I've killed about 10+ hours configuring CVS to run over SSH. I was
having a problem until, out of desperation, I tried making some chmods
755 --- and then success. Why is gosh-darn SSH so picky?

I place a authorized_keys2 file in a UNIX user cvs' .ssh directory and
into another user smiller's .ssh directory.

The authorized_keys2 file of identical length and checksum in both
directories. The chmods on both copies is 755 (one copy in
/home/cvs/.ssh/authorized_keys2) and the second in
/home/smiller/.ssh/authorized_keys2). The cvs copy is owned by cvs.cvs
whereas the smiller copy is owned by smiller.smiller. Similarly for the
..ssh directory. Both are chmod 755 and are owned by their respective
owner and group.

The only gosh darn difference was that /home/cvs was chmod 755 cvs.cvs.
But /home/smiller was chmod 777 smiller.smiller.

That tiny difference is what caused a ssh into smiller to require a
password but sshing in as cvs did not require a password i.e.

> eval $( ssh-agent -s )
> ssh-add [enter passcode]
> ssh -l cvs <host> # this works; I'm logged in and no password is needed.
> ssh -l smiller <host> # this does not work. I am asked for the password.

But if I change /home/smiller to 755 then volai

> ssh -l smiller <host> # it works fine.

What is the deal? Honestly, what is the deal here?

>>>>> "gsm" == gsm beamon <gsm.beamon@gmail.com> writes:

gsm> I've killed about 10+ hours configuring CVS to run over SSH. I
gsm> was having a problem until, out of desperation, I tried making
gsm> some chmods 755 --- and then success. Why is gosh-darn SSH so
gsm> picky?

gsm> I place a authorized_keys2 file in a UNIX user cvs' .ssh
gsm> directory and into another user smiller's .ssh directory.

gsm> The authorized_keys2 file of identical length and checksum in
gsm> both directories. The chmods on both copies is 755 (one copy in
gsm> /home/cvs/.ssh/authorized_keys2) and the second in
gsm> /home/smiller/.ssh/authorized_keys2). The cvs copy is owned by
gsm> cvs.cvs whereas the smiller copy is owned by
gsm> smiller.smiller. Similarly for the .ssh directory. Both are chmod
gsm> 755 and are owned by their respective owner and group.

gsm> The only gosh darn difference was that /home/cvs was chmod 755
gsm> cvs.cvs. But /home/smiller was chmod 777 smiller.smiller.

gsm> That tiny difference is what caused a ssh into smiller to require
gsm> a password but sshing in as cvs did not require a password i.e.

>> eval $( ssh-agent -s ) ssh-add [enter passcode] ssh -l cvs <host> #
>> this works; I'm logged in and no password is needed. ssh -l
>> smiller <host> # this does not work. I am asked for the password.

gsm> But if I change /home/smiller to 755 then volai

>> ssh -l smiller <host> # it works fine.

gsm> What is the deal? Honestly, what is the deal here?

% man sshd_config
....
StrictModes
Specifies whether sshd should check file modes and ownership of
the user's files and home directory before accepting login. This
is normally desirable because novices sometimes accidentally
leave their directory or files world-writable. The default is
``yes''.
....

--
Richard Silverman
res@qoxp.net

> % man sshd_config
> ...
> StrictModes
> Specifies whether sshd should check file modes and ownership of
> the user's files and home directory before accepting login. This
> is normally desirable because novices sometimes accidentally
> leave their directory or files world-writable. The default is
> ``yes''.
> ...
>
> --
message received!
shane

gsm.beamon@gmail.com wrote:
>> eval $( ssh-agent -s )
>> ssh-add [enter passcode]
>> ssh -l cvs <host> # this works; I'm logged in and no password is needed.
>> ssh -l smiller <host> # this does not work. I am asked for the password.

> But if I change /home/smiller to 755 then volai

>> ssh -l smiller <host> # it works fine.

> What is the deal? Honestly, what is the deal here?

Also when debugging these issues, if you run the server in debug mode
(usually easiest to run another copy on another port), it will be more
explicit about running into permissions issues.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

In article <1162475184.278098.179190@f16g2000cwb.googlegroups .com>
gsm.beamon@gmail.com writes:
>> % man sshd_config
>> ...
>> StrictModes
>> Specifies whether sshd should check file modes and ownership of
>> the user's files and home directory before accepting login. This
>> is normally desirable because novices sometimes accidentally
>> leave their directory or files world-writable. The default is
>> ``yes''.
>> ...
>>
>message received!

Hopefully you also received the implicit message about why the default
(which you shouldn't change without *very* good reason) made sshd refuse
the key-based authentication: If /home/miller is mode 777, even if
/home/miller/.ssh is mode 755, any user on the system can do e.g.:

mv /home/miller/.ssh /home/miller/foo
mkdir /home/miller/.ssh
cp $HOME/.ssh/authorized_keys /home/miller/.ssh

- and then log in as miller using his own private key. This applies
recursively upwards of course, i.e. lax permissions on '/' or '/home'
will allow a variant of the same trick.

--Per Hedeland
per@hedeland.org

On 2006-11-02, Per Hedeland <per@hedeland.org> wrote:

> Hopefully you also received the implicit message about why the default
> (which you shouldn't change without *very* good reason) made sshd refuse

The failure should also have created a log entry which if you had a proactive
geek on log duty would led to him contacting you and explaining the problem.
Or even if you didn't; logs are sometimes a good place to look for errors
that don't show on the command-line.

--
Elvis Notargiacomo master AT barefaced DOT cheek
http://www.notatla.org.uk/goen/

> Hopefully you also received the implicit message about why the default
> (which you shouldn't change without *very* good reason) made sshd refuse
> the key-based authentication: If /home/miller is mode 777, even if
> /home/miller/.ssh is mode 755, any user on the system can do e.g.:
thank you for this clarification. good stuff. thank you.