SShD Silently failing -- Need directions, output logs

Caidence · 01-20-2004, 02:23 AM

Very recently, after the reboot before last, my sshd daemon stopped starting as would be appropriate. It *was* working perfectly, but now...

sshd will not start with the init.d script -- at boot time or from command line, or from manual command line starting of the actual sshd daemon. Both actions return absolutely nil. After doing either of these, ps aux returns:

Code:

Dir < /home/caidence >
[catharsis:root]# ps aux
USER       PID %CPU %MEM   VSZ  RSS TTY      STAT START   TIME COMMAND
root         1  0.9  0.0  1484  488 ?        S    02:25   0:06 init [2]
root         2  0.0  0.0     0    0 ?        SW   02:25   0:00 [keventd]
root         3  0.0  0.0     0    0 ?        SWN  02:25   0:00 [ksoftirqd_CPU0]
root         4  0.0  0.0     0    0 ?        SW   02:25   0:00 [kswapd]
root         5  0.0  0.0     0    0 ?        SW   02:25   0:00 [bdflush]
root         6  0.0  0.0     0    0 ?        SW   02:25   0:00 [kupdated]
root         9  0.0  0.0     0    0 ?        SW   02:25   0:00 [khubd]
root       198  0.0  0.1  1532  604 ?        S    02:26   0:00 /sbin/syslogd
root       201  0.0  0.2  2020 1164 ?        S    02:26   0:00 /sbin/klogd
root       212  0.0  0.1  1516  528 ?        S    02:26   0:00 /usr/sbin/inetd
root       221  0.0  0.2  2544 1256 ?        S    02:26   0:00 /bin/sh /usr/bin/mysqld_safe
mysql      261  0.0  1.0 38836 5352 ?        S    02:26   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/m ...
mysql      267  0.0  1.0 38836 5352 ?        S    02:26   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/m ...
mysql      268  0.0  1.0 38836 5352 ?        S    02:26   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/m ...
mysql      269  0.0  1.0 38836 5352 ?        S    02:26   0:00 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/m ...
root       278  0.0  0.4  4832 2056 ?        S    02:26   0:00 /usr/sbin/nmbd -D
root       280  0.0  0.4  6792 2500 ?        S    02:26   0:00 /usr/sbin/smbd -D
root       295  0.0  0.6  4868 3504 ?        S    02:26   0:00 /usr/bin/X11/xfs -daemon
root       370  0.0  0.1  1740  708 ?        S    02:26   0:00 /usr/sbin/cron
root       408  0.0  0.0  1480  472 tty1     S    02:26   0:00 /sbin/getty 38400 tty1
root       409  0.0  0.0  1480  472 tty2     S    02:26   0:00 /sbin/getty 38400 tty2
root       410  0.0  0.0  1480  472 tty3     S    02:26   0:00 /sbin/getty 38400 tty3
root       411  0.0  0.0  1480  472 tty4     S    02:26   0:00 /sbin/getty 38400 tty4
root       412  0.0  0.0  1480  472 tty5     S    02:26   0:00 /sbin/getty 38400 tty5
root       413  0.0  0.0  1480  472 tty6     S    02:26   0:00 /sbin/getty 38400 tty6
telnetd    414  0.0  0.1  1592  608 ?        S    02:27   0:00 in.telnetd: evolution
caidence   415  0.0  0.2  2624 1492 pts/0    S    02:27   0:00 -bash
root       419  0.0  0.3  3080 1968 pts/0    S    02:27   0:00 bash
root       435  0.0  0.1  2848  824 pts/0    R    02:37   0:00 ps aux

Am I missing something...?

The only thing I can get sshd to say is with using sshd -e, which simply says:

Code:

 Dir < /home/caidence >
[catharsis:root]# sshd -e
 Dir < /home/caidence >
[catharsis:root]# daemon() failed: Success

...and promptly quits

So, I tried a clean reinstall. After removing the apt package of sshd, updating and reinstalling, I get the same situation. All configuration files were replaced for a clean install.

Can anyone give me a hint as to where to find sshd outputs/logs?

or, even better, give me an explanation and a fix? I need this server public as soon as possible.

Thank you for checking this post...

Addendum

This particular machine is using Debian's unstable distribution, but there hasn't been any major changes to the system to cause a program failure... The system ran perfectly fine for 8 months straight with no problems.
Demonstrating my network, I can telnet and ftp perfectly with telnetd and vsftpd respectively, from anywhere.
I vaguely remember once having to manually start sshd with the init.d script, but it ran and kept running without a hitch. This time it refuses.

TheRealDeal · 01-20-2004, 05:33 AM

hello

i've never had a problem with sshd. but try running it in debug mode. i got this out of the man page for you. it says it dumps the output to system logs, so i'd try /var/log/messages

-d Debug mode. The server sends verbose debug output to the system
log, and does not put itself in the background. The server also
will not fork and will only process one connection. This option
is only intended for debugging for the server. Multiple -d
options increase the debugging level. Maximum is 3.

good luck

>Craig

Caidence · 01-24-2004, 08:38 PM

Not that anyone would have found this, but the answer lies in /dev/null.

If /dev/null is broken or mishandled (bad permissions), then sshd gets confused and goes back to bed without a word.

In my case, I chmod'ed /dev/null to 666. That's ok, except that it makes /dev/null a normal file rather than a character device. A /dev/null that isn't a character device isn't a /dev/null.

in order to change a device file's permissions, you need to recreate it. You can also create a copy. Get the major and the minor numbers, and the device type.

[quote][catharsis:root]# ls -l null
crw-rw-rw- 1 root root 1, 3 Jan 24 21:19 null/quote]

using the above as an example, the 'c' is the device type (in this case, c), the '1' is the major number, and the minor number is '3'.

It is now possible to do

Code:

[catharsis:root]# mknod --mode=666 null c 1 3

The "mode" is the chmod code you'd normally use in setting a file's pemission's with chmod.

That is all.