SSHD Problems on 4210 3.1(5)S58

[jdauncey]

Hi,

SSHD was not working on our sensor today. I logged on through an alternate method and found that SSHD wasn't running. After investigation it was refusing to start because /var/empty had rwx permissions for group and other. However, we had not changed the SSH configuration. We hadn't stopped SSHD, but the sensor may have reset it or rebooted it at some point.

Has anyone else seen this?

Does anyone have any ideas why it happened? Was it related to the S58 update?

I'm quite concerned as nothing that I've done goes near these files.

Thanks,

Joe

[csailer]

Joe,

I have not seen this issue during any of my testing.

One question though, what version was running on the sesnor prior to applying the IDSk9-sp-3.1-5-S58.bin service pack?

Thanks,

Chad

[csailer]

Joe,

One other thing, login to your sensor as root and do a "umask" and send be the output.

Thanks,

Chad

[csailer · Accepted solution]

Joe,

I was able to reproduce the problem by changing the umask of root to 0000. By default, root's umask on the sensor is 0022. My guess is that this was changed on your sensor, either in the during the

session in which the update was installed, by creating a .profile for root, or by modifying the /etc/profile.

Changing the permissions on /var/empty and /var/empty/sshd to 755 will fix the sshd startup problem. I am also going to file a bug against the installer because it really should handle this scenario better.

Thanks,

Chad

[jdauncey]

Chad,

I was previously on 3.1(4)S57

The umask was already 0022 and it's not something that I've changed before. There's no .profile, but the umask does get set to 022 in /etc/profile.

I had started the install through IDM as netrangr. Could that make a difference? umask for netrangr is just 022.

I had already changed the permissions to 700 and it was working fine like that. I've made the permissions change to 755 that you suggested and that all works fine too. I've stopped and restarted SSHD to check.

So, it still seems a bit of a mystery how that happened?

Thanks for your help...

Joe

[jlively]

It turns out IDM is the culprit. DDTS created CSCec89660. If you had logged into the sensor as root and typed IDSk9-sp-3.1-5-S58.bin -I, it would have worked fine.

[khiebert]

FYI. We had the same problem. We use a 4210 IDS and applied service pack 5 to the 3.1(4)S58 configuration and lost SSH. Following the workaround listed in CSCec89660 fixed the problem. I did notice that when I used the IDM to re-enable telnet, after going to the sysconfig-sensor mode, the security level was set to "Unknown". I reset it to "Low", rebooted, and verified the setting was still set to "Low". Then, as a troubleshooting exercise, I reset it to "High" (disabling telnet and ftp) then reused the IDM to re-enable telnet again. After logging back into the sensor as sysconfig-sensor, I found that the security level was set to "Unknown" again. Clearly, the IDM is the source of the problem.

Thanks for the posts as they helped me resolve the same problem I was experiencing on my sensor.