Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I've tried to setup a password-less ssh b/w A to B and B to A as well. Generated the public and private key using ssh-keygen -trsa on both the machines. Used the ssh-copy-id utility to copy the public-keys from A to B as well as B to A.

The passwordless ssh works from A to B but not from B to A. I've checked the permissions of the ~/ssh/ folder and seems to be normal.

A's .ssh folder permissions:

-rw-------  1 root root 13530 2011-07-26 23:00 known_hosts
-rw-------  1 root root   403 2011-07-27 00:35
-rw-------  1 root root  1675 2011-07-27 00:35 id_rsa
-rw-------  1 root root   799 2011-07-27 00:37 authorized_keys
drwxrwx--- 70 root root  4096 2011-07-27 00:37 ..
drwx------  2 root root  4096 2011-07-27 00:38 .

B's .ssh folder permissions:

-rw------- 1 root root  884 2011-07-07 13:15 known_hosts
-rw-r--r-- 1 root root  396 2011-07-27 00:15
-rw------- 1 root root 1675 2011-07-27 00:15 id_rsa
-rw------- 1 root root 2545 2011-07-27 00:36 authorized_keys
drwxr-xr-x 8 root root 4096 2011-07-06 19:44 ..
drwx------ 2 root root 4096 2011-07-27 00:15 .

A is an ubuntu 10.04 (OpenSSH_5.3p1 Debian-3ubuntu4, OpenSSL 0.9.8k 25 Mar 2009) B is a debian machine (OpenSSH_5.1p1 Debian-5, OpenSSL 0.9.8g 19 Oct 2007)

From A:

#ssh B

works fine.

From B:

#ssh -vvv A 
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /root/.ssh/identity ((nil))
debug2: key: /root/.ssh/id_rsa (0x7f1581f23a50)
debug2: key: /root/.ssh/id_dsa ((nil))
debug3: Wrote 64 bytes for a total of 1127
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,gssapi,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/identity
debug3: no such identity: /root/.ssh/identity
debug1: Offering public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 368 bytes for a total of 1495
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /root/.ssh/id_dsa
debug3: no such identity: /root/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@'s password: 

Which essentially means it's not authenticating using the file /root/id_rsa. I ran the ssh-add command in both the machines as well.

the contents /etc/ssh/sshd_config are:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

I'm running out of ideas. Any help would be appreciated.

share|improve this question
What is SSH daemon config on A ? – Kristaps Jul 27 '11 at 6:29
@Kristaps, I've posted the whole of /etc/ssh/sshd_config file in the question itself – Cuurious Jul 27 '11 at 6:51
Just to be clear--you are trying to ssh as root@A to root@B and vice-versa? – Bryan Agee Jul 27 '11 at 7:00
if you have, it hasnt posted it to the question – Sirex Jul 27 '11 at 7:02
@Bryan Agee, I'm trying to ssh as root@A as well as root@B – Cuurious Jul 27 '11 at 7:20

3 Answers 3

up vote 0 down vote accepted

Note the different permissions on the root directory and /root/.ssh/ from A and B.

On B try: chmod o-rx /root;chmod go-r /root/.ssh/ then try again.

share|improve this answer
@dmorurati, I'm still not able to login w/o password – Cuurious Jul 27 '11 at 8:40
@dmourati: I could be wrong about this but I think it's the other way around: file-folder permissions on B are correct, on A they appear wrong (imho). As far as I know the pub keys should be world-readable. That is what public implies isn't it :-) – Tonny Jul 27 '11 at 9:38
@Tonny, I thought the public key would be verified through the key copied to authorized_keys (which could be copied through ssh-copy-id`). So I assumed it is independent of the permissions to – Cuurious Jul 27 '11 at 9:59

Are you absolutely sure that the correct public keys are in the right place? Check that there is an entry in A's authorized_keys file that matches on B.

The permissions look OK. The fact that on A is inaccessible to any other users is of no consequence in this context (even though it is strange and unsual).

I would also change permissions for the .ssh folder on A so that they match the permissions on B (which are correct).

share|improve this answer

This is almost certainly an issue with the formatting of your public keys in the authorized_keys file.

Check that there are no line breaks in the public keys (the key should all be on one line), and that there are no omitted characters.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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