Bug 937 - ssh2 pubkey auth broken by user:style syntax
Summary: ssh2 pubkey auth broken by user:style syntax
Status: CLOSED FIXED
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: -current
Hardware: All OpenBSD
: P2 normal
Assignee: OpenSSH Bugzilla mailing list
URL:
Keywords:
Depends on:
Blocks: V_6_3
  Show dependency treegraph
 
Reported: 2004-09-30 17:00 AEST by Damien Miller
Modified: 2015-08-11 23:02 AEST (History)
1 user (show)

See Also:


Attachments
Support Pubkeys with :style loginname (1.07 KB, patch)
2011-09-10 18:25 AEST, Patric Stout
no flags Details | Diff
Support Pubkeys with :style loginname (5.51 KB, patch)
2011-09-10 20:07 AEST, Patric Stout
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Damien Miller 2004-09-30 17:00:06 AEST
ssh2 pubkey auth is broken ("hash mismatch") when a user tries to log in using
the "user:style" username trick despite having a valid pubkey. 

The problem is that we strip off the style in input_userauth_request(), but we
don't add it back when computing the pubkey signature. Maybe it would be better
to stash the entire username as offered by the client and use it to compute the sig.
Comment 1 Patric Stout 2011-09-10 18:24:11 AEST
Yesterday I found out about this problem too, and I am amused to see this bug was original created 7 years ago.

That said, a solution is relative easy. The comment in auth.h suggests that the authctxt->user field should be the username as the client sends it. And looking at the code it is also how it is used. For example in the public key challenge, where the client assumes the name he sends is the one used by the server. In auth2-pubkey.c we also find authctxt->user in this place. So that leaves us to wonder why this field is not really what the client send, but in case of [:style] (or [/role] in the Debian SELinux patch) a modified version.

Attached a simple patch to solve the issue, which also makes the comment in auth.h valid again. I am not an OpenSSH expert, and I cannot validate if in all cases this will work as intended, but for regular (non-style loginnames) this cannot do any harm, so it can only work for the better. 

As a side-effect of this change, a validation of username-change triggered, which had to be avoided by another simple modification.

With this patch applied, you can login to a server with your public-key with username:style as your loginname.
Comment 2 Patric Stout 2011-09-10 18:25:49 AEST
Created attachment 2080 [details]
Support Pubkeys with :style loginname
Comment 3 Patric Stout 2011-09-10 20:07:50 AEST
Created attachment 2081 [details]
Support Pubkeys with :style loginname

Although the last patch was valid, it was both applied to Debian source, as it was tested without privileged mode.

This brought a few other things to light.

It turns out several places send ->pw->pw_name to ->user in the monitor, causing validations to fail (user-mismatch).

Although everywhere ->pw->pw_name and ->user is used when needed, auth2-pam is an exception. It uses ->user, where it should be using ->pw->pw_name.

The combination of all these small problems are combined in the attached patch. The changes to auth2-pam.c should be considered separate. They are related to this bug, but is a problem on its own which should be addressed.

With auth2-pam.c changes, there is no need to send the username to the monitor separately.

To stop talking so much, as last, to solve this bug it was needed to send the real username in the authserv package. I don't know if it is in its place there, but it felt good to place it there.

The default remarks hold, I am not an OpenSSH expert so I don't know the impact in other parts of this patch. It works for me. Also, I only tested it with protocol 2.
Comment 4 Damien Miller 2013-03-08 10:23:59 AEDT
Fixed in a slightly different way: by reconstructing the user:style where we need it. This will be in openssh-6.3.
Comment 5 Damien Miller 2015-08-11 23:02:33 AEST
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1