1
1
I've been trying to solve this for a while, but I'm admittedly quite stumped.
I just started up a new server and was setting up OpenSSH to use key-based SSH logins, but I've run into quite a dilemma. All the guides are relatively similar, and I was following them closely (despite having done this once before). I triple checked my work to see if I would notice some obvious screw up - but nothing is apparent. As far as I can tell, I haven't done anything wrong (and I've checked very closely).
If it's any help, on my end I'm using Cygwin and the server is running Ubuntu 12.04.1 LTS.
Anyways, here is the output (I've removed/censored some parts for privacy (primarily anything with my name, website, or its IP address), but I can assure you that nothing is wrong there):
$ ssh user@host -v
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Connecting to host [ipaddress] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
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 24:68:c3:d8:13:f8:61:94:f2:95:34:d1:e2:6d:e7:d7
debug1: Host 'host' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
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
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/user/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: No more authentication methods to try.
Permission denied (publickey).
What can I do to resolve my problem?
There's a line in there about
Roaming not allowed by server
which is possibly what your problem is. – None – 2012-10-18T04:13:34.333notwithstanding other issues which may exist, you should check the file permissions on your .ssh and .ssh/id_rsa files as well as the dirs between / and .ssh and post them here.
SSH will not accept a key which can be read by others or if .ssh can be written by others – Ben West – 2012-10-18T04:50:39.200
@BenWest As far as I can tell, all my file permissions are as they should be. – Bob – 2012-10-18T08:59:46.463
@RandolphWest What does that mean, and how could I go about resolving it? – Bob – 2012-10-18T09:00:05.637
1The "Roaming not allowed" message is completely unrelated. It refers to a disabled-by-default protocol extension by AppGate (automatic reconnection when client moves networks). – user1686 – 2012-10-18T11:07:01.743
ok, I'm sure they're great. can you post the file permissions. Anytime you get authentication failures for key authentication, you should double check them. – Ben West – 2012-10-18T15:14:31.607
@BenWest As was recommended by all the guides I've read, the file permission for .ssh is
0700/drwx------
and the file permission for authorized_keys is0600/drw-------
. The file permission for /, /home, and /home/user is 755. – Bob – 2012-10-18T19:02:29.490@bob right, what about id_rsa? on your client? – Ben West – 2012-10-19T00:16:51.830
@BenWest id_rsa is 700. – Bob – 2012-10-19T19:22:48.377
ok, that looks right; what about ~/.ssh and ~ – Ben West – 2012-10-21T01:00:29.463