-----Original Message-----
From: Paetow, Stefan (DLSLtd,RAL,DIA) 
Sent: 06 June 2013 16:59
To: 'Stuart Rankin'
Subject: RE: Odd behaviour with local users

*hangs head in shame* 

I was trying to figure something out... and broke Sam's fix. I've unbroken it now and it's on Dropbox.

:-/

Stefan

-----Original Message-----
From: Stuart Rankin [mailto:[log in to unmask]]
Sent: 06 June 2013 16:58
To: Paetow, Stefan (DLSLtd,RAL,DIA)
Subject: Re: Odd behaviour with local users

Backtrace:

#0  0x00007f92f968c120 in ssh_gssapi_generic_localname (client=<value optimized out>, localname=
     0x7fff51b43dc0) at gss-serv.c:91
#1  0x00007f92f968b53f in gssapi_set_username (authctxt=0x7f92fa03be30) at auth2-gss.c:280
#2  0x00007f92f968b827 in input_gssapi_mic (type=<value optimized out>,
     plen=<value optimized out>, ctxt=0x7f92fa03be30) at auth2-gss.c:374
#3  0x00007f92f96aeb73 in dispatch_run (mode=0, done=0x7f92fa03be30, ctxt=0x7f92fa03be30)
     at dispatch.c:98
#4  0x00007f92f966b091 in main (ac=<value optimized out>, av=<value optimized out>) at sshd.c:2003

On 06/06/13 16:39, Stuart Rankin wrote:
> Hi Stefan,
>
> FWIW, the segfault is occurring here:
>
> [Switching to Thread 0x7fb92b00c7c0 (LWP 22005)]
> 0x00007fc3e3c36120 in ssh_gssapi_generic_localname (client=<value optimized out>, localname=
>      0x7fffe9ba0e10) at gss-serv.c:91
> 91          *(localname)[lbuffer.length] = '\0';
>
> Best regards
>
> Stuart
>
> On 06/06/13 14:54, Stefan Paetow wrote:
>> Oh, Stuart,
>>
>> Run "touch /var/log/lastlog" if the file does not exist... then restart SSHD.
>>
>> Does that stop the segfault?
>>
>> Stefan
>>
>>
>> -----Original Message-----
>> From: Moonshot community list
>> [mailto:[log in to unmask]] On Behalf Of Stuart Rankin
>> Sent: 06 June 2013 14:50
>> To: [log in to unmask]
>> Subject: Re: Odd behaviour with local users
>>
>> Hi Stefan,
>>
>> In my case, I have two accounts on the server without passwords (i.e. 
>> with the password field disabled), and one account with a password. 
>> When using sshd built from SRPM with your patches (and also when using the binary which you built), each of these accounts is behaving the same way, i.e.
>> doing
>>
>> ssh -l testuser moon-server.vm
>>
>> lets me in if the SAML header in
>> /etc/freeradius/sites-available/default on the IdP contains testuser, 
>> but otherwise fails gssapi-with-mic and proceeds to try password authentication. This seems to be the expected behaviour.
>>
>> However, I'm afraid that if I try
>>
>> ssh -l "" moon-server.vm
>>
>> the sshd segfaults. This is also true with your binary version from 
>> dropbox. I will try to work out where the segfault is occurring.
>>
>> Best regards,
>>
>> Stuart
>>
>>
>> On 06/06/13 13:56, Stefan Paetow wrote:
>>> Right, I'm noticing some odd behaviour with Moonshot SSH and if one 
>>> of the experts could help explain, that'd be grand.
>>>
>>> I have user "steve" and "steve2" on the local box. "steve" has a 
>>> password set, but "steve2" was added with useradd -m. When I attempt 
>>> to use Moonshot authentication, a test that results in "steve" as local-login-user fails to log me in, whereas a test that results in "steve2" works.
>>>
>>> Is there a specific restriction that the password needs to be unset 
>>> for the local user to be able to log in with GSS or something to that effect?
>>>
>>> With Regards
>>>
>>> Stefan Paetow
>>> Software Engineer
>>> +44 1235 778812
>>> Diamond Light Source Ltd.
>>> Diamond House, Harwell Science and Innovation Campus Didcot, 
>>> Oxfordshire, OX11 0DE
>>>
>>>
>>>
>>>
>>
>> --
>> Dr. Stuart Rankin
>>
>> Senior System Administrator
>> High Performance Computing Service
>> University of Cambridge
>> Email: [log in to unmask]
>> Tel: (+)44 1223 763517
>>
>

--
Dr. Stuart Rankin

Senior System Administrator
High Performance Computing Service
University of Cambridge
Email: [log in to unmask]
Tel: (+)44 1223 763517

-- 
This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom