-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I am having an odd problem with OpenSSH sshd on FC3. I am asking about the problem here because I think the problem may be outside of sshd itself. In the end, I am sure I have caused the problem myself, but am hoping someone else has seen it.
Symptoms: sshd rejects all users but one (my account) with "*user* rejected because not in AllowUsers". This message appears in /var/log/secure. When logging in with ssh, it asks for and appears to reject the password (even though a public key is configured). The funny thing is that AllowUsers is *empty*.
Background: When I installed the server, I immediately created a new user account, added it to AllowUsers, and turned off root login. I reloaded the server (service reload sshd) and began connecting as this user. It worked. Root was, correctly, denied. Now I have added more accounts and wish to allow login for some of them. In fact, I want to allow all users and let the shell setting disallow the users it should (shell=/dev/null). Most of the users have been created by Webmin/Virtualmin. Two were created with useradd at the prompt (including the one that *is* allowed to ssh).
At first, I went into Webmin and added another user to the AllowUsers list and saved it. No effect. I verified that I have set the user's shell (/bin/zsh,which is in /etc/shells). I forced a reload of sshd. I verified that the AllowUsers field had been updated in /etc/ssh/sshd_config.
Next, I went back to Webmin/SSH module and set it to allow all logins (the ones I do not want have shells set to /dev/null). I looked at sshd_config and verified that AllowUsers had been removed from the file (the man page says that it defaults to allow all). No good. I reloaded sshd and still no good.
The original user account is still let in. No new account, whether created in Webmin or by useradd can log in. The original account has its personal group and wheel. Of the other accounts being rejected, at least one is also in wheel. I do not see any other related messages in the logs.
I have also tried setting AllowUsers to "*" and I have tried replacing the *original config file* from the RPM with *no change*.
Questions: 1) Why is sshd not allowing all users with an empty AllowUsers? 2) If it is not defaulting to allow all, why let the original account in? 3) Why did the original config file not reset the behavior (!)?
I am forced to conclude that sshd is simply not reading /etc/ssh/sshd_config, though it is reloading (I get disconnected each time) and I can find no other file on the system which it might be reading instead. In particular, I have gone through every file on the system in which the original account name appears looking for a ghost allow list somewhere with no result. Now I am getting very confused.
- -- - -------------- Eric Vought
Technical Director, Diversity Ink Morgan Family Enterprises
On Wed, 2 Feb 2005, Eric Vought, Technical Director wrote:
Symptoms: sshd rejects all users but one (my account) with "*user* rejected because not in AllowUsers".
Maybe not releated - but I thought I'd sugest anyway..
Once I had problem with adding new users with 'system-config-users'. However I could add with 'adduser' - but ssh whouldn't accept the passwd.
The thing that resolved this issue for me was running 'system-config-securitylevel' - in the 'Selinux' tab, disabling Selinux - and then re-enabling it again.
Satish
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Satish Balay wrote: | On Wed, 2 Feb 2005, Eric Vought, Technical Director wrote: | | |>Symptoms: |>sshd rejects all users but one (my account) with "*user* rejected |>because not in AllowUsers". | | | Maybe not releated - but I thought I'd sugest anyway.. | | Once I had problem with adding new users with | 'system-config-users'. However I could add with 'adduser' - but ssh | whouldn't accept the passwd. | | The thing that resolved this issue for me was running | 'system-config-securitylevel' - in the 'Selinux' tab, disabling | Selinux - and then re-enabling it again. | | Satish | That's interesting ... it may be related. Does SELinux cache the inodes of configuration files? In other words, if I used an editor which does a create-and-rename for saving files, would sshd be rendered incapable of reading its own configuration?
- -- - -------------- Eric Vought
Technical Director, Diversity Ink Morgan Family Enterprises
On Wed, 2 Feb 2005, Eric Vought, Technical Director wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Satish Balay wrote: | On Wed, 2 Feb 2005, Eric Vought, Technical Director wrote: | | |>Symptoms: |>sshd rejects all users but one (my account) with "*user* rejected |>because not in AllowUsers". | | | Maybe not releated - but I thought I'd sugest anyway.. | | Once I had problem with adding new users with | 'system-config-users'. However I could add with 'adduser' - but ssh | whouldn't accept the passwd. | | The thing that resolved this issue for me was running | 'system-config-securitylevel' - in the 'Selinux' tab, disabling | Selinux - and then re-enabling it again. | | Satish | That's interesting ... it may be related. Does SELinux cache the inodes of configuration files? In other words, if I used an editor which does a create-and-rename for saving files, would sshd be rendered incapable of reading its own configuration?
I think it was more of - due bad attributes (related to selinux) some files were not getting modified (or read correctly). Don't know how I landed in that bad state though.. It could just be one of the many kernel oops (resulting in hard reboots) I've had due to APM not working well with FC3 kernels.
Satish
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric Vought, Technical Director wrote: | Satish Balay wrote: | | On Wed, 2 Feb 2005, Eric Vought, Technical Director wrote: | | | | | |>Symptoms: | |>sshd rejects all users but one (my account) with "*user* rejected | |>because not in AllowUsers". | | | | | | Maybe not releated - but I thought I'd sugest anyway.. | | | | Once I had problem with adding new users with | | 'system-config-users'. However I could add with 'adduser' - but ssh | | whouldn't accept the passwd. | | | | The thing that resolved this issue for me was running | | 'system-config-securitylevel' - in the 'Selinux' tab, disabling | | Selinux - and then re-enabling it again. | | | | Satish | | | That's interesting ... it may be related. Does SELinux cache the inodes | of configuration files? In other words, if I used an editor which does a | create-and-rename for saving files, would sshd be rendered incapable of | reading its own configuration? | Well, it looks like SELinux cannot be the problem. sshd is running unconfined; it is not in the 'targetted' policy.
- -- - -------------- Eric Vought
Technical Director, Diversity Ink Morgan Family Enterprises
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Eric Vought, Technical Director wrote: | Eric Vought, Technical Director wrote: | | Satish Balay wrote: | | | On Wed, 2 Feb 2005, Eric Vought, Technical Director wrote: | | | | | | | | |>Symptoms: | | |>sshd rejects all users but one (my account) with "*user* rejected | | |>because not in AllowUsers". | | | | | | | | | Maybe not releated - but I thought I'd sugest anyway.. | | | | | | Once I had problem with adding new users with | | | 'system-config-users'. However I could add with 'adduser' - but ssh | | | whouldn't accept the passwd. | | | | | | The thing that resolved this issue for me was running | | | 'system-config-securitylevel' - in the 'Selinux' tab, disabling | | | Selinux - and then re-enabling it again. | | | | | | Satish | | | | | That's interesting ... it may be related. Does SELinux cache the inodes | | of configuration files? In other words, if I used an editor which does a | | create-and-rename for saving files, would sshd be rendered incapable of | | reading its own configuration? | | | Well, it looks like SELinux cannot be the problem. sshd is running | unconfined; it is not in the 'targetted' policy. | OK, the problem is that service sshd reload and service sshd restart are not working. They are SIGHUPping the wrong process IDs. I figured this out when I realized that not all of my ssh sessions were closing when I reloaded the configuration. The session which was closing was the one which was mistakenly shut down by service sshd reload/restart.
When I HUP the process myself, everything suddenly works.
- -- - -------------- Eric Vought
Technical Director, Diversity Ink Morgan Family Enterprises
On Wed, 2005-02-02 at 20:17 -0600, Eric Vought, Technical Director
OK, the problem is that service sshd reload and service sshd restart are not working. They are SIGHUPping the wrong process IDs. I figured this out when I realized that not all of my ssh sessions were closing when I reloaded the configuration. The session which was closing was the one which was mistakenly shut down by service sshd reload/restart.
When I HUP the process myself, everything suddenly works.
If true, this would be a bug. Stop has stop() { echo -n $"Stopping $prog:" killproc $SSHD -TERM ...
and restart has stop() start(). Could you please test more? init.d script looks ok to me.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marius Andreiana wrote: | On Wed, 2005-02-02 at 20:17 -0600, Eric Vought, Technical Director | |>OK, the problem is that service sshd reload and service sshd restart are |>not working. They are SIGHUPping the wrong process IDs. I figured this |>out when I realized that not all of my ssh sessions were closing when I |>reloaded the configuration. The session which was closing was the one |>which was mistakenly shut down by service sshd reload/restart. |> |>When I HUP the process myself, everything suddenly works. | | If true, this would be a bug. Stop has | stop() | { | echo -n $"Stopping $prog:" | killproc $SSHD -TERM | ... | | and restart has stop() start(). | Could you please test more? init.d script looks ok to me. | | It is true. It is signaling *an* sshd instance, but not the primary. That is why my connection gets killed and the config file is not read. I have not had a chance to track down 'killproc' yet, but it is on my list. If it essentially goes through a psgrep to find the process, that could underlie the problem. I have to be somewhat cautious in playing here since it is a remote machine and I do not have physical access if I end up shutting down ssh.
- -- - -------------- Eric Vought
Technical Director, Diversity Ink Morgan Family Enterprises
On Thu, 2005-02-03 at 11:20 -0600, Eric Vought, Technical Director wrote:
It is true
Could you please file a bug at bugzilla.redhat.com and let us know the #? Thanks!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Marius Andreiana wrote: | On Wed, 2005-02-02 at 20:17 -0600, Eric Vought, Technical Director | |>OK, the problem is that service sshd reload and service sshd restart are |>not working. They are SIGHUPping the wrong process IDs. I figured this |>out when I realized that not all of my ssh sessions were closing when I |>reloaded the configuration. The session which was closing was the one |>which was mistakenly shut down by service sshd reload/restart. |> |>When I HUP the process myself, everything suddenly works. | | If true, this would be a bug. Stop has | stop() | { | echo -n $"Stopping $prog:" | killproc $SSHD -TERM | ... | | and restart has stop() start(). | Could you please test more? init.d script looks ok to me.
OK, sorry this has taken some time to follow up. I needed time to fiddle with the system some more in order to write a good bug report.
The problem is no longer reproducible after a reboot. It looks like /var/run/sshd.pid may have gotten corrupted in some manner, which was fixed when the system came back up (unrelated upgrade).
I am extremely reluctant to muck further with a production server, but have a local FC3 box to break now. The odd thing is that I can only reproduce the behavior when the content of the .pid file is *wrong* not merely non-existant or empty. If the file is missing or empty, killproc falls back to using pidof to return all sshd processes, not just the first found, which would have (and does) work correctly. Further, I know from an IDS log that the file did exist and was non-empty. I cannot, at the moment, think of how the pidfile corruption could plausibly occur, and, in any case, it is probably not FC3's fault.
To sum: I do not think there is enough to open a bug. Chalk one up to poltergiests.
- -- Eric Vought
Technical Director, Diversity Ink, Morgan Family Enterprises Web Hosting and Site Design for Small Business and Not-for-Profit (http://www.diversityink.com)
-
Eric Vought -
Marius Andreiana -
Satish Balay