Hi,

I have a RHEL 5.5 server.On this server there is an account named test for which I configured public key authentication and I am able to login from a remote server with this user without password.

The problem is when I lock this user with passwd -l or usermod -L ,I can still login from remote server. So it seems these commands only lock the shadow. Is there any way to prevent publickey authentication in this case.

Thanks.

Depends on how you manage user restrictions. If you set them in /etc/ssh/sshd_config you could use {Allow,Deny}{Users,Groups}. Else, if you don't like editing sshd_config each and every time, you could use a "pam_listfile.so onerr=fail item=user sense=deny file=/path/to/deny.file" in the SSH PAM stack and echo all denied user names into "/path/to/deny.file" one account per line.

I use neither of the restrictions you mentioned.
I am in charge of managing many servers with many users. When one user leaves the organisation I lock his/her user by usermod -L or passwd -l but seems it is not enough; because if he configured publickey authentication before he can still login to the server while his account is locked ,please correct me if I am wrong

Sure he can because test is using a separate login system, PKI. And test still has his public key. You need to rename or remove his private key(s) in /home/test/.ssh .

Be advised that it is never a good idea to make certs without a password. I know the point is to make passwordless logins, but don't give just anyone their public key. No one if possible, especially yourself as you are admin. :[

Just out of curiosity are you using ldap, or kerberos for normal auth? Are you making any use of selinux?

1 members found this post helpful.

We are using none of ldap,kerberos,selinux.

The point is users are able to edit their authorized_keys by themselves so after locking them they will be still able to login to the server. So I guess I will move or delete their .ssh directory in addition to locking their account after they left the company

They won't even be able to get in (from their remote client with their public key) if you rename their private key (on the server), so they wouldn't be able to edit their keys.

PKI with no cert password is not a good idea anyway, except in special circumstances like an rsync backup server, or reverse SSH tunnels. Best to do these though with a special user with a login shell of /bin/false .

Interesting. You might want to consider Kerberos if you're managing a number of machines and accounts. It gives centralized control and coherency.

1 members found this post helpful.

As far as managing passwords on keys, that's what "ssh agent" programs are for. You supply the unlocking password for the key once.

Macintosh OS/X is rather nice in that it will conveniently store these passwords in the OS/X "keychain" of your choice. You don't have to remember the random, unguessable string of gobbledygook that is the actual certificate encryption key.

Never use an ssh certificate that is not encrypted.

Well, for certain automated actions over the LAN you pretty much have to make passwordless certs. No alternative. But coupling that with /bin/false shell mitigates, as long as the client machine is secure.

@vahab: I've got a checklist (that I put together years ago) for disabling users:

http://www.daemonforums.org/showthread.php?t=413

The home directory management step I outline there is another way to solve the issue you were experiencing.

1 members found this post helpful.

The following command will effectively deactivate one user (password and SSH key login):

From man passwd: