login shell not found "bug"
David.Leonard at quest.com
Sat Mar 24 14:47:45 EST 2007
Bob Proulx wrote:
> Craig Bookwalter wrote:
>> It turned out that the problem was that my default login shell in
>> the NIS passwd file was tcsh, and Ubuntu 6.10 does not come with
>> tcsh installed by default. It would have been wonderful if SSH could
>> have told me that the reason my login was failing was that my login
>> shell didn't exist, rather than just rejecting my password.
> Did any errors get logged to the syslog with this information? That
> would be the right place for it.
There would have been this kind of entry in the server logs:
Mar 24 09:59:16 somehost sshd: User testuser not allowed because
shell /bin/doesntexist does not exist
sshd's allowed_user() function is noticing that the shell doesn't exist,
so it vetoes the authentication.
(sshd(8)'s section on 'AUTHENTICATION' doesn't mention this check.)
> Using a shell that is non-existent is a common way for admins to
> disable accounts. I don't know if sshd would have logged any
> information to the syslog about it or not but returning an indication
> to the user would probably be a security badness. Because then an
> attacker would learn something about the account, that the account
> existed but that the shell did not. That might give an attacker
> information that could be used to advantage in breaking into the
> system in another way. The usual wisdom is give no system information
> to an unauthorized user. Therefore probably sshd cannot actually say
> why the login is failing to the user logging into the system.
If you believe that invalid shell = disabled account, the question here
is then: how can sshd's allowed_user() function know if an account's
shell is /intentionally/ invalid or not? Some systems provide an
/etc/shells list. Perhaps sshd should scan that list and continue if
pw_shell is in that list? Leaking an error message (/bin/tcsh: No such
file or directory) is then bad.
Maybe PAM is a better place for an invalid shell check.
But I think invalid shell = disabled account is wrong wisdom. ('invalid'
meaning that the shell doesn't exist or maybe isn't executable) I
suspect that it is a widespread belief though. If you reject that
belief, then printing "/bin/tcsh: No such file or directory" doesn't
leaking any information. It also means that allowed_user() has no
business looking at the pw_shell field.
The existence of /sbin/nologin is an example where this won't work. I
think it's a fallback for tools that bypass authentication (eg su). And
in the case of FTP and other desirable non-shell network access, I think
that PAM is a much better way to control access (instead of through
So, if sshd's allowed_user()'s behaviour were changed to ignore
pw_shell, then an account with an invalid shell would be allowed to do
some non-session things, like port forwarding (this is currently the
case when the shell is set to /sbin/nologin but the password is left
valid). but the best part is that the authenticated user would get some
information about why their session isn't working (/bin/tcsh: No such
file or directory) This seems consistent to me.
> This probably won't make you feel any better about it but perhaps it
> does explain the situation a little more. (And also that perhaps it
> is time to think about switching to a more standard shell. :-)
My preferred shell is ksh .. I have hit the same problem on newly
installed systems in an environment where invalid shell != disabled
account, so I would benefit from a better error message because I am
otherwise a properly authenticated user.
PS: I haven't found any definitive documentation, but on this topic,
OpenBSD's passwd(5) says:
By convention, accounts that are not intended to be logged in to
(e.g. bin, daemon, sshd) have a star (`*') in the password field.
[...and] usually have a shell of /sbin/nologin.
and SuSE Linux passwd(5) says:
If [the shell field is] set to a non-existing executable, the user
will be unable to login through login(1). [...]
If the encrypted password is set to a star, the user will be unable
to login using login(1), but may still login using rlogin(1), run
existing processes and initiate new ones through rsh(1), cron(1),
at(1), or mail filters, etc. Trying to lock an account by simply
changing the shell field yields the same result and additionally
allows the use of su(1).
More information about the openssh-unix-dev