I am trying to write an expect script that trys to telnet, if telnet fails, trys to ssh to a remote network devices.
The script works fine until the following is received :
spawn telnet 10.3.2.24
Trying 10.3.2.24...
telnet: connect to address 10.3.2.24: Connection refused
10.3.2.24 is not reachable!!
spawn ssh -l myname 10.3.2.24
The authenticity of host '10.3.2.24 (10.3.2.24)' can't be established.
RSA key fingerprint is b1:z6:22:85:3a:a6:z0:ae:6d:b3:9d:f6:77:85:01:aa.
Are you sure you want to continue connecting (yes/no)?
Ive added
expect {continue connecting*} {send "yes\r"}
at different places within the telnet host not reachable section, but cant
get expect to respond.
Ive added the entire script below for those who may want to look at it.
#! /usr/local/bin/expect --
#
# Setup Log file that will contain all steps of the process.
#============================================================
puts "[exec clear]"
set nam "[ clock format [ clock seconds ] -format "%m%d%H%M" ].log"
log_file -a $nam
#
# Open Seedfile and setup log containing failed connections.
#=============================================================
set ifil [open "seedfileofips" r]
set ofil [open "[ clock format [ clock seconds ] -format "%m%d%H%M" ].err" w]
###
# Main Body. While reading the seedfile, telnet to site
# or ssh to site
#=============================================================
while { [gets $ifil host] >=0 } {
send_user "Standby ... Validating ... $host \n"
puts "[exec clear]"
set taclnam "myname"
set tacpswd "mypassword"
set timeout 30
spawn telnet $host
I haven't read your Expect script because it's been far too long since I last wrote anything in Tcl.
Anyway, I think there is no real need for any sophisticated Expect prompting logic here
since the warning you encounter from your SSH client about an unknown host identity
can be easily circumvented.
If your SSH client connects to a remote SSH server whose host identity it cannot verify,
either because it is the first connect to this host, or maybe the remote host's SSH server was started with different host keys meanwhile (maybe its admin updated SSH and neglected restoring its host key) it will warn you as long as StrictHostKeyChecking isn't set to "no" (per default it is set to "ask", see man ssh_config).
If it is the first connect and you have verified that the presented fingerprint of the remote host key is correct (or you trust it anyway) you simply need to confirm this warning with yes.
Your SSH client will then create a file $HOME/.ssh/known_hosts (if it hasn't existed yet)
and append the public host key offered from the remote SSH server to it.
From then on it will never again ask you as long as the host key on the remote server or the entry in your local known_hosts file for that host will not change.
In that respect it even wouldn't help if you provided an extra yes response in your Expect prompt logic.
However, there are even other ways how you can connect if you don't care for strict host key checking at all (which maybe isn't advisable in a potentially hostile environment)
You could run the SSH command with the following options:
This will (even if the host key changed, or there is a real man-in-the-middle attack!) don't care about the validity of the host key's fingerprint and automatically "add" any offered host key to the bit bucket /dev/null.
The quiet option -q will suppress any warning text of this action,
and BatchMode will not prompt for any passwords or passphrases.
So you should run this command with distributed RSA keys which have either no passphrase attached to them, or have started an ssh-agent a priori which had added the necessary RSA key for this connection.
Please, consult man ssh and man ssh_config for details.