(Soapbox: Please score the answers according to how effective they are in solving your problem. That's how everyone can later use the scores to find the _best_ solutions.)
OK, it appears that sshd is somewhat broken on your sdapca9 system.
Which is the OS version on that system?
Does the system have an ipfilter or some other packet filter/firewall installed?
A situation where traffic to port 22 is DROPped looks just like your situation.
A packet filter with a very draconian configuration may block localhost traffic too.
Does that system have /dev/random and /dev/urandom?
If it doesn't, sshd should spawn some child processes when it starts up. Those processes gather random number by doing things like "df", "netstat -an", "ps" with various options or "vmstat". (man ssh-rand-helper, then see the ssh_prng_cmds file to find out the commands it runs).
If something causes these child processes to hang, it may prevent sshd from completing start-up. Look for NFS mounts from servers that are unreachable, or disks gone bad in an apparently-infinite retry loop. If you find one of those, fix it first, worry about sshd after that. If you need a work-around, find out the command that's causing trouble and comment it out of ssh_prng_cmds.
If this doesn't help (or if you have /dev/random, making your system almost more resistant to random-number-generation problems), stop all sshd processes and then start sshd in debug mode:
/usr/local/sbin/sshd -d
When you do this, sshd does not become a daemon and it will only accept one connection before stopping. It will also output very much debug information to your session.
Things to check:
- does it output the message "Server listening on [...] port 22"?
- if it does, what happens when someone tries to log in using SSH?
- if it detects the login attempt and goes through the authentication process, does it get to the point where it outputs the message "Entering interactive session [...]"?
MK
