Tom H wrote: > David Guntner wrote: > > Of course, I'm a LONG-time UNIX user/admin, and back in the day, setting > > the login shell that way was pretty much the way to do it. As someone > > else here pointed out, doing a "passwd -l" doesn't actually *disable* > > the account and allows someone who's using a key instead of a password > > to get in. Setting their login shell to /bin/false (and later, with the > > addition of /usr/sbin/nologin on Linux system to give the user a message > > before hanging up) does that nicely - they're not getting in with a key, > > either. I had thought that using ssh with keys allowed a way through the /bin/false way, perhaps at some time in the past, but testing just now proved otherwise. AFAICT by experimentation setting /bin/bash does block all account access. By all I mean ssh login, ssh command, scp, sftp, (plus rsync). Mostly they just silently exited 1. Although an account disabled that way is not quite the same as not having an account at all. A point which will be important to some people that information is not leaked. Setting nologin is somewhat friendlier in that it emits a message saying "This account is currently not available." For all of the embedded protocols such as scp, sftp, rsync the extra text causes protocol errors. Received message too long 1416128883 protocol error: mtime.sec not delimited rsync: connection unexpectedly closed (0 bytes received so far) [Receiver] rsync error: error in rsync protocol data stream (code 12) at io.c(605) [Receiver=3.0.9] protocol version mismatch -- is your shell clean? (see the rsync man page for an explanation) Those might be more confusing. But for a disabled account it doesn't really matter. > > I can't recall, however, if that would keep them from > > connecting via (S)FTP (since there's no actual login shell being > > invoked). Probably need to test that.... > > AFAIR sftp will work when the shell's "/usr/sbin/nologin" or > "/bin/false" if you use "internal-sftp" as the sftp server. I did not test internal-sftp but the default sftp-server is blocked by setting either /bin/false or /usr/sbin/nologin. I presume because they are not valid /etc/shells. > >> You don't have to edit "/etc/passwd" to change shells to nologin. You > >> can use "chsh" as long as nologin is a recognized shell. > > > > Sure, that works, too - however, you'll have to edit /etc/shells to > > include /bin/false and/or /usr/sbin/nologin, 'cause those aren't "valid" > > login shells by default. That restriction does not apply for root. And traditionally the ftp server for one used the presence of the user specified shell in /etc/shells to indicate whether ftp was allowed to log into the system. (I presume sftp may operate similarly by implication. Don't know.) Therefore *do not* add either of those to /etc/shells or it may open up an account to a service such as ftp (hopefully no one is running user authenticated passwords in the clear ftp anymore, anonymous ftp for distribution is fine) when the desire was the opposite. > That's why I said "recognized shell." Root can always change the shell to anything. The restriction is only for user's to change their own shell. Bob
Attachment:
signature.asc
Description: Digital signature