I tried to use public key authentication on my new server, and I came across this problem.

$ ssh -v -i .ssh/server
OpenSSH_5.6p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data .ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to [] port 22.
debug1: Connection established.
debug1: identity file .ssh/server type -1
debug1: identity file .ssh/server-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1 Debian-1ubuntu3
debug1: match: OpenSSH_5.8p1 Debian-1ubuntu3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.6
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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '' is known and matches the RSA host key.
debug1: Found key in .ssh/known_hosts:1
debug1: ssh_rsa_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: Trying private key: .ssh/server
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

and then I have to input my password to get logged in.

But, if I already have one session connected to that server (which is connected by password), then the following connection uses key auth to avoid password input.

If there is no SSH connection already established, I can't connect without input password.

This is really weird to me, I checked the MD5 of /usr/sbin/sshd between the new server and the other normal server, it's the same. Then I just copied the /etc/ssh/sshd_config from the other normal server to the new server, and ran service ssh restart. The problem still exists.

How am I supposed to fix this?


Check that your .ssh folder and the files inside it on the client machine are only readable by the owner (chmod -R 600 .ssh) and that the owner is correct for the folder and files (use chown command if necessary).

Also check the authorized_keys folder and file on the server (probably in /root/.ssh or the home folder of the user trying to login) to make sure their permissions and owner are set in the same way.

Edit: based on more feedback (and some guesswork!) - can you check /etc/ssh/sshd_config and see whether the following parameter is set like below. If not, try editing it.

AuthorizedKeysFile /home/%u/.ssh/authorized_keys

Note, this assumes you don't login remotely as root

|improve this answer|||||
  • my .ssh is 700 and files in .ssh is 600, and I double checked ~/.ssh/authorized_keys in remote machine. Setup public key auth is the first thing I do after I install the system, so it's not likely to be messed up by other operation. btw, problem still.. – lxyu Aug 23 '11 at 10:58
  • OK - I am adding something to my answer based on this. – Linker3000 Aug 23 '11 at 11:55
  • there is a line of "#AuthorizedKeysFile %h/.ssh/authorized_keys". I tried comment it out, but of no use.. btw, the same '/usr/sbin/sshd' with the same 'sshd_config', how the they behave differently? – lxyu Aug 23 '11 at 13:13
  • Finally I reinstalled ubuntu, then I set up openssh-server in one minute and it working fine now... Still don't know what's wrong. :( – lxyu Aug 23 '11 at 17:24
  • Sometimes it is really difficult to find out what's the problem. I once mispelled authorized_keys as auhorized_keys. I needed about one hour to troubleshoot this. Did you see the mispelling? It is really tricky! :-) – nalply Feb 24 '12 at 14:00

I fixed my own case of this error by removing id_rsa.pub from .ssh.

I had copied id_rsa from another machine and distributed it across several dummy clients. Therefore, id_rsa and id_rsa.pub were actually different keys which prevented the usage of id_rsa altogether.

No error message to clearly indicate this though. I figured it out essentially by accident, trying to get the different machines into an identical state.

|improve this answer|||||

From my finding, the least permission of the target's home director is 750. If the world's bit is not 0, it will not work.

Eg. for root's directory:

drwxr-x--- 3 root root 4096 Jul 20 11:57 root

Next is /root/.ssh

drwx------  2 root root  4096 Jul 17 03:28 .ssh

Then /root/.ssh/authorized_keys

-rw------- 1 root root 1179 Jul 17 03:28 authorized_keys
|improve this answer|||||

In my case the permissions on the home directory were 775 instead of 0755 or lower.

The entire path to authorized_keys file, i.e. /home/user/.ssh/ must be 0755 or lower.

|improve this answer|||||
  • THANK YOU This just got read of a headache I've had for a week now. Most people only mention the .ssh folder (700) and the authorized_keys (600) – Jonathan Komar Oct 7 '15 at 17:49

After troubling a lot I got the solution of the problem:

Home directory of the user should not have permission 777 or world writable. If it is the case, SSH key verification will fail and you have to put password for login.

|improve this answer|||||

Just make sure the account you are trying to ssh to is a user with a password on the remote server. I just banged my head on the wall for half an hour before finding this answer here: https://stackoverflow.com/a/14421105/758174

|improve this answer|||||

If your /etc/ssh/sshd_config has the following line un-commented, then your SSH configuration only allows a fixed list of users to ssh into the system, and you need to add any new accounts to the list:

AllowUsers root user1 user2 user3

Any other users than the ones listed above trying to login via SSH would receive this cryptic error messages:

Roaming not allowed by server
|improve this answer|||||

I found out that after changing my user and group name (but not IDs) in /etc/passwd and /etc/group, but forgetting to change /etc/shadow accordingly, I got the same "No roaming allowed" message.

|improve this answer|||||

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.