Any ideas on how to solve the following problem.
hamilton is shown as ssh ok, status unchanged for a week, but you can't ssh in:
% ssh -v hamilton OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to hamilton [128.210.3.42] port 22. debug1: Connection established. debug1: identity file /homes/jflack/.ssh/identity type -1 debug1: identity file /homes/jflack/.ssh/id_rsa type -1 debug1: identity file /homes/jflack/.ssh/id_dsa type -1 debug1: loaded 3 keys debug1: Remote protocol version 1.99, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH_3.* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.3 debug1: SSH2_MSG_KEXINIT sent Read from socket failed: Connection reset by peer
Apparently something goes wrong in the server just at the start of key exchange. The xymon ssh test reports the remote protocol and software versions, so it must converse at least that far, but I guess it doesn't go on through the key exchange.
The ssh server going wrong that way seems to be a familiar failure mode for our linux boxes, so it would be nice to have a test for it in xymon. An ssh identity that's allowed to run some single very restricted command would work. Actually ssh-keyscan does the trick too, and doesn't require any logging in or permission on the host. The only trick is ssh-keyscan exits with status 0 whether it succeeded or not, so it would have to be used in a script that actually parses its output to see if it worked.
Dustin's script that does ssh-keyscan for updating the keys list could be a useful starting point.
Robert P. McGraw, Jr.
Manager, Computer System EMAIL: rmcgraw at purdue.edu
Purdue University ROOM: MATH-807
Department of Mathematics PHONE: (765) 494-6055
150 N. University Street
West Lafayette, IN 47907-2067