RFC 4462 empty user name string

[David Leonard]

Hi,

Thanks for that. I looked at the patch in 958, and I guess I will have 
to stare at it some more (when I am more awake) to understand how it 
uses empty username strings.

I'm mainly confused as to what the behaviour of the /client/ should be. 
You see I've also got patches against PuTTY, and the approach I made it 
try for gssapi-with-mic/gss-keyex was
   - try sending an empty username string first
   - if that fails, try sending the username provided in config
   - if that fails, try sending the non-realm elements of the upn :)
My plan was that the client should try to discover a way to login to the 
server by trying older and older standards.. and guesswork. The problem 
though is that sshd rejects the connection because it sees the client is 
changing the username, and won't give the client a second chance. The 
only workaround I can see is that the client re-try the connection after 
it collapses (but that has its own hairy problems.)

Bug 1100 is the one I entered on this topic. I have an implementation 
(patch), for openssh but it only works without privsep at the moment.

Cheers

d

Jim Basney wrote:
> Yes, we find the RFC 4462 empty user name string feature very useful for
> the GSI GSSAPI mechanism to ease single sign-on across systems where
> usernames differ.  For interop, we have to be careful to only send an
> empty username if we know the server will accept it.  We maintain our
> GSI patch for OpenSSH at <http://grid.ncsa.uiuc.edu/ssh/>.  I submitted
> a version of the patch at
> <http://bugzilla.mindrot.org/show_bug.cgi?id=958> which I'd be happy to
> update if there's interest.
>
> Cheers,
> Jim
>
> David Leonard <David.Leonard at quest.com> wrote:
>   
>> I'm all for multiple-auth in sshd, but the current impl appears to
>> conflict with an obscure feature of RFC4462 that I have been trying to
>> implement, namely where the username field can start off blank and the
>> server deduces the username from the credentials. Has anyone else looked
>> at this? sshd currently rejects connections when the username field
>> changes between separate auth attempts.
>>
>> d
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> http://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>     
>
>
>