[Bug 1554] No feedback when configuration file permissions are set incorrectly.

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1554


bgassend at exponent.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




--- Comment #2 from bgassend at exponent.com  2009-02-13 18:05:05 ---
(In reply to comment #1)

Pardon me if reopening this is poor etiquette. I do not have much
experience with the bug submission process. I believe that I may have a
constructive solution that is both secure and user friendly.

> Bad permissions are logged on the server. E.g.
> 
> Authentication refused: bad ownership or modes for file
> /home/djm/.ssh/authorized_keys

The problem is that only an administrator can see /var/log/auth.log.
Today I was trying to get things working on a machine on which I did
not have root access, and the admin did not know anything about getting
sshd to work, was on the other side of the country, and possibly did
not know about /var/log/auth.log. (I didn't know about that file
without further digging this evening.)

> We cannot relay this information to the client because it is, by
> definition, not authenticated at the time it is attempting public key
> authentication and is therefore untrustworthy. It would be
> inappropriate to divulge the existence of an authorized_keys file, let
> alone that it has unsafe permissions.

Would it be possible to relay this information to the user after he has
typed his password and successfully logged in? This could be appended
to the motd, so it shouldn't break scripts, and it takes place on the
server side where the reason why the authentication failed is known.

I see a number of advantages:
- This could be seen as a security enhancement. Imagine the following
scenario. Alice has a world writable authorized_keys file. (She had
tried and given up on getting public key authentication to work because
she didn't figure out that she had a permission problem. The file sits
there for many months. Oscar notices and puts in a malicious key. One
day at lunch, Alice finds out from Bob that her failure to use public
key authentication may be because of a file permission problem. Alice
corrects the file permissions, and sure enough she can now log in.
Oscar is also happy because he too can log in.

- This is a great usability improvement. Today I tried running ssh with
all the verbosity turned up. The public key was going out and
disappearing into a vacuum. I tried running a non-priviledged sshd on
the server machine with debugging information turned on. It kept dying
without saying why, probably had to do with the fact that I did not
have root acces. I didn't know, and didn't have access to
/var/log/auth.log. The administrator didn't know much about ssh
authentication. In the end a flash of inspiration (I had encountered
this problem once before), file permissions on authorized_keys occurred
to me. Without the flash of inspiration I might have given up. And yet
I am a software engineer with 10 years of experience running my Linux
box. 

All this to say that there is a usability issue with getting public key
authentication working. I have often fought this problem, and I'm sure
I'm not the only one. The reason for this usability issue is that it is
that the failure is silent. Giving information on the failure after the
user has typed the correct password is not a security issue. If the
user is running ssh -v -v -v -v -v, printing that information is not
going to be seen as causing too much clutter. If the authorized_key
file is world writable, that is a security concern (see above) that the
user should be notified of as soon as he is authenticated.

I hope I have been more convincing, and that you will consider the
solution I propose, which I think addresses usability, security and
implementation convenience.

Best regards,
Blaise Gassend

-- 
Configure bugmail: https://bugzilla.mindrot.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.