login shell not found "bug"

[Sergio Gelato]

* David Leonard [2007-03-24 13:47:45 +1000]:
> 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.

I concur. Not least because installing /bin/tcsh is the sysadmin's, not
the (remote) user's job. There is no point in disclosing the underlying
details to the end user when (s)he can't fix the problem him/herself
even with that knowledge. The sysadmin can and should read the syslog
as a matter of course, so a message there is enough.
 
> 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

A log message that means what it says. Excellent.

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

Even if the shell is invalid as a result of a configuration error
(by the way, it's also not unheard of for sysadmins to misconfigure
the contents of /etc/shells) only the sysadmin really needs to know
that, not the end user. So sshd doesn't need to guess intentions
(which is good, since mind-reading isn't particularly easy to program).

> Maybe PAM is a better place for an invalid shell check.

Maybe, but changing the shell in order to lock an account is common 
practice. And some operating systems don't have PAM, and some tools 
(e.g. OpenSSH with UsePAM=no) can bypass PAM even when it is available.

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

At many sites, csh (or, more often these days, tcsh) *is* the standard
shell. I give my users a choice of tcsh or bash, but that's mainly
because I prefer bash myself; almost everybody else here uses tcsh.

If you distribute the passwd database through a directory service 
(NIS, LDAP, or whatever) you probably have a documented procedure for
configuring client systems (editing /etc/nsswitch.conf, etc.); make
"apt-get install tcsh" a part of that procedure if tcsh is one of
your supported shells.