Good morning Stuart,
Can you check your /etc/shibboleth/shibboleth2.xml for this set of lines:
<Extensions>
<Library path="plugins.so" fatal="true" />
</Extensions>
If they don't exist, please insert them. Then try the null-user test again. It should work (does on both my servers now).
Regards
Stefan
-----Original Message-----
From: Moonshot community list [mailto:[log in to unmask]] On Behalf Of Stuart Rankin
Sent: 06 June 2013 18:04
To: [log in to unmask]
Subject: Re: Odd behaviour with local users
Hi Stefan and Sam,
The segfault has gone, but I'm now seeing a new strange behaviour when the ssh user is null.
With this attribute released by the IdP:
SAML-AAA-Assertion += '<saml:Attribute NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.7"><saml:AttributeValue>sjr20</saml:AttributeValue></saml:Attribute>'
trying
ssh -l "" moon-server.vm
CTRL-EVENT-EAP-STARTED EAP authentication started CTRL-EVENT-EAP-PROPOSED-METHOD vendor=0 method=21 CTRL-EVENT-EAP-METHOD EAP vendor 0 method 21 (TTLS) selected CTRL-EVENT-EAP-SUCCESS EAP authentication completed successfully Connection to moon-server.vm closed by remote host.
Connection to moon-server.vm closed.
the sshd closes the connection as you can see above and logs the following:
Jun 6 17:34:10 moon-server sshd[12054]: Accepted gssapi-with-mic for sjr20 from 192.168.122.92 port
50138 ssh2
Jun 6 17:34:11 moon-server sshd[12054]: pam_unix(sshd:session): session opened for user sjr20 by
(uid=0)
Jun 6 17:34:11 moon-server sshd[12059]: fatal: login_init_entry: Cannot find user "6+\362\335\330\177"
Jun 6 17:34:11 moon-server sshd[12054]: fatal: login_init_entry: Cannot find user "6+\362\335\330\177"
Jun 6 17:34:11 moon-server sshd[12054]: pam_unix(sshd:session): session closed for user sjr20 Jun 6 17:34:11 moon-server sshd[12054]: fatal: login_init_entry: Cannot find user "6+\362\335\330\177"
The garbage at the end is changing randomly. Using a non-null user still works fine. I've tried both rebuilding openssh against the most recent patch, and using the latest binary from the zipped RPMS at dropbox. It doesn't seem to matter whether the user has a local password set or not (I've tried multiple users).
Doing it again just now I got this (note the 'user "SELINUX_ROLE_REQUESTED="'):
Jun 6 17:58:23 moon-server sshd[12207]: Invalid user from 192.168.122.92 Jun 6 17:58:23 moon-server sshd[12207]: input_userauth_request: invalid user Jun 6 17:58:23 moon-server sshd[12207]: Failed none for invalid user from 192.168.122.92 port
50163 ssh2
Jun 6 17:58:24 moon-server sshd[12207]: Postponed gssapi-with-mic for invalid user from
192.168.122.92 port 50163 ssh2
Jun 6 17:58:24 moon-server sshd[12207]: Accepted gssapi-with-mic for sjr20 from 192.168.122.92 port
50163 ssh2
Jun 6 17:58:24 moon-server sshd[12207]: pam_unix(sshd:session): session opened for user sjr20 by
(uid=0)
Jun 6 17:58:24 moon-server sshd[12212]: fatal: login_init_entry: Cannot find user "SELINUX_ROLE_REQUESTED="
Jun 6 17:58:24 moon-server sshd[12207]: fatal: login_init_entry: Cannot find user "SELINUX_ROLE_REQUESTED="
Jun 6 17:58:24 moon-server sshd[12207]: pam_unix(sshd:session): session closed for user sjr20 Jun 6 17:58:24 moon-server sshd[12207]: fatal: login_init_entry: Cannot find user "\360s\002\353\257\177"
I note that Stefan you aren't seeing this?
Best regards,
Stuart
On 06/06/13 17:02, Stefan Paetow wrote:
> -----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
>
--
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
|