Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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_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?

share|improve this question
There's a line in there about Roaming not allowed by server which is possibly what your problem is. – user3463 Oct 18 '12 at 4:13
notwithstanding 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 Oct 18 '12 at 4:50
@BenWest As far as I can tell, all my file permissions are as they should be. – Bob Oct 18 '12 at 8:59
@RandolphWest What does that mean, and how could I go about resolving it? – Bob Oct 18 '12 at 9:00
The "Roaming not allowed" message is completely unrelated. It refers to a disabled-by-default protocol extension by AppGate (automatic reconnection when client moves networks). – grawity Oct 18 '12 at 11:07

I get that output when I try to log in as a dummy user that doesn't exist on the target machine, or the key isn't in the .ssh/authorized_keys file on the target machine. Are you sure 'user' exists and that your key is in the .ssh/authorized_keys file on the target machine? Have you tried ssh-copy-id?

share|improve this answer
I can verify that the 'user' does exist and the key is in the .ssh/authorized_keys file on the target machine. – Bob Oct 18 '12 at 8:12

After much consideration, I decided it would be best to just delete authorized_keys and instead of doing it manually, just use ssh-copy-id to get the key on to the server. It seemed to work perfectly.

share|improve this answer
You should selectr own answer as the correct one if it resolved your issue. – Ben West Dec 29 '12 at 13:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .