Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

On localhost running sshd service. Created two pairs of rsa keys for root and user1 using ssh-keygen. Copied from root/.ssh/id_rsa.pub to user1/.ssh/id_rsa.pub. Changed permissions to 600. Tried ssh -l user1 localhost and ssh -l root localhost but both failed with Permission denied (publickey,keyboard-interactive).. Do I have to copy public key to ~/.ssh folder for both users? What is wrong with configuration? Why I cannot connect to localhost?

File /etc/ssh/sshd_config:

RSAAuthentication yes
PubkeyAuthentication yes
PasswordAuthentication yes
UsePAM no
AllowUsers user1 root
PermitRootLogin yes

In file /etc/ssh/ssh_config is uncommented lines:

   RSAAuthentication yes
   PasswordAuthentication no
   ForwardX11 no
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes
    GSSAPIDelegateCredentials no
   PubkeyAuthentication yes

EDIT 1

I am trying to connect to localhost. I have to be able to login to user1 using only public key while possible to login as root with public key and/or password.


EDIT 2

I copied cp ~/.ssh/id_rsa.pub /home/user1/.ssh/authorized_keys. Changed permissions chmod -R 700 ~/.ssh and chmod -R 700 /home/user1/.ssh. Restarted sshd 'service ssh restart'. But it seems not working.


EDIT 4

root@ubuntu:~# ssh-copy-id user1@localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is 34:29:b6:1b:fe:84:eb:82:85:77:87:f6:25:39:61:5a.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
Permission denied (publickey,keyboard-interactive).

root@ubuntu:~# ssh-copy-id root@localhost
Permission denied (publickey,keyboard-interactive).

Log:

# tail /var/log/auth.log

... ubuntu sshd[8476]: User root not allowed because account is locked

A good SSH troubleshot article: Problems and Solutions

share|improve this question
    
Are you trying to ssh to localhost? Why? Did you get password prompt? –  Khaled Apr 22 '12 at 13:50
2  
Have you looked at the server's sshd logs? –  cjc Apr 22 '12 at 14:08

6 Answers 6

I ran into a similar issue a while back try doing a

chmod -R 600 ~/.ssh 

Apparently if the file permissions are right but the directory permissions are not the same kind of permissions error can crop up.

I also think that you need to rename the file from id_rsa.pub to authorized_keys.

share|improve this answer
    
On Debian-6+squeeze3, you will definitely need permission 700 –  zupa May 3 '13 at 15:32

I ran into this issue when i tried to login to an account that has no password, even though i use SSH key pair authentication and have password login turned off. The solution was to set a password using my root account:

passwd user1
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
share|improve this answer
    
In your case, this would have been a PAM accounting issue. UsePAM no is present in this configuration and it would not be applicable. –  Andrew B Apr 4 '13 at 20:53
  1. Whenever encountering a problem ssh'ing to a server, it's always best to add the -v flag, e.g.

    $ ssh -v host -l user
    
  2. In both above cases, the public key (id_rsa.pub) should be added to the "remote user's .ssh/authorized_keys" file. In your case above, both to root and user1. This can easily be done via the ssh-copy-id command.

  3. /var/log/secure will hold clues as to why the login was not successful.

  4. Directory permissions should be 700 [rwx] (not 600) [rw-]

share|improve this answer
    
ssh-copy-id is not working because ssh connection cannot be established. Tried to simply copy public key of user1 to root nevertheless authorization failed. Where should be public key of user1 copied if I need to connect to local host? –  RCola Apr 22 '12 at 15:07
1  
From the log snippet above, appears that the root user is locked, ie in /etc/shadow, there is '!!' in the password file. Give the root user a password - this should unlock the root account. If you'd like user1 to be able to ssh into the system as 'root', add user1 'id_rsa.pub' key to /root/.ssh/authorized_keys. –  rprimus Apr 22 '12 at 15:25

Some notes: Since you have specifically disabled the password authentication, you cannot login with password. I believe that you have to configure the permitted users with some other (Match User is possibly the best way to move forward). Also, you need to specifically allow root user (PermitRootLogin set it to yes).

share|improve this answer

It would make sense to give us some more information about the settings in /etc/ssh/sshd_config, in particular StrictModes (grep StrictModes /etc/ssh/sshd_config). StrictModes is the setting that governs how sensitive sshd reacts to the file and folder permissions of each user's respective ~/.ssh and ~/.ssh/authorized_keys. You also didn't give us the setting of AuthorizedKeysFile in your sshd_config. Very much relevant, if your SSH server is looking for the file somewhere else than you put it.

But aside from the answers so far, there can be a multitude of reasons for this. The problem is that even though you tried, there is not enough information to make a sure guess what's wrong.

One more thing can be PAM restrictions (UsePAM in sshd_config). Ubuntu used to have that at some point. If the user account didn't have a password set (public key only authentication) it wouldn't be allowed in.

But let me give you a generic method to debug such issues.

Generic troubleshooting of sshd

What I find generally very useful in any such cases is to start sshd without letting it daemonize ("go into background and detach from the terminal"). Often the logs won't be overly helpful, in particular when you have a configuration error (which isn't the obvious case at least).

You start it from the terminal like that:

# $(which sshd) -Ddp 10222

This will give you plenty of debug output that would otherwise not appear (without the -d) or end up in the logs if you're lucky.

NB: the $(which sshd) is the best method to satisfy sshd requirement of an absolute path. Otherwise you'll get the following error: sshd re-exec requires execution with an absolute path. The -p 10222 makes sshd listen on that alternative port, overriding the configuration file - this is so that it doesn't clash with potentially running sshd instances. Make sure to choose a free port here.

This method has helped me many many times in finding issues, be it authentication issues, performance issues or other types of issues. To get really verbose output to stdout, use $(which sshd) -Ddddp 10222 (note the added dd to increase verbosity). For more debugging goodness check man sshd.

On the client side ssh can take -v (up to -vvv) to be really verbose about what it is doing.


The log line

... ubuntu sshd[8476]: User root not allowed because account is locked

hints at that being the problem, so run:

sudo passwd -u root
share|improve this answer

On CentOS, selinux can block authentication. To solve the problem using the command:

restorecon -Rv ~ /. ssh
share|improve this answer

Your Answer

 
discard

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.