Im trying to set access from ServerA(SunOS) to ServerB(Some custom Linux with Keyboard Interactive login) with SSH Keys. As a proof of concept I was able to do it between 2 virtual machines. Now in my real life scenario it isnt working.

I created the keys in ServerA, copied them to ServerB, chmod'd .ssh folders to 700 on both ServerA,B.

Here is the log of what I get.

    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: Peer sent proposed langtags, ctos:
    debug1: Peer sent proposed langtags, stoc:
    debug1: We proposed langtags, ctos: en-US
    debug1: We proposed langtags, stoc: en-US
    debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
    debug1: dh_gen_key: priv key bits set: 125/256
    debug1: bits set: 1039/2048
    debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
    debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
    debug1: Host 'XXX.XXX.XXX.XXX' is known and matches the RSA host key.
    debug1: Found key in /XXX/.ssh/known_hosts:1
    debug1: bits set: 1061/2048
    debug1: ssh_rsa_verify: signature correct
    debug1: newkeys: mode 1
    debug1: set_newkeys: setting new keys for 'out' mode
    debug1: SSH2_MSG_NEWKEYS sent
    debug1: expecting SSH2_MSG_NEWKEYS
    debug1: newkeys: mode 0
    debug1: set_newkeys: setting new keys for 'in' mode
    debug1: SSH2_MSG_NEWKEYS received
    debug1: done: ssh_kex2.
    debug1: send SSH2_MSG_SERVICE_REQUEST
    debug1: got SSH2_MSG_SERVICE_ACCEPT
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Next authentication method: publickey
    debug1: Trying private key: /XXXX/.ssh/identity
    debug1: Trying public key: /xxx/.ssh/id_rsa
    debug1: Authentications that can continue: publickey,keyboard-interactive
    debug1: Trying private key: /xxx/.ssh/id_dsa
    debug1: Next authentication method: keyboard-interactive

ServerB has pretty limited actions since its a custom propietary linux.

What could be happening?


Problem was that I didnt have those settings enabled in the sshd_config (Refer to accepted answer) AND that while pasting the key from ServerA to ServerB it would interpret the key as 3 separate lines.

What I did was, in case you cant use ssh-copy-id like I couldnt. Paste the first line of your key in your "ServerB" authorized_keys file WITHOUT the last 2 characters, then type yourself the missing characters from line 1 and the first one from line 2, this will prevent adding a "new line" between the first and second line of the key. Repeat with the 3d line.

  • 1
    What's the output of ls -lh ~/.ssh on serverB?
    – miniBill
    Jun 8, 2012 at 15:02

8 Answers 8


I don't think your keys have been properly copied, if you have ssh-copy-id available I would recommend you use that.

$ ssh-copy-id user@remote_server

Once you have entered the password, your SSH key will be copied over and you should be able to just ssh without providing the password again.

Also check your SSH configuration on ServerB and check a couple of things.

$ vi /etc/ssh/sshd_config

Another thing is to check these settings:

RSAAuthentication yes
PubKeyAuthentication yes
AuthorizedKeysFile %h/.ssh/authorized_keys

The value of AuthorizedKeysFile is where you need to paste your public ssh key.

You can collect your SSH-Key information by using: ssh-add -L


When ssh-copy-id doesn't exist you can do the old way:

$ cat ~/.ssh/id_rsa.pub | ssh user@remote_host 'cat >> /home/user/.ssh/authorized_keys'
  • thing is Solaris doesnt have ssh-copy-id :/
    – Rhyuk
    Jun 8, 2012 at 14:36
  • Please see my revised answer - I hope this helps.
    – Ash
    Jun 8, 2012 at 14:47
  • sshd_config from ServerB doesnt have the following values: PubKeyAuthentication yes AuthorizedKeysFlle %h/.ssh/authorized_keys Since I cant write in that file, Ill check that out and get back to you.
    – Rhyuk
    Jun 8, 2012 at 15:05
  • another thing, you could ssh in to ServerB, and tail -f /var/log/auth.log then in another terminal attempt to ssh in via your ssh key. Paste the output of that here, permissions is usually the problem when you connect and immediately get disconnected.
    – Ash
    Jun 8, 2012 at 15:26
  • 1
    ssh-copy-id is a life saver Feb 20, 2018 at 15:59

You should check the permission of the files on the remote machine using ls -l ~/.sshand setup the permission:
chmod 600 ~/.ssh/authorized_keys
chmod 600 ~/.ssh/<private_key> Ex: chmod 600 ~/.ssh/id_rsa
chmod 700 ~/.ssh/<public_key> Ex: chmod 700 ~/.ssh/id_rsa.pub
chmod 700 /home/vmirea/.ssh

  • Based on the output provided in the question it looks like it is only ~/.ssh/authorized_keys that could possibly have incorrect permissions. If any of the other files had incorrect permissions, I would expect an explicit indication of that in the output. It is permitted for the files in ~/.ssh to be world-readable except of course from private keys, which must only be readable to the owner. Write permissions for anybody other than the owner is not permitted, that includes permissions on ~ and ~/.ssh.
    – kasperd
    Oct 27, 2015 at 16:35

Your debug log shows that the server did not accept any of your private RSA keys. You should either specify the specific correct keyfile or check that the server has the right public key file.

As @Fredrik said, permissions on files can also play a role. SSH will refuse to use public key entries that others can write to and private key entries that others can read.


These problems (which are usually permissions related) are much more easily debugged from the server side. I recommend that you start another sshd in debug mode with: /usr/sbin/sshd -d -p 2222 which will start another sshd on port 2222, then run ssh -p 2222 user@sshserver on the client side. Watch what comes out of the sshd when your client tries to authenticate.

Permissions problems don't have to be just /home/$USER/.ssh. it could also be a problem with /, /home, or /home/$USER. If any of those are group writable it can be a problem.

Another common problem is that you mis-paste and put linebreaks in the middle of your key in the authorized_keys file

  • Thanks, Stew ... you solved my problem on HP-UX 11.23, where /home/myname was 0x777 instead of 0x755. Changed to 755, and ssh no longer prompts for a password. Oct 24, 2014 at 22:12
  • Omg thanks man. Best post regarding SSH debugging, I don't understand why noone else has mentioned this. Sep 4, 2018 at 13:16

Based on the above I cannot say what the problem is. However, most of times I've encountered this the reason has been that the keys have had their rights set to be too readable (as in readable to group or other, not just the user). That's where I would start looking.


The easiest way to setup the keys is by running

ssh-copy-id <remotehost>

on the machine that will be connecting (your workstation for example)

It should ask for your password, and then copy your key and setup the permissions appropriately.


Dont forget to have this in ~/.ssh/config

Host *
ForwardAgent yes
# Or
Host yourhost
ForwardAgent yes

In my case I configured StrictModes to from yes to no.

sudo vim /etc/ssh/sshd_config

StrictModes no
  • Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.
    – Community Bot
    Jul 23, 2022 at 5:59

You must log in to answer this question.

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