On both source and target servers ensure these permissions exist:
$ chmod go-w ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/id_rsa
$ chmod 644 ~/.ssh/id_rsa.pub
$ chmod 644 ~/.ssh/known_hosts
It didn't work for me in one case where $HOME directory had 777 permission
Looking at /var/log/auth.log on my server revealed the problem: sshd was
refusing to use my public key because my home directory was
group-writable. In order to do pubkey auth, both the home directory
and the .ssh directory must writable only by the owner.
Two parts: first, turn up debugging on your ssh sever. Edit /etc/ssh/sshd_config and increase LogLevel to DEBUG. Then force your ssh server to reload it's config with killall -HUP.
That will cause the server to add much more details to your /var/log/secure and/or /var/log/auth logfiles.
Secondly (actually you cant try this first), increase the debug level on the client side. ssh in to the box with
$ ssh -vvv hostname
and that will print out lots more info about where the process is failing.
If you do turn up the debug level on your ssh server, don't forget to turn it back down when you are finished.
A few more reasons why this fails:
1. Make sure the owner:group on the directories and files is correct:
ls -ld $HOME/
ls -ld $HOME/.ssh
ls -ltr $HOME/.ssh
Login as root
chown user:group $HOME
chown user:group $HOME/.ssh
chown user:group $HOME/.ssh/authorized_keys
chown user:group $HOME/.ssh/id_rsa
chown user:group $HOME/.ssh/id_rsa.pub
chown user:group $HOME/.ssh/known_hosts
2. This one took a lot of R&D. The user's entry was missing in /etc/shadow
Login as root
grep user /etc/shadow
If user doesn't exist in /etc/shadow, ssh will fail.
This is caused, because unix admins sometimes do not use useradd command to add users, they just copy the line from /etc/passwd from an existing server and paste it in new server. They forget to add the line for the user inside /etc/shadow. If useradd command is used, it takes care of this automatically.
$ chmod go-w ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
$ chmod 600 ~/.ssh/id_rsa
$ chmod 644 ~/.ssh/id_rsa.pub
$ chmod 644 ~/.ssh/known_hosts
It didn't work for me in one case where $HOME directory had 777 permission
Looking at /var/log/auth.log on my server revealed the problem: sshd was
refusing to use my public key because my home directory was
group-writable. In order to do pubkey auth, both the home directory
and the .ssh directory must writable only by the owner.
Two parts: first, turn up debugging on your ssh sever. Edit /etc/ssh/sshd_config and increase LogLevel to DEBUG. Then force your ssh server to reload it's config with killall -HUP
That will cause the server to add much more details to your /var/log/secure and/or /var/log/auth logfiles.
Secondly (actually you cant try this first), increase the debug level on the client side. ssh in to the box with
$ ssh -vvv hostname
and that will print out lots more info about where the process is failing.
If you do turn up the debug level on your ssh server, don't forget to turn it back down when you are finished.
ls -ld $HOME/
ls -ld $HOME/.ssh
ls -ltr $HOME/.ssh
Login as root
chown user:group $HOME
chown user:group $HOME/.ssh
chown user:group $HOME/.ssh/authorized_keys
chown user:group $HOME/.ssh/id_rsa
chown user:group $HOME/.ssh/id_rsa.pub
chown user:group $HOME/.ssh/known_hosts
2. This one took a lot of R&D. The user's entry was missing in /etc/shadow
Login as root
grep user /etc/shadow
If user doesn't exist in /etc/shadow, ssh will fail.
This is caused, because unix admins sometimes do not use useradd command to add users, they just copy the line from /etc/passwd from an existing server and paste it in new server. They forget to add the line for the user inside /etc/shadow. If useradd command is used, it takes care of this automatically.
No comments:
Post a Comment