openssh bugs - Sep 2012 - [Bug 2042] New: Troubleshooting information should be logged when sshd doesn't have permission to read user's authorized_keys file

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

          Priority: P5
            Bug ID: 2042
          Assignee: unassigned-bugs at mindrot.org
           Summary: Troubleshooting information should be logged when sshd
                    doesn't have permission to read user's
authorized_keys
                    file
          Severity: enhancement
    Classification: Unclassified
                OS: Linux
          Reporter: asari.takashi at gmail.com
          Hardware: All
            Status: NEW
           Version: 5.6p1
         Component: sshd
           Product: Portable OpenSSH

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Janne Ruohom?ki <janne.ruohomaki at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janne.ruohomaki at gmail.com

--- Comment #1 from Janne Ruohom?ki <janne.ruohomaki at gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org,
                   |                            |dtucker at dtucker.net
   Attachment #3601|                            |ok?(dtucker at dtucker.net)
              Flags|                            |

--- Comment #2 from Damien Miller <djm at mindrot.org> ---
Created attachment 3601
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3601&action=edit
increase loglevel for errno != ENOENT

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3601|ok?(dtucker at dtucker.net)    |ok+
              Flags|                            |

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Blocks|                            |3418
             Status|NEW                         |RESOLVED

--- Comment #3 from Damien Miller <djm at mindrot.org> ---
This has been committed and will be in OpenSSH 9.1


Referenced Bugs:

https://bugzilla.mindrot.org/show_bug.cgi?id=3418
[Bug 3418] tracking bug for openssh-9.1
-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #4 from Damien Miller <djm at mindrot.org> ---
Closing bugs from openssh-9.1 release cycle

-- 
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.