I have two laptops (Host A and Host C) with dynamic IP addresses and one desktop (Host B), all of which are running (Ubuntu) Linux. Right now I have things set up so I can access Host A from Host C as follows. I have an ssh tunnel from A to C with the command on hostA of the form

autossh -NR 10023:localhost:22 ohnoplus@hostB.xxx.edu

I am using a key pairing so that this the autossh command can actually happen.

Then I can ssh into B from C and then connect to a with

ssh -p 10023 localhost

promps for a password and I can get in. No problems there.

I would however like to improve the security on A so a key is required for login. So I ssh-keygen a pair of keys on HostB and name my key customkey_rsa and give it a password. Then customkey_rsa.pub is the public key. I can't get ssh-copy-id to work with this tunnel, so I just login to A from C and scp over the customkey_rsa.pub from Host B. Then I append the key with

cd .ssh & cat customkey_rsa.pub >> authorized_keys

Now though, when I try to login, I still get the password prompt. It looks, in fact, like it gets as far as trying the key, but somehow gives up at the last second as below

from B

ssh -v -i customkey_rsa -p 10023 localhost


OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Connecting to localhost [] port 10023.
debug1: Connection established.
debug1: identity file customkey_rsa type 1
debug1: identity file customkey_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH_6.6.1* compat 0x04000000
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5-etm@openssh.com none
debug1: kex: client->server aes128-ctr hmac-md5-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA (redacted)
debug1: Host '[localhost]:10023' is known and matches the ECDSA host key.
debug1: Found key in /home/ohnoplus/.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,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: customkey_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password 
ohnoplus@localhost's password: 

Note, the permissions for ~/.ssh in Host A is 700 and for .ssh/authorized_keys is 600 .

So my question. Why didn't this work, and how can I fix it?

Things I have looked at that haven't helped:

Worked through the suggestions list. The permissions are set correctly on my system and the other solutions do not apply. Why am I still getting a password prompt with ssh with public key authentication?

Similar, but no solution provided: ssh with rsa key asks for password

I do not have an "authorized_keys2" file ssh prompts for password despite .ssh/authorized_keys

  • What is the output of grep AuthorizedKeysFile /etc/ssh/sshd_config? Anything interesting in the server log file / system log? – Hauke Laging Jan 11 '15 at 23:06
  • #AuthorizedKeysFile %h/.ssh/authorized_keys – ohnoplus Jan 13 '15 at 18:27
  • #AuthorizedKeysFile %h/.ssh/authorized_keys (Host C and Host B). Mostly failed login attempts in /var/log/auth.log files from unauthorized users trying to be admin, root or unknown, but I'm not sure what I should be looking for. – ohnoplus Jan 13 '15 at 18:35
  • The problem ist in host A so only the grep output on that host is important. Does your first comment refer to host A? Copy the secret key file to host A and try to log in locally. – Hauke Laging Jan 13 '15 at 18:40
  • For testing purposes you can run a second sshd with different configuration (on a different port) to test changes to the server configuration without the risk to lock yourself out. (This rather belongs to your comment to the answer; I put it here in case the answer gets deleted.) – Hauke Laging Jan 14 '15 at 5:38

You need to add:

PasswordAuthentication no

to your sshd_config (that's the server config)

  • No. Setting this to yes doesn't prevent pubkey authentication, of course. – Hauke Laging Jan 12 '15 at 13:05
  • Yeah, I'd worry that would just lock me out of Host C, if the key authentications don't work. – ohnoplus Jan 13 '15 at 18:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.