openssh bugs - Jan 2010 - [Bug 1693] New: ssh prompts for passphrase even when identity file is unreadable

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

           Summary: ssh prompts for passphrase even when identity file is
                    unreadable
           Product: Portable OpenSSH
           Version: 5.3p1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: ssh
        AssignedTo: unassigned-bugs at mindrot.org
        ReportedBy: tj at castaglia.org


Created an attachment (id=1767)
 --> (https://bugzilla.mindrot.org/attachment.cgi?id=1767)
Uses access(2) to check readability of identity file before loading

When using publickey authentication, the private key is loaded from an
IdentityFile using ssh2connect.c's load_identity_file() function.  A
stat(2) is used to ensure that the file exists, and then the key is
loaded.

If the file exists, but the process does not have read permissions on
that file, then ssh will prompt the user for a passphrase.  This is
particularly confusing if the private key in question is not
passphrase-protected.  The fact that the ssh client prompts for the
passphrase is misleading; the underlying inability to load the private
key stems not from the need for a passphrase, but from the lack of
readability.  It would be better to display a "Permission denied"
message to the user, and/or move on to the next authentication method,
rather than needlessly prompting the user for passphrases in this case.

The attached patch attempts to remedy this situation by using access(2)
after the stat(2) call.  If the file is not readable, then the private
key cannot be loaded, and thus the call to key_load_private_type() is
skipped.

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

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

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au
             Blocks|                            |1626

--- Comment #1 from Darren Tucker <dtucker at zip.com.au> 2010-01-11
12:43:56 EST ---
Look at this for 5.4

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

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

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1767|0                           |1
        is obsolete|                            |
   Attachment #1774|                            |ok?(djm at mindrot.org)
               Flag|                            |

--- Comment #2 from Darren Tucker <dtucker at zip.com.au> 2010-01-11
15:16:15 EST ---
Created an attachment (id=1774)
 --> (https://bugzilla.mindrot.org/attachment.cgi?id=1774)
log (to debug) the reason for failing to load a private key

OK, so this is interesting: it doesn't happen on OpenBSD, but I do see
it on Linux.

sshconnect2.c:load_identity_file() calls key_load_private_type.  If
that fails and if we're either or in batchmode or if the key has bad
perms then we quit, otherwise we prompt for a passphrase.  Or at least
that's what it's supposed to do.

So why doesn't this actually happen on Linux?  perm_ok is on the stack,
and if the open() in key_load_private_type fails then it returns early
without setting (or unsetting) perm_ok.  Thus, whether or not you get
prompted depends on the initial value of perm_ok from whatever happened
to be on the stack.  Nasty.

This patch reports the reason if the open() fails and sets perms_ok
appropriately, no need for the extra access() calls.  It also
initializes perms_ok to the safe default.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1774|ok?(djm at mindrot.org)        |ok+
               Flag|                            |

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

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

Darren Tucker <dtucker at zip.com.au> changed:

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

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> 2010-01-11
15:47:32 EST ---
Patch has been applied and will be in 5.4.  Thanks for the report.

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

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

--- Comment #4 from TJ Saunders <tj at castaglia.org> 2010-01-12 04:59:20
EST ---
Thanks for the analysis; I'd missed the reliance upon the stack-based
value of perm_ok when trying to figure this out.  Cheers!

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

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

Darren Tucker <dtucker at zip.com.au> changed:

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

--- Comment #5 from Darren Tucker <dtucker at zip.com.au> 2010-03-26
10:51:47 EST ---
With the release of 5.4p1, this bug is now considered closed.

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