openssh bugs - Sep 2011 - [Bug 937] ssh2 pubkey auth broken by user:style syntax

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

Patric Stout <patric.stout at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |patric.stout at gmail.com

--- Comment #1 from Patric Stout <patric.stout at gmail.com> 2011-09-10
18:24:11 EST ---
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.

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

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

--- Comment #2 from Patric Stout <patric.stout at gmail.com> 2011-09-10
18:25:49 EST ---
Created attachment 2080
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2080
Support Pubkeys with :style loginname

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

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

Patric Stout <patric.stout at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2080|0                           |1
        is obsolete|                            |

--- Comment #3 from Patric Stout <patric.stout at gmail.com> 2011-09-10
20:07:50 EST ---
Created attachment 2081
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2081
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.

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