How utterly bizarre...
Go to https://www.dropbox.com/sh/sbqyy7gvzrd3egt/UCWszNQ3ES/Shibboleth - I've parked my two files there.
Do you ever get the Moonshot Identity Selector popping up (or are you in a console?) - If you have the Moonshot ID selector, my cards are configured as follows:
Display Name: whatever you want it to be
Issuer: realm (for some of my users it's diamond.ac.uk, for my fake eduroam user it's camford.ac.uk)
Username: user's ID
Password: user's password
Remember password: ticked
You can also click on "View Details" and then click on "Remove" to unlink the appropriate card from the service. If you use the ID selector, rename .gss_eap_id in your home directory, or ensure the username/password combination there matches the card that is linked to the service.
If you're in a console, my .gss_eap_id tends to be a full eduroam-compatible username (i.e. "[log in to unmask]") and the password in the next line.
This is what currently works for me...
Stefan
-----Original Message-----
From: Stuart Rankin [mailto:[log in to unmask]]
Sent: 07 June 2013 09:51
To: Paetow, Stefan (DLSLtd,RAL,DIA)
Cc: [log in to unmask]
Subject: Re: Odd behaviour with local users
Hi Stefan,
Those lines didn't exist (I note that they don't on the live DVD either), but if I add them gssapi fails consistently (even with a non-null user). I.e. every ssh attempt falls though to asking for a password.
Perhaps I'm adding the lines in the wrong place (I tried both outside and inside the <SPConfig>...</SPConfig> tags). If you could please send me your version of the file I will try it with your sshd binary.
Best Regards
Stuart
On 07/06/13 09:23, [log in to unmask] wrote:
> 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
>
--
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
|
