Markus Friedl wrote:>
> Subject: Openssh still logs in while passwd is locked
> Date: Wed, 22 May 2002 15:20:08 +0100 (BST)
> From: John Horne <J.Horne at plymouth.ac.uk>
> Organization: University of Plymouth
> To: secureshell at securityfocus.com
>
> Hello,
>
> Using OpenSSH 3.1p1 on a Sun Solaris 7 box, I disabled an account using the
> 'passwd -l ...' command to lock the users password. However, the
user can
> still access the system via ssh. Whilst I could do other things such as
> moving their .ssh directory, removing their account home directory, etc,
> etc, is there some 'nicer' way to inform ssh that the account is
now locked
> and thus to not allow them to login?
It seems this topic should be covered in the FAQ somewhere. I too was
surprized by this behaviour. `passwd -l' locks user's PASSWORD, but not
his ~/.ssh/authorized_keys. I.e. after locking user's password, he will
not be able to log on using other mechanisms (e.g. typing his username
and password at login: prompt on the console), but he may log in to the
machine using ssh and a valid and authorized key. There is nothing wrong
with that. Besides the fact that there MAY be a need for an option that
disallows logins for certain users/accounts based on ~/.ssh/ directory.
Let me draw an example where this may be needed. Imagine a samba server,
where users aren't allowed to log in and use shell prompt, but may use
the server for file/print from their winblows workstations (e.g. using
samba's "encrypted" passwords in /etc/samba/smbpasswd).
Obviously, such
users will have a read-write home directory (e.g. for storing their private
files and windows profiles). And it is pretty possible to create .ssh
directory and place any files within it, including properly formatted
authorized_keys. Now it may be possible to log in and bypass a
"nologin"
restriction. But it is possible IF there is a valid shell listed for their
accounts. I'm not sure if this is the case - will e.g.
ssh remotehost /bin/sh
work if /etc/passwd contains /bin/true or /bin/nologin for a user? Also,
will such users be able to use sftp? If yes, this may be another security
issue as well: using samba it is possible to restrict filesystem visibility,
but with e.g. sftp it is not possible, all the filesystem is available
(with corresponding permissions, but who knows why an administrator may
choose to limit visibility for samba).
/mjt