3

I have created a user without a password

$getent passwd logcoll
logcoll:x:998:999:Log Collector,,,:/var/backups/logcoll:/bin/sh

This user has no password, and this machine requires users to login with SSH Keys.

I copied my identity to /var/backups/logcoll/.ssh/authorized_keys. But when I try to login to this machines, I get an error:

ssh -i .ssh/id_rsa logcoll@server  
Permission denied (publickey)

But if create a password for that user with passwd logcoll I can login using the command:

ssh -i .ssh/id_rsa logcoll@data3.

So the question is: how do I enable keybased authentication without setting pam based password for users?

updated

user@localhost:~$ ssh -v -i .ssh/id_rsa logcoll@server
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to user [1x.x.x.21] port 22.
debug1: Connection established.
debug1: identity file .ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file .ssh/id_rsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
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: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 15:13:8b:62:49:ad:5a:01:e6:5f:13:bd:10:c3:c1:28
debug1: Host 'data3' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:16
debug1: ssh_ecdsa_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_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: .ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).
user@localhost:~$ 

The file permissions:

root@server:/var/backups/logcoll#ls -ld .ssh   
drwx------ 2 logcoll logcoll 4096 Dec  1 15:36 .ssh
root@data3:/var/backups/logcoll#ls -ld .ssh/authorized_keys
-rw------- 1 logcoll logcoll 391 Dec  1 15:29 .ssh/authorized_keys
4
  • Will the other way around (disable password authentication via SSH) be enough?
    – muru
    Dec 1, 2014 at 14:40
  • ssh -v (add more v for more info) is your friend. Is the permissions correct on the authorized_keys file? Dec 1, 2014 at 14:46
  • @garethTheRed, I don't see more information that can help me, but I've added the output.
    – oz123
    Dec 1, 2014 at 14:54
  • 3
    Have you checked the logs on the server? Have you checked permissions on the .authorized_keys file? It and it's parent directory should not be writeable by anyone other than the user. Dec 1, 2014 at 15:15

1 Answer 1

4

Well, some info found in my logs:

$ sudo tail -f /var/log/auth.log  
Dec  1 16:17:14 server sshd[31251]: User logcoll not allowed because account is locked 

I removed ! in the shadow entry and replaced it with:

logcoll:NOPASSAUTHALLOWED:16384:0:99999:7:::  

man shadow states:

If the password field contains some string that is not a valid result of crypt(3), for instance ! or *, the user will not be able to use a unix password to log in (but the user may log in the system by other means).

This is exatcly the behaviour I wanted.

3
  • 1
    a) You can do that with passwd -u logcoll, and b) man 1 passwd states: "The user may still be able to login using another authentication token (e.g. an SSH key)", so the behaviour is decidedly odd.
    – muru
    Dec 1, 2014 at 15:26
  • The SSHD man page confirms your approach: “The definition of a locked account is system dependant. (…) a leading ! on most Linuxes). If there is a requirement to disable password authentication for the account while allowing still public-key, then the passwd field should be set to something other than these values (eg NP or *NP*).” Dec 2, 2014 at 15:03
  • @mure, that was the odd behaviour here, despite what man 1 passwd said, I could not login with ssh-key. It says may still be, the authors of sshd, decided otherwise. If an account is locked you can't login, hence, an invalid password is the way to go here.
    – oz123
    Dec 2, 2014 at 15:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .