Automate testing a port with ssh

[Geoff Wild]

Trying to do a test to see if communication to a port is open from a server using ssh.

Basically, I'm testing a non ssh port:

ssh -p 6523 -v svr201

But I have to ^C to exit.

Need to automate (and no - don't want to use expect nor telnet) - any way to terminate ssh non-interactivly?

Rgds....Geoff

[Steven E. Protter]

Shalom,

ssh -p 6523 -v svr201 "command goes here"

Run a script that terminates the connection with an exit command.

SEP

[Mel Burslan]

I am not sure how this will work with the port but, without the port specification, it is working fine for me:

echo "~." | ssh myservername

hope this helps

[Mel Burslan]

as a matter of fact, when I tried your command with -p 22 -v command line switches, it worked, although it complains about the connection not coming from a terminal session and such.

[Geoff Wild]

Mel - yeah - I was looking at the ~. but no luck:

# echo "~." |ssh -p 6523 -v svr201
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug1: Reading configuration data /etc/opt/boksm/ssh/ssh_config
debug1: Connecting to svr201 [192.168.111.222] port 6523.
debug1: Connection established.
debug1: identity file /.ssh/identity type -1
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1

It just sits there until I ^C

I tried a \n in there as well...

With telnet it works:

echo ^C\n |telnet svr201 6523 |grep Connected

But, I would like to use ssh...

Steven - as far as commands - you can't - not on that port...

Thanks...Geoff

[Steven E. Protter]

Shalom again Geoff,

I should have run a test.

Have a script launch the command background.

Redirect the output to a file so you can see it later.

Get the process id of the command just launched with ps -ef | grep or UNIX95=1 ps -C and then launch a second script that waits x number of seconds and then issues a kill on the original process.

Messy, but it might get the job done.

telnet is an ideal tool for this job. ssh is designed specifically not to easily let you do this.

SEP

[Mel Burslan]

Geoff,

for what it is worth, I am using ssh V 4.20 and I noticed you are using 3.81. Unfortunately, I do not have any sshd running at that revision level left on any of my machines after last month's maintenance. So I can not test it but it may be something you can consider.

[Mel Burslan]

Actually, thinking hard, I found a ssh 3.81 machine and tested it. It still works on my end using port 22. Here is my output

(please keep in mind that i have a pair of trusted keys between these two hosts for passwd free login)

# echo "~." | ssh -p 22 -v prod

OpenSSH_3.8, OpenSSL 0.9.7d 17 Mar 2004
HP-UX_Secure_Shell-A.03.81.002, HP_UX Secure Shell version
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug1: Reading configuration data /opt/ssh/etc/ssh_config
debug1: Connecting to prod [xxx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/id_rsa type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8
debug1: match: OpenSSH_3.8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'prod' is known and matches the RSA host key.
debug1: Found key in /root/.ssh/known_hosts:300
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

*******************************************************************************
* *
* UNAUTHORIZED ACCESS TO THIS SYSTEM OR NETWORK IS PROHIBITED *
* *
* This is a private computer system provided for authorized use only. Use of *
* this system constitutes consent to monitoring of the system and disclosure *
* in accordance with Company policy and applicable law. *
* *
*******************************************************************************

debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /root/.ssh/id_rsa
debug1: Offering public key: /root/.ssh/id_dsa
debug1: Server accepts key: pkalg ssh-dss blen 434
debug1: read PEM private key done: type DSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
ttytype: couldn't open /dev/tty for reading
(c)Copyright 1983-2000 Hewlett-Packard Co., All Rights Reserved.
(c)Copyright 1979, 1980, 1983, 1985-1993 The Regents of the Univ. of California
(c)Copyright 1980, 1984, 1986 Novell, Inc.
(c)Copyright 1986-1992 Sun Microsystems, Inc.
(c)Copyright 1985, 1986, 1988 Massachusetts Institute of Technology
(c)Copyright 1989-1993 The Open Software Foundation, Inc.
(c)Copyright 1986 Digital Equipment Corp.
(c)Copyright 1990 Motorola, Inc.
(c)Copyright 1990, 1991, 1992 Cornell University
(c)Copyright 1989-1991 The University of Maryland
(c)Copyright 1988 Carnegie Mellon University
(c)Copyright 1991-2000 Mentat Inc.
(c)Copyright 1996 Morning Star Technologies, Inc.
(c)Copyright 1996 Progressive Systems, Inc.
(c)Copyright 1991-2000 Isogon Corporation, All Rights Reserved.


RESTRICTED RIGHTS LEGEND
Use, duplication, or disclosure by the U.S. Government is subject to
restrictions as set forth in sub-paragraph (c)(1)(ii) of the Rights in
Technical Data and Computer Software clause in DFARS 252.227-7013.

Hewlett-Packard Company
3000 Hanover Street
Palo Alto, CA 94304 U.S.A.

Rights for non-DOD U.S. Government Departments and Agencies are as set
forth in FAR 52.227-19(c)(1,2).
ttytype: couldn't open /dev/tty for reading
stty: : Not a typewriter

----------------------------------------
My /etc/motd here
----------------------------------------

Value of TERM has been set to "".
WARNING: YOU ARE SUPERUSER !!

logout root
Not a terminal
stty: : Not a typewriter
stty: : Not a typewriter
sh: ~.: not found.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.4 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 127





and here is my sshd_config

Protocol 2

KerberosAuthentication yes

UsePAM yes

X11Forwarding yes
X11UseLocalhost no

Banner /etc/issue

Subsystem sftp /opt/ssh/libexec/sftp-server



HTH

[Sandman!]

try the one below, tested on ssh ver. 3.81 and 3.91 and it works:

# ssh -e '~' -v svr201 ~.

[Geoff Wild]

Sandman - nope - still prompts for password:

# ssh -e '~' -v sha1 ~.
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/opt/boksm/ssh/ssh_config
debug1: Connecting to sha1 [192.168.162.125] port 22.
debug1: Connection established.
debug1: identity file /.ssh/identity type 0
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'sha1' is known and matches the RSA host key.
debug1: Found key in /.ssh/known_hosts:6
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
root's Password:


Rgds...Geoff

[Ralph Grothe]

I would suggest using Net::Ping
http://search.cpan.org/~bbb/Net-Ping-2.31/lib/Net/Ping.pm
According to above POD you can directly
access a Net::Ping object's data by assigning port 22 to the hashref key port
(although strictly speaking this infringes one of OO's fundamental principles not to bypass the interface)
I used the Net::Ping module for monitoring of firewalled servers which only have port 22 open to our admin LAN
before I discovered Nagios which has amongst others a versatile check_tcp plug-in.

[Geoff Wild]

Intersting idea using Perl - however - I can't - servers have a stripped down OS for security reasons...no Perl.

That said, the ssh eventually times out:

# timex ssh -p 6523 -v sha1
OpenSSH_3.8.1p1, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /etc/opt/boksm/ssh/ssh_config
debug1: Connecting to sha1 [192.168.162.125] port 6523.
debug1: Connection established.
debug1: identity file /.ssh/identity type 0
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host

real 2:02.41
user 0.02
sys 0.07

Rgds...Geoff

[Denver Osborn]

if you're testing against an sshd listner...

ssh -p 6523 -v -o perferredauthentications=password -o numberofpasswordprompts=0 -o stricthostkeychecking=no svr201


for testing against a non-sshd listner using ssh... I haven't got a clue, yet. :)

-denver

[Geoff Wild]

Denver - yes - it is a non sshd listener....

the -o options gave me some help...

What I tried was:

ssh -p 6523 -T -o ConnectTimeout=2 -o ServerAliveInterval=1 -o ServerAliveCountMax=1 -v sha1

The ConnectTimeout works great for hosts that don't respond - but the others don't seem to do what I interpreted from the man page :(

ServerAliveInterval
Sets a timeout interval in seconds after which if no
data has been received from the server, ssh will send a
message through the encrypted channel to request a
response from the server. The default is 0, indicating
that these messages will not be sent to the server.
This option applies to protocol version 2 only.

ServerAliveCountMax
Sets the number of server alive messages (see above)
which may be sent without ssh receiving any messages
back from the server. If this threshold is reached
while server alive messages are being sent, ssh will
disconnect from the server, terminating the session.
It is important to note that the use of server alive
messages is very different from TCPKeepAlive (below).
The server alive messages are sent through the
encrypted channel and therefore will not be spoofable.
The TCP keepalive option enabled by TCPKeepAlive is
spoofable. The server alive mechanism is valuable when
the client or server depend on knowing when a connec-
tion has become inactive.

The default value is 3. If, for example,
ServerAliveInterval (above) is set to 15, and Ser-
verAliveCountMax is left at the default, if the server
becomes unresponsive ssh will disconnect after approxi-
mately 45 seconds.

Rgds...Geoff

[Geoff Wild]

We are close here - just need a way to timeout the connection or send a control C to the session...else I'll have to do Steven's way - kill the PID after sleeping for 2 seconds...

Rgds...Geoff

[Mel Burslan]

Geoff,

There is an obscure -o option in ssh command which says ConnectTimeout. In ssh_config file, the line with this option is commented out with a value 0, which tells me it is set to no timeout by default.

Having said that, on one of my development servers, I have set this value to 5 hoping that it will be in seconds or miliseconds. And ssh into port 25 of a remote server. No dice. It sat on the sendmail listening output forever.

I tried it from the command line as follows:

ssh -o ConnectTimeout=3 -v -p 25 dev_p17

with the same outcome. I thought you might want to follow this lead. Otherwise, only option other than killing the PID is to readjust the global TCP TIMEOUT on the remote hosts, which I am almost sure can raise you to the status of "persona non grata" pretty quickly.

Good luck.

Mel

[Geoff Wild]

You know what we really need - a sshping utility.

I can't believe that someone hasn't developed one - especially one that is used to test non sshd ports.

Or, why can't one send a ^C as an option to ssh itself?

To recap, with ssh as I have it now, there is a 2 minute timeout to all servers that I can reach, and 2 seconds to those I can't.

With Telnet, there is an almost immediate disconnect to servers that I can connect to and a 2 minute delay to those I can't.

With most of my (300 servers) that I run my script against being reachable, telnet will complete more then 9 hours quicker then ssh.

Rgds...Geoff

[Geoff Wild]

cd /pub
more beer

Well - I was wrong - I tested from a server where default ping was working...then I found out that it didn't work from my main server - then I RTFM'ed the man page: -p port only applies to UDP....

So, I'm back at the start....

------------------------------------

Talk about the answer being right under your nose - I said sshping - and then I thought - check ping options and sure enough ping itself has a -p (port) option!

DOH!

Course, this is for Solaris 10.

timex ping -p 6523 svr201 3
no answer from svr201

real 3.01
user 0.00
sys 0.00

Rgds...Geoff