9

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

Improve this question
2
  • Are you trying to ssh to localhost? Why? Did you get password prompt? Commented Apr 22, 2012 at 13:50
  • 2
    Have you looked at the server's sshd logs? Commented Apr 22, 2012 at 14:08

6 Answers 6

Reset to default
8

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
Improve this answer
2
  • In your case, this would have been a PAM accounting issue. UsePAM no is present in this configuration and it would not be applicable. Commented Apr 4, 2013 at 20:53
  • Andrew B, that's not true. I'm having the same problem: I cannot log in when I set "UsePAM no" when the user in question doesn't have a password. Once I set a password, the login works fine. Commented Sep 25, 2014 at 13:15
4

  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-]

Improve this answer
2
  • 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? Commented Apr 22, 2012 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. Commented Apr 22, 2012 at 15:25
2

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.

Improve this answer
1
  • On Debian-6+squeeze3, you will definitely need permission 700 Commented May 3, 2013 at 15:32
1

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).

Improve this answer
1

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
Improve this answer
1

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

restorecon -Rv ~ /. ssh
Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.