login shell not found "bug"

[David Leonard]

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[19155]: 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 
pw_shell).

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.

d

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).