Bug 2042 - Troubleshooting information should be logged when sshd doesn't have permission to read user's authorized_keys file
Summary: Troubleshooting information should be logged when sshd doesn't have permissio...
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 5.6p1
Hardware: All Linux
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks: V_9_1
  Show dependency treegraph
 
Reported: 2012-09-15 02:48 AEST by Takashi Asari
Modified: 2022-10-04 21:58 AEDT (History)
3 users (show)

See Also:


Attachments
increase loglevel for errno != ENOENT (1013 bytes, patch)
2022-07-01 10:57 AEST, Damien Miller
dtucker: ok+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Takashi Asari 2012-09-15 02:48:59 AEST
For ease of troubleshooting, I think sshd should complain when authorized_keys file  couldn't be read.

Currently we can see debug level messages like this:

$ sudo /usr/sbin/sshd -dDp 2022
debug1: sshd version OpenSSH_5.6p1
:
debug1: trying public key file /Users/asari/.ssh/authorized_keys
debug1: Could not open authorized keys '/Users/asari/.ssh/authorized_keys': Permission denied

... but I believe this message should go to the info level, because it's likely to be caused by a misconfiguration. (To be precise, I think it's still fine to leave the log at debug level when authorized_keys doesn't exist (No such file or directory).)

I see many users including me have difficulty with troubleshooting about this, typically the admin performed 'sudo cp pubkey ~username/.ssh/authorized_keys' and left the file owned by root and 600-mode.

One concern about this feature request is about such a case like root placed non-readable empty files into ~username/.ssh/authorized_keys{,2} and intended to prevent the user from placing his/her own authorized_keys file...  though I think it's a very rare case (and even no problem if the mode were user-readable).

By the way, when authorized_keys had too open mode or was owned by the other user (except by root),  even currently we can see messages like "Authentication refused: bad ownership or modes for file $USER/.ssh/authorized_keys", and a client can receive notice about this as of OpenSSH 5.7 ( https://bugzilla.mindrot.org/show_bug.cgi?id=1554 ). I understand that these messages intend not to point a misconfiguration but to point a security issue, but I'd be happy if I can see similar messages like this.
Comment 1 Janne Ruohomäki 2022-07-01 03:10:15 AEST
I seriously think that this issue is way too severe to sit idling for 10 years. 

https://github.com/openssh/openssh-portable/blob/acb2059febaddd71ee06c2ebf63dcf211d9ab9f2/auth2-pubkeyfile.c#L453
https://github.com/openssh/openssh-portable/blob/f5ba85daddfc2da6a8dab6038269e02c0695be44/auth2-pubkey.c#L599

All error messages related to read access to users authorized_keys file are sent to /dev/null with any sensible production log level. Not only this makes diagnostics of pubkey authentication credential issues, it also hides potential brute force attacks as there's no sensible output in the log files about failed authentication attempts. Now, as the users authorized_keys file is in users control, including filesystem access rights and potentially excluding selinux settings, this can make considerable mess. 

Additionally, there have been problems in several distros breaking pubkey authentication via messing with selinux configs for authorized_keys file on larger scale.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=658675
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/965663

All it takes to fix this, is change those log levels in auth2-pubkeyfile.c and auth2-pubkey.c to Warning or Error. 

I would suggest Error as a correct log level for "Could not open %s '%s': %s" messages because:

1) It directly affects authentication by leaving out configuration
2) The configuration left out is explicitly put in place meant to be used
3) If not written to log, it masks brute force attacks against certain user accounts, if read access to config file in control of non-root user is denied.
Comment 2 Damien Miller 2022-07-01 10:57:37 AEST
Created attachment 3601 [details]
increase loglevel for errno != ENOENT
Comment 3 Damien Miller 2022-07-01 13:54:59 AEST
This has been committed and will be in OpenSSH 9.1
Comment 4 Damien Miller 2022-10-04 21:58:58 AEDT
Closing bugs from openssh-9.1 release cycle