Hello list,
on a CentOS 6.4 machine I'm creating accounts with empty passwords. Each user's public key is located in <user's home>/.ssh/authorized_keys.
When trying to ssh into that machine, following error message is displayed: Permission denied (publickey).
In /etc/ssh/sshd_config I've set: PasswordAuthentication no UsePAM no
If I set a password for the users, the public key auth works without any problems.
Could anyone tell me what I'm missing here?
Thanks Michael
On Thu, 10 Oct 2013 15:44:36 +0200 Michael Schultz wrote:
UsePAM no
I've never been completely clear on what UsePAM yes versus UsePam no actually does, other than that setting it to no seems to make things a lot more complicated. Perhaps you could try setting it to yes and see if that solves the problem?
On 10 Oct 2013 14:45, "Michael Schultz" m.schultz@srz.de wrote:
on a CentOS 6.4 machine I'm creating accounts with empty passwords. Each user's public key is located in <user's home>/.ssh/authorized_keys.
When trying to ssh into that machine, following error message is
displayed:
Permission denied (publickey).
Check /var/log/secure on the server for more details...
Check the permissions on the file and .ssh directory... Needs to be owned by the user and 600 on the file... This is a very common issue...
Also check context on the file and folder if selinux is enabled.
Thanks everyone,
secure log tells me exactly what the problem is: "User username not allowed because account is locked"
Setting a password for that account unlocks it and ssh works as expected. I guess I have to work on my account creation routine.
Michael
Am 10.10.2013 21:49, schrieb James Hogarth:
On 10 Oct 2013 14:45, "Michael Schultz" m.schultz@srz.de wrote:
on a CentOS 6.4 machine I'm creating accounts with empty passwords. Each user's public key is located in <user's home>/.ssh/authorized_keys.
When trying to ssh into that machine, following error message is
displayed:
Permission denied (publickey).
Check /var/log/secure on the server for more details...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 10/11/2013 12:27 AM, Michael Schultz wrote:
Setting a password for that account unlocks it and ssh works as expected. I guess I have to work on my account creation routine.
you might look into mkpasswd, its probably excessively complicated, but it can set a users password
# mkpasswd -l 20 xyzzy zhRovbjh24hcqrg?xqoF
sets a gnarly 20 character password for the xyzzy user. easy to script.
You are right, that would do the trick when writing a script. But what I'm actually trying to accomplish is creating user accounts with the configuration manager "salt".
In a blog post someone explained how to create users with it and he didn't set a password, so I gave it chance and came across the ssh problem.
Am 11.10.2013 10:14, schrieb John R Pierce:
On 10/11/2013 12:27 AM, Michael Schultz wrote:
Setting a password for that account unlocks it and ssh works as expected. I guess I have to work on my account creation routine.
you might look into mkpasswd, its probably excessively complicated, but it can set a users password
# mkpasswd -l 20 xyzzy zhRovbjh24hcqrg?xqoF
sets a gnarly 20 character password for the xyzzy user. easy to script.
Am 11.10.2013 09:27, schrieb Michael Schultz:
Thanks everyone,
secure log tells me exactly what the problem is: "User username not allowed because account is locked"
Setting a password for that account unlocks it and ssh works as expected. I guess I have to work on my account creation routine.
I haven't tried but maybe you could just try the obvious and unlock the account? I think it is passwd -u [user]
This only works when there's been a password set for the account before locking it. For obvious reasons empty passwords are not allowed :)
Am 11.10.2013 10:58, schrieb Rainer Traut:
Am 11.10.2013 09:27, schrieb Michael Schultz:
Thanks everyone,
secure log tells me exactly what the problem is: "User username not allowed because account is locked"
Setting a password for that account unlocks it and ssh works as expected. I guess I have to work on my account creation routine.
I haven't tried but maybe you could just try the obvious and unlock the account? I think it is passwd -u [user]
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 11.Okt.2013, at 10:58, Rainer Traut wrote:
Am 11.10.2013 09:27, schrieb Michael Schultz:
Thanks everyone,
secure log tells me exactly what the problem is: "User username not allowed because account is locked"
Setting a password for that account unlocks it and ssh works as expected. I guess I have to work on my account creation routine.
I haven't tried but maybe you could just try the obvious and unlock the account? I think it is passwd -u [user]
from the usermod and passwd manual page
... This puts a ´!´ in front of the encrypted password ... ... by prefixing the encrypted string with an ! ...
What I have as an example
/etc/passwd:login:x:10000:10000::/home/login:/bin/bash /etc/shadow:login:!!:15546:0:99999:7:::
and ssh with keys works fine What is in Michaels passwd and shadow? Maybe he does not use shadow passwords and the behaviour is different ?
Another thougt, are there any AVCs in /var/log/audit/audit.log, maybe it is a selinux issue?
Michael?
Am 11.10.2013 14:51, schrieb Markus Falb:
On 11.Okt.2013, at 10:58, Rainer Traut wrote:
Am 11.10.2013 09:27, schrieb Michael Schultz:
Thanks everyone,
secure log tells me exactly what the problem is: "User username not allowed because account is locked"
Setting a password for that account unlocks it and ssh works as expected. I guess I have to work on my account creation routine.
I haven't tried but maybe you could just try the obvious and unlock the account? I think it is passwd -u [user]
from the usermod and passwd manual page
... This puts a ´!´ in front of the encrypted password ... ... by prefixing the encrypted string with an ! ...
What I have as an example
/etc/passwd:login:x:10000:10000::/home/login:/bin/bash /etc/shadow:login:!!:15546:0:99999:7:::
and ssh with keys works fine What is in Michaels passwd and shadow? Maybe he does not use shadow passwords and the behaviour is different ?
Another thougt, are there any AVCs in /var/log/audit/audit.log, maybe it is a selinux issue?
Michael?
My passwd and shadow look like the ones in your example, SELinux is disabled.
I think I'm just going to set account passwords, SSH pubkey auth works that way and it's a lot more secure.
Thank you again for your help everyone, Michael
I question why you want accounts without passwords when logging in via SSH and public keys does not use a password or even ask for one. Also anyone logged in can change users with only an su - <username> and not need a password.
Have you tried setting PASS_MIN_LEN in /etc/login.defs to 0?
Mike
On 10/11/2013 03:27 AM, Michael Schultz wrote:
Thanks everyone,
secure log tells me exactly what the problem is: "User username not allowed because account is locked"
Setting a password for that account unlocks it and ssh works as expected. I guess I have to work on my account creation routine.
Michael
Am 10.10.2013 21:49, schrieb James Hogarth:
On 10 Oct 2013 14:45, "Michael Schultz" m.schultz@srz.de wrote:
on a CentOS 6.4 machine I'm creating accounts with empty passwords. Each user's public key is located in <user's home>/.ssh/authorized_keys.
When trying to ssh into that machine, following error message is
displayed:
Permission denied (publickey).
Check /var/log/secure on the server for more details...
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hello, check permissions on <user's home>/.ssh/authorized_keys. i guess issue related to permissions but i can be wrong
On 10.10.2013, at 15:44, Michael Schultz m.schultz@srz.de wrote:
Hello list,
on a CentOS 6.4 machine I'm creating accounts with empty passwords. Each user's public key is located in <user's home>/.ssh/authorized_keys.
When trying to ssh into that machine, following error message is displayed: Permission denied (publickey).
In /etc/ssh/sshd_config I've set: PasswordAuthentication no UsePAM no
If I set a password for the users, the public key auth works without any problems.
Could anyone tell me what I'm missing here?
Thanks Michael
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
----- Original Message -----
From: "Michael Schultz" m.schultz@srz.de To: centos@centos.org Sent: Thursday, October 10, 2013 6:44:36 AM Subject: [CentOS] SSH login from user with empty password
Hello list,
on a CentOS 6.4 machine I'm creating accounts with empty passwords. Each user's public key is located in <user's home>/.ssh/authorized_keys.
When trying to ssh into that machine, following error message is displayed: Permission denied (publickey).
In /etc/ssh/sshd_config I've set: PasswordAuthentication no UsePAM no
If I set a password for the users, the public key auth works without any problems.
Could anyone tell me what I'm missing here?
Thanks Michael
SSH by default will use a key pair if found but then drops back to login password. It will also fall back to password if the keypair has a passphrase and you just hit retrun without type it in. SSH won't allow you to connect because the password in the shadow file is blank. Basically if you don't have a password it should not allow you to login regardless. From a security standpoint it makes sense to never allow blank passwords. Just give the account a long 25 character random password and then setup SSH key pairs.
David.
On 10/10/2013 03:12 PM, David C. Miller wrote:
SSH by default will use a key pair if found but then drops back to login password. It will also fall back to password if the keypair has a passphrase and you just hit retrun without type it in. SSH won't allow you to connect because the password in the shadow file is blank. Basically if you don't have a password it should not allow you to login regardless. From a security standpoint it makes sense to never allow blank passwords. Just give the account a long 25 character random password and then setup SSH key pairs.
From what I read, it sounds like you are saying that you can't log in with keypairs unless a password has been set. If so, this appears to be incorrect, at least as of CentOS 6. To test this, I did the following:
[root@norman ~]# adduser testnopw [root@norman ~]# su - testnopw [testnopw@norman ~]$ mkdir .ssh && chmod 600 .ssh; [testnopw@norman ~]$ nano .ssh/authorized_keys < - pasted id_dsa.pub from another account -> [testnopw@norman ~]$ chmod 600 .ssh/authorized_keys
Now, as another account on the same server:
[bens@norman] ssh testnopw@localhost Enter passphrase for key '/home/bens/.ssh/id_dsa': [testnopw@norman ~]$
Never, in the above script, was a password set.
----- Original Message -----
From: "Lists" lists@benjamindsmith.com To: centos@centos.org Sent: Thursday, October 10, 2013 3:36:02 PM Subject: Re: [CentOS] SSH login from user with empty password
On 10/10/2013 03:12 PM, David C. Miller wrote:
SSH by default will use a key pair if found but then drops back to login password. It will also fall back to password if the keypair has a passphrase and you just hit retrun without type it in. SSH won't allow you to connect because the password in the shadow file is blank. Basically if you don't have a password it should not allow you to login regardless. From a security standpoint it makes sense to never allow blank passwords. Just give the account a long 25 character random password and then setup SSH key pairs.
From what I read, it sounds like you are saying that you can't log in with keypairs unless a password has been set. If so, this appears to be incorrect, at least as of CentOS 6. To test this, I did the following:
[root@norman ~]# adduser testnopw [root@norman ~]# su - testnopw [testnopw@norman ~]$ mkdir .ssh && chmod 600 .ssh; [testnopw@norman ~]$ nano .ssh/authorized_keys < - pasted id_dsa.pub from another account -> [testnopw@norman ~]$ chmod 600 .ssh/authorized_keys
Now, as another account on the same server:
[bens@norman] ssh testnopw@localhost Enter passphrase for key '/home/bens/.ssh/id_dsa': [testnopw@norman ~]$
Never, in the above script, was a password set.
I just tested this myself and indeed it even works with a key pair that does not have a passphrase. I stand corrected.
David.
-
David C. Miller -
Frank Cox -
Iurii Andamasov -
James Hogarth -
John R Pierce -
Lists -
Markus Falb -
Michael Schultz -
Mike McCarthy -
Rainer Traut