SSH passwordless authentication failure

By Posted on

QUESTION :

I am trying to ssh two machines and I would prefer to use keys generated for authentication rather than password. This will enable me to automate port-forwarding and many other things.

Note: My server is debian.

Below is what I did.

  1. I generated the key:

    ssh-keygen -t dsa

  2. Copied the id_dsa.pub to the remote server’s ~/.ssh

  3. ssh-add -D to delete old keys. Gues I didn’t need them

  4. ssh-add ~/.ssh/id_dsa to add the private id
    5.tried to connect to the external server as

    ssh root@remote-ip

  5. Still settled for password even after my acceptance to be added on known-hosts.
  6. Tried ssh -vvv root@remote-ip and log obtain is posted below.
OpenSSH_5.8p1 Debian-7ubuntu1, OpenSSL 1.0.0e 6 Sep 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 184.154.191.58 [184.154.191.58] port 18765.
debug1: Connection established.
debug1: identity file /home/eclipse/.ssh/id_rsa type -1
debug1: identity file /home/eclipse/.ssh/id_rsa-cert type -1
debug1: identity file /home/eclipse/.ssh/id_dsa type 2
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: identity file /home/eclipse/.ssh/id_dsa-cert type -1
debug1: identity file /home/eclipse/.ssh/id_ecdsa type -1
debug1: identity file /home/eclipse/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.8p1 Debian-7ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [184.154.191.58]:18765
debug3: load_hostkeys: loading entries for host "[184.154.191.58]:18765" from file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: none
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024-1024-8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 125/256
debug2: bits set: 518/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 5d:ce:fb:75:de:6f:52:f9:ad:41:e3:92:9a:53:ee:f0
debug3: put_host_port: [184.154.191.58]:18765
debug3: put_host_port: [184.154.191.58]:18765
debug3: load_hostkeys: loading entries for host "[184.154.191.58]:18765" from file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "[184.154.191.58]:18765" from file "/home/eclipse/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/eclipse/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys
debug1: Host '[184.154.191.58]:18765' is known and matches the RSA host key.
debug1: Found key in /home/eclipse/.ssh/known_hosts:3
debug2: bits set: 514/1024
debug1: ssh_rsa_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: /home/eclipse/.ssh/id_rsa ((nil))
debug2: key: /home/eclipse/.ssh/id_dsa (0x21b20e18)
debug2: key: /home/eclipse/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: password,keyboard-interactive
debug3: start over, passed a different list password,keyboard-interactive
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup keyboard-interactive
debug3: remaining preferred: password
debug3: authmethod_is_enabled keyboard-interactive
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password:

Kindly someone help.

ANSWER :

You put the public key in the wrong place. On the server, allowed keys are stored in the file ~/.ssh/authorized_keys, one key per line. The SSH server ignores all other files in ~/.ssh.

(You can use ssh-copy-id <server> to authorize the key easily.)

Second, did you really run sshd -D and sshd id_dsa? The command is ssh-add:

ssh-add -D
ssh-add ~/.ssh/id_dsa

I’ve spent way too much time debugging passwordless public-key ssh auth over the years, so I wanted to post some suggestions for others who come along:

  • As mgorven posted, make sure file permissions are set correctly on the remote host. This is the most common issue in my experience.
    $ chown -R username:username ~/.ssh
    $ chmod -R 700 ~/.ssh

  • Running ssh from the client with “-v”, “-vv” or “-vvv” has given me a lot of output, but it has NEVER told me what configuration is wrong on the remote machine. It’s probably to prevent evil h4x0rs from getting too much info or something like that.

  • If you have physical (non-ssh) access to the remote machine, you can try stopping the sshd service and manually running sshd with the “-d” flag to output debugging info to the console.

  • Setting up passwordless auth for root is a major security no-no, but if you still want to do it, try setting up a non-root user first. Then if you have problems enabling it for root, you will know that a setting specific to root/sysadmin accounts is responsible.

  • Check if SELinux is enabled. If it is, it may be interfering. Especially if you’re trying to setup passwordless auth for a superuser account.

Hopefully this will save people the hours of frustrating troubleshooting time that ssh has inflicted on the rest of us.

OpenSSH is very anal about file permissions. Make sure that /root/.ssh and everything in it is owned by the correct user, and is only readable and writable by the owner.

chown -R root:root /root/.ssh
chmod -R u=rwX,g=,o= /root/.ssh

If that still doesn’t work, paste the contents of /var/log/auth.log and possibly /var/log/syslog on the server while trying to login.

try 

ssh-copy-id [user@]hostname

you will be prompted once for the password of the remote user, enter that, and you should be on the remote server,
log out and ssh back in. no passwords required.

*also, do check file permissions as mentioned in other answers.

hope it helps

Leave a Reply

Your email address will not be published. Required fields are marked *