Mehdi, Check that these GSSAPI options in /etc/ssh/sshd_config are set to "yes": GSSAPIAuthentication GSSAPIKeyExchange GSSAPICleanupCredentials You may want to set GSSAPIStrictAcceptorCheck to "no", restart the SSH server and see if it resolves the issue you are having. According to the debug output, the "Acceptor identity different than expected" error means that the hostname may not have resolved back correctly and the acceptor check failed because of that. With Regards Stefan From: Moonshot community list [mailto:[log in to unmask]] On Behalf Of Mehdi Hached Sent: 08 November 2013 14:17 To: [log in to unmask] Subject: Re: [moonshot] Progress update - July 2013 Hello John, To stick more closely to the moonshot documentation for the test server, I have reinstalled it, with the latest updates, on a regular virtual box (not on our IVS) I'm experiencing ssh text connections failures without having a clue of what is wrong. Any idea about what is failing ? ________________________________ hached@moonshot:~$ ssh -v [log in to unmask]<mailto:[log in to unmask]> OpenSSH_5.9p1 Debian-5+moonshot5, OpenSSL 1.0.1e 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug1: Connecting to moonshot.renater.fr [127.0.1.1] port 22. debug1: Connection established. debug1: identity file /home/hached/.ssh/id_rsa type -1 debug1: identity file /home/hached/.ssh/id_rsa-cert type -1 debug1: identity file /home/hached/.ssh/id_dsa type -1 debug1: identity file /home/hached/.ssh/id_dsa-cert type -1 debug1: identity file /home/hached/.ssh/id_ecdsa type -1 debug1: identity file /home/hached/.ssh/id_ecdsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5+moonshot5 debug1: match: OpenSSH_5.9p1 Debian-5+moonshot5 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5+moonshot5 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: sending SSH2_MSG_KEX_ECDH_INIT debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: Server host key: ECDSA e2:de:5e:22:f1:26:2c:03:a1:fc:cd:ee:7f:db:c0:37 debug1: Host 'moonshot.renater.fr' is known and matches the ECDSA host key. debug1: Found key in /home/hached/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_1000' not found debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_1000' not found debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_1000' not found debug1: Invalid token was supplied Acceptor identity different than expected debug1: Invalid token was supplied Acceptor identity different than expected debug1: Next authentication method: publickey debug1: Trying private key: /home/hached/.ssh/id_rsa debug1: Trying private key: /home/hached/.ssh/id_dsa debug1: Trying private key: /home/hached/.ssh/id_ecdsa debug1: Next authentication method: password [log in to unmask]<mailto:[log in to unmask]>'s password: ________________________________ Second question, Jean-François told me that you met at the GEANT Symposium and you spoke about the necessity of a Radsec server to deploy a national trust router. Jean-François told me that we can use the JANET (test?) Radsec server. I guess it is only for test purpose, am I wrong ? We will have to wait for our security team to do the DNSSEC/RADSEC implementation to be able to finish our own work with the trust router then... Thank you for your help and advices. Regards, Le 06/08/2013 17:17, Mehdi Hached a écrit : Le 30/07/13 16:08, John Chapman a écrit : Hello all Hello, A quick update from my side. As we're approaching the end of another month I thought it would be useful to take stock of where we are and also to encourage you to share your progress so far. Demo DVD - The 2013.06.17 release of the Live DVD includes Freeradius 3.x (including trust_router client support) and significant updates to the UI. It also uses RADSEC: https://community.ja.net/groups/moonshot/wiki/getting-started-moonshot-using-live-dvd I have used the documentation and the liveDvd install as mentioned above. I'm connecting from distance with ssh to my moonshot test server, so I'm not using my server GUI. I perform my tests as follow: * GSS test ok (only once) * SSH test ok (only once). The following times it asks for the user "moonshot"'s password after failing several authentication means. The follonwing times: * GSS: "GSS-API error initializing context: SPNEGO failed to negotiate a mechanism" * SSH: "debug1: Host 'dev-moonshot.renater.fr' is known and matches the ECDSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: ssh_ecdsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa ((nil)) debug2: key: /root/.ssh/id_dsa ((nil)) debug2: key: /root/.ssh/id_ecdsa ((nil)) debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information Credentials cache file '/tmp/krb5cc_0' not found [...] debug1: Unspecified GSS failure. Minor code may provide more information Generic RADIUS failure debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug2: we did not send a packet, disable method debug1: Next authentication method: publickey debug1: Trying private key: /root/.ssh/id_rsa debug1: Trying private key: /root/.ssh/id_dsa debug1: Trying private key: /root/.ssh/id_ecdsa debug2: we did not send a packet, disable method debug1: Next authentication method: password [log in to unmask]<mailto:[log in to unmask]>'s password: I don't know if I'm doing something wrong but my tests are not very successful. Another "issue" is to clean the identity selector without the GUI ? Thanks From: John Chapman Sent: 18 June 2013 15:32 To: [log in to unmask]<mailto:[log in to unmask]> Subject: Progress update Hello all Following on from the Moonshot briefing 3 weeks ago I thought it would be good to catch up with you all to see how you are getting on with your own testing / implementation. I see from the [log in to unmask]<mailto:[log in to unmask]> list that RedIRIS/UMU and CSC are making good progress - good work Kalle and Alejandro. Please could everyone let me know either here or off list what (if any) progress you have made. If you've not yet started looking at Moonshot yet, then I'd recommend installing the Live DVD (https://community.ja.net/groups/moonshot/wiki/getting-started-moonshot-using-live-dvd ) as the first step. We're slowly adding more documentation to https://community.ja.net/groups/moonshot/wiki but if anyone needs any specific help then please email the [log in to unmask]<mailto:[log in to unmask]> list. And if anyone needs access to the Windows libraries, please let me know and I'll send you the Dropbox link. Cheers John -- Dr John Chapman Strategic Programmes Janet 01235 822 346 Twitter http://twitter.com/chapman_john Janet, the UK's research and education network. -- Mehdi HACHED Services applicatifs aux utilisateurs Middleware services Tel : +33 2 23 23 69 38 Fax : +33 2 23 23 71 11 www.renater.fr<http;/www.renater.fr> -- 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