Afternoon,
I have googled this all day and even attempted other solutions in python but not had any success.
I have some old-ish network gear that seems to have a weird terminal type when you SSH to them, the one where CTRL+h is backspace!
This is causing problems for my expect script than needs to do 3 things, 1) log in 2) escalate privileges (think cisco enable) 3) save the config
Tried to set the terminal type but not sure that vt100 is correct, i doubt it is. I also added the sleep commands to see if a delay would solve it, no dice.
here is my script so far
#!/usr/bin/expect
set ::env(TERM) vt100
## Get username
send_user "Username: \n"
expect_user -re "(.*)\n" { set user $expect_out(1,string) }
## Get pass
stty -echo
send_user "Password: \n"
expect_user -re "(.*)\n" { set pass $expect_out(1,string) }
stty echo
## Get list of hosts
set f [ open "hosts.txt"]
set hosts [ split [read $f] "\n"]
set hosts [ lreplace $hosts end end ]
close $f
## iterate host
foreach host $hosts {
spawn ssh "$user\#$host"
expect {
"continue connecting" { send "yes\r"; exp_continue }
"assword" { send "$pass\r" }
}
expect "Copyright (c)" {
sleep 1
send "\r"
sleep 1
send "en 14\r"
sleep 1
send "$pass\r"
sleep 1
send "config save\r"
sleep 1
send "exit\r"
}
}
Output from script
deanmoore#laptop% ./zyxel
Username:
dean.moore
Password:
spawn ssh dean.moore#host1
dean.moore#host1's password:
Copyright (c) 1994 - 2013 ZyXEL Communications Corp.
host1> ^[[47;223R%
deanmoore#laptop% 7;223R
Related
I am trying to write a script will provide credentials to a vpn with one caveat where VPN requires that I provide OTP.
This is my script:
#! /usr/bin/expect
set vpn [ lindex $argv 0]
set group [ lindex $argv 1]
set user [ lindex $argv 2]
set secret [ lindex $argv 3]
log_user 2
spawn nmcli con up $vpn --ask
expect {
"GROUP:" {
send "$group\r"
exp_continue
}
"Username:" {
send "$user\r"
exp_continue
}
Password: {
send_user "\nProvide RSA OTP:"
expect_user -re ":(.*)\r"
set otp $expect_out(0,string) <--------- Error!!!
set pass "$secret$otp"
send "$pass\r"
exp_continue
}
"Connection successfully activated" {
send_user "Connected to VPN\r"
}
"Login failed" {
send_user "Login failed\r"
exp_continue
}
"already active" {
send_user "Already connected to VPN\r"
}
}
exit
I included an arrow to what I think is the source of the problem because when I run this script, it looks like expect_out contains Password:. Given what i read in man page I imagined that the buffer is cleared each time new match is made and therefore it contains string matched in most recent expect clause( in this case expect_user -re ":(.*)\r"), however it seems that I'm wrong. I did not see any notes saying that expect_user contents need to be accessed using different function like interact does, so I'm not sure where did my password go?
Thank you
When using send_user you will not see an echo of what you write, unlike when you send to the spawned command, so you will never match : unless the user explicitly types it. Also, you will read newline, not carriage-return. So use
expect_user -re "(.*)\n"
to get the user input and $expect_out(1,string) (1 not 0) will contain the input.
What you are observing is a timeout in your expect_user, which is why the variable is not updated and still contains the old match.
To protect yourself against unseen timeouts, you could set up a "global" timeout check by starting with
proc abort { } { send_user "Timeout!" ; exit 2 }
expect_before timeout abort
The expect_before is done "before" each expect, but also before each expect_user, it seems.
Because my company insists on using sudo I now have to scrap my ssh system I've built for running remote commands.
I have a script that will connect to a server, sudo into the db2 inst owner account and then run a script (previously delivered into /tmp). Maybe 1 in 10 times it will work (outputs 'Hello world' for my test).
Here is the ksh script on the remote server (/tmp/cwow/generic.ksh):
#!/usr/bin/ksh93
echo "Hello world"
[I've also tried adding sleep 5 and wait with mixed results but it doesn't solve the problem]
The expect script I'm running locally is:
#!/usr/bin/expect
set spath /tmp/cwow/generic.ksh
set pass $env(MYEXPECTPASS)
set user $env(MYEXPECTUSER)
if { [llength $argv] != 2 } {
send_user "USAGE: $argv0 host inst\n"
exit
}
set host [lindex $argv 0]
set inst [lindex $argv 1]
set timeout 10
log_user 1
exp_internal 0
eval spawn /usr/bin/ssh -t $user#$host "sudo su - cwow"
expect {
timeout { send_user "TimedOut"; exit }
-glob "assword:" {
send "$pass\r"
expect {
-glob "assword:" {
send "$pass\r"
expect {
-glob " " {
send "/tmp/cwow/generic.ksh\r\n"
expect {
-glob "world" {
send_user "Got it\r"
}
}
}
}
}
}
}
}
I should also note that I never get the 'Got it' message but I don't really need that to work, just curious why it doesn't. What I need to work reliably is for the script to run and, most of the time, it doesn't appear to.
Any ideas for a weak expect user would be greatly appreciated.
(not an answer, just a formatted comment)
You don't need to nest all the expect commands: if you expect a pattern with no action body, the script will continue to the next command. This is more readable, IMO:
expect {
timeout { send_user "TimedOut"; exit }
"assword:"
}
send "$pass\r"
expect "assword:"
send "$pass\r"
expect " "
send "/tmp/cwow/generic.ksh\r"
expect "world"
send_user "Got it\n"
Note, you should send to the spawned process with \r as "hitting Enter". But \n is used for send_user.
I am attempting to automate the change of switch configurations on multiple cisco switches. I get all the way to the config section and when the config.txt variable is sent, the output has curly brackets at the end and is not a valid command. Here is the output and below that I will post the code.
All I am trying to do is login to my switch and run the following command
configure replace flash:/thenameofconfig
The script will loop through multiple switches in the device list and apply the correct config based o
IL-test-SW1#configure replace flash:/il-test-sw2-confg} {}
Code:
#!/usr/bin/expect -f
# Set up various other variables here ($user, $password)
set username user
set password user
set enablepassword user
# Log results
#log_file -a ~/results.log
log_file -a /tmp/results.log
# Get the list of hosts, one per line #####
set f [open "device-list.txt"]
set hostname [split [read $f] "\n"]
close $f
# Get the commands to run, one per line
set f [open "configs.txt"]
set configs [split [read $f] "\n"]
close $f
# Iterate over the hosts
foreach host $hostname {
# Don't check keys
spawn ssh -o StrictHostKeyChecking=no $username\#$hostname
# spawn ssh $user#host
# expect "password:"
# send "$password\r"
# Allow this script to handle ssh connection issues
expect {
timeout { send_user "\nTimeout Exceeded - Check Host\n"; exit 1 }
eof { send_user "\nSSH Connection To $hostname Failed\n"; exit 1 }
"*#" {}
"*assword:" {
send "$password\n"
}
}
# If we're not already in enable mode, get us there
expect {
default { send_user "\nEnable Mode Failed - Check Password\n"; exit 1 }
"*#" {}
"*>" {
send "enable\n"
expect "*assword"
send "$enablepassword\n"
expect "*#"
}
}
# Let's go to configure mode
send "conf t\n"
expect "(config)#"
send "shell processing full\n"
expect "(config)#"
send "end\n"
expect "*#"
#Iterate over the commands
foreach config $configs {
expect "*#"
send "$configs\n"
expect "\[no]:"
send "y\n"
expect "*#"
}
# Tidy up
# expect "*#"
# send "exit\r"
# expect eof
# close
send "exit\n"
expect ":~\$"
exit
}
Cannot seem to get rid of the {} at the end of the configure replace command.
Any help will be greatly appreciated.
Figured it out. Was the following line
set hostname [split [read $f] "\n"]
Needs to be:
set hostname [split [read -nonewline $f] "\n"]
I am trying to figure out how expect working. AFAIK the expect script consists of "expect" and "send" statements. So for each approporiate "expect" statement which appears on screen the "send" statement is called. Also the command "interact" means that controlling is passed back to user and he is able to interact with the terminal. Correct me if I am wrong. Those two statements works like a charm.
1st:
#!/usr/bin/expect
spawn ssh -q localhost;
# Handles following message: "Are you sure you want to continue connecting (yes/no)?"
expect "yes";
send "yes\r";
interact;
2nd:
#!/usr/bin/expect
spawn ssh -q localhost;
# Handles following message: "pista#localhost's password:"
expect "assword";
send "password\r";
interact;
I've found on internet that something like following code should combine those two examples into one:
#!/usr/bin/expect
spawn ssh -q localhost "uname -a";
expect {
"*yes/no*" { send "yes\r" ; exp_continue }
"*assword:" { send "password\r"; interact }
}
But this example exits immediatelly after sucesfull login (seems like "interact" is not workig here, see output bellow)
[pista#HP-PC .ssh]$ ./fin.exp
spawn ssh -q localhost uname -a
pista#localhost's password:
Linux HP-PC 3.6.6-1.fc16.x86_64 #1 SMP Mon Nov 5 16:56:43 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[pista#HP-PC .ssh]$ set | grep SHLV
SHLVL=2
Three questions:
What those weird expect syntax mean, only possible explaination to me is that there is no emphasis on patterns order in this "big" expect ?
Can you please clarify what is exactly exp_continue doing, seems to me like "goto" statement to expect which invoked this ?
Why is not interact working here ?
Many thanks
1. This syntax means that you use consecutive expect statements, it's easier. For example, this will try SSH or telnet if SSH fails
#!/usr/bin/expect
set remote_server [lrange $argv 0 0]
set timeout 10
spawn ssh -M username#$remote_server
while 1 {
expect {
"no)?" {send "yes\r"}
"denied" {
log_file /var/log/expect_msg.log
send_log "Can't login to $remote_server. Check username and password\n";
exit 1
}
"telnet:" {
log_file /var/log/expect_msg.log
send_log "Can't connect to $remote_server via SSH or Telnet. Something went definitely wrong\n";
exit 2
}
"failed" {
log_file /var/log/expect_msg.log
send_log "Host $remote_server exists. Check ssh_hosts file\n";
exit 3
}
timeout {
log_file /var/log/expect_msg.log
send_log "Timeout problem. Host $remote_server doesn't respond\n";
exit 4
}
"refused" {
log_file /var/log/expect_msg.log
send_log "Host $remote_server refused to SSH. That is insecure.\n"
log_file
spawn telnet $remote_server
}
"sername:" {send "username\r"}
"assword:" {send "password\r"}
"#" {break}
}
}
2. exp_continue is telling expect to "continue to expect", that is to continue with the event processing. Without this instruction your expect { ... } block will stop. In the example above it is the line:
"#" {break}
First it breaks from the while loop, and then without exp_continue it stops executing expect { ... } block and going for the next instructions (not shown in the example above).
3. You have an error in your code. I've slightly modified your code, to make it work.
#!/usr/bin/expect
spawn ssh -q localhost
expect {
"*yes/no*" { send "yes\r" ; exp_continue }
"*assword:" { send "password\r"; exp_continue;}
"~" {send "uname -a\r"; interact;}
}
I am automating the process of:
Connect to a system named "alpha" via ssh with password "alpha" for username "alpha". Once connected I would like to set the root password (to "kickass"). The system I am connecting to doesn't have a root password by default. I wrote this expect script to do the job but it doesn't work consistently. It works once and then if I change the password to test again, it waits at the "Enter new UNIX password:" prompt after issuing "sudo passwd root". Any ideas?
#!/usr/bin/expect -f
set arg1 [lindex $argv 0]
set force_conservative 1 ;# set to 1 to force conservative mode even if
;# script wasn't run conservatively originally
if {$force_conservative} {
set send_slow {1 .1}
proc send {ignore arg} {
sleep .1
exp_send -s -- $arg
}
}
set timeout -1
spawn ssh alpha#$arg1
match_max 100000
expect -exact "password: "
send -- "alpha\r"
expect -exact "alpha#alpha:~\$ "
send -- "sudo passwd root\r"
expect -exact "password for alpha: "
send -- "alpha\r"
expect -exact "new UNIX password: "
send -- "kickass\r"
expect -exact "Retype new UNIX password: "
send -- "kickass\r"
expect -exact "alpha#alpha:~\$ "
send -- "exit\r"
expect eof
Thanks.
Expanding on Andrei Sfrent's comment:
Sudo normally has some kind of time-out value, so that if you issue a second sudo command within the time-out period you will not be asked for your password again. You could modify the code to something like this:
send -- "sudo passwd root\r"
expect {
-exact "password for alpha: "
{
send -- "alpha\r"
exp_continue
}
-exact "new UNIX password: "
{
send -- "kickass\r"
}
}