Hello folks at OpenSSH, I recently encountered a behavior of your software (it doesn't really deserve the name of "bug") that may be so rare that it is not worth correcting--however, if it was corrected, it would have saved me many hours of anguish. I recently set up a new PC with Ubuntu 6.10 and connected to my office NIS domain. Unfortunately, when I tried to log in via SSH with my NIS login, I always had my password rejected. I spent a great deal of time trying to make sure that SSH had access to the NIS passwd file. 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. I realize this doesn't happen very often, so it may not be worth inserting, but I thought I would at least put it in your hands. In any case, thank you for writing a program that 99% of the time I don't notice because it works beautifully. Regards, Craig
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. I > realize this doesn't happen very often, so it may not be worth > inserting, but I thought I would at least put it in your hands.First let me say that I am not one of the OpenSSH developers. I am speaking for myself. 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. Did any errors get logged to the syslog with this information? That would be the right place for it. 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. :-) Good Luck! Bob
Possibly Parallel Threads
- GUI/X11 login and shells other than bash?
- GUI/X11 login and shells other than bash?
- Real sh? Or other efficient shell for non-interactive scripts
- issue and solution : samba 4.9.4 and win10 1809 : windows could not connect to user profile service aka the home drive letter semi-colon is missing
- Winbindd Strangeness