timing out an ssh command

[Andrei Doicin]

Dear fellow Pythonheads,

I have written a fairly nifty but "just beyond amateur" =) wrapper script in
python for sending ssh commands to remote hosts from the unix command line,
but would now like the ssh command to time out after a certain amount of
time (eventually to be specified as an option to the wrapper).

What would you advise is the best way to do this, out of the following
avenues to consider ?

- somehow making use of time.time or time.clock and/or select(x,x,x,timeout)
- sockets (i.e. making use of something like
http://www.timo-tasi.org/python/timeoutsocket.py by Timothy Malley)
- expect
- pexpect

?

A situation in which the ssh command hangs forever can be indicated as
follows, using the verbose option (whether necessary or not) of ssh to
illustrate what's going on at the fundamental level:

[client0-15:26:01] 130:adoicin/scripts> ssh -v target1 uptime
OpenSSH_3.4p1-CERN20020919, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to target1 [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/adoicin/.ssh/identity type -1
debug1: identity file /home/adoicin/.ssh/id_rsa type -1
debug1: identity file /home/adoicin/.ssh/id_dsa type -1
... waits forever ...

the above example literally hangs forever unless you intervene with CTRL-C
(obviously the target machine has a problem), so I put the relevant block of
code inside a try:/except block terminating with except KeyboardInterrupt,
which I have coded to give a neat enough output when doing CTRL-C instead of
barfing, but the next stage to aim for is an automatic timeout.

Here's an example where everything goes through smoothly enough and the
command completes.

[client0-15:26:07] 130:adoicin/scripts> ssh -v target2 uptime
OpenSSH_3.4p1-CERN20020919, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to target2 [xxx.xxx.xxx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/adoicin/.ssh/identity type -1
debug1: identity file /home/adoicin/.ssh/id_rsa type -1
debug1: identity file /home/adoicin/.ssh/id_dsa type -1
debug1: Remote protocol version 1.99, remote software version
OpenSSH_3.4p1-CERN20020919
debug1: match: OpenSSH_3.4p1-CERN20020919 pat OpenSSH*
debug1: Local version string SSH-1.5-OpenSSH_3.4p1-CERN20020919
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'target2' is known and matches the RSA1 host key.
debug1: Found key in /home/adoicin/.ssh/known_hosts:43
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: cipher_init: set keylen (16 -> 32)
debug1: cipher_init: set keylen (16 -> 32)
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying Kerberos v5 authentication.
debug1: Kerberos v5: krb5_mk_req failed: No credentials cache found
debug1: Trying Kerberos v4 authentication.
debug1: Kerberos v4 authentication accepted.
debug1: Kerberos v4 challenge successful.
debug1: Kerberos v5 TGT forwarding failed: No credentials cache found
debug1: Kerberos v4 TGT forwarded (adoicin at CERN.CH).
debug1: AFS token for cell cern.ch forwarded.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: fd 3 setting TCP_NODELAY
debug1: Sending command: uptime
debug1: Entering interactive session.
  3:26pm  up 14 days, 20:56, 70 users,  load average: 0.12, 0.17, 0.20
debug1: Transferred: stdin 0, stdout 71, stderr 0 bytes in 0.4 seconds
debug1: Bytes per second: stdin 0.0, stdout 187.5, stderr 0.0
debug1: Exit status 0
[client0-15:26:13] 0:adoicin/scripts>

I'll post my code if you'd like to have a look, but I'm not sure if it's
necessary if we're just discussing the problem at the theoretical level for
the moment.

Thanks for your comments,

A