I have a script to automatically connect to a VPN, because I often have to connect and disconnect several times a day. (Certain things like ScreenHero and GoToMeeting fail on the VPN, and Mail servers and other things are blocked while on the VPN, but I can't connect to the Git server unless I'm on the VPN, and the app I'm working on can't reach certain back-end services unless I'm on the VPN, so development is limited when disconnected.)
The script lessens the hassle, but I have a $ in my password (which is available in the environment through the environment variable VPN_PASSWORD1), and the password value gets interpolated before it is passed to the VPN program by expect.
#!/bin/bash
{
/usr/bin/expect << END_OF_LOGIN_SESSION
set timeout 30
spawn /opt/cisco/anyconnect/bin/vpn -s connect blah.blahblah.com
expect "Username:*"
send "\r"
expect "Password:*"
send "$VPN_PASSWORD\r"
expect "accept? \[y/n\]:*"
send "y\r"
expect eof
END_OF_LOGIN_SESSION
}
How do I pass a password literally, without letting it be subject to string interpolation?
Changing my password is a cop-out. Saving it with a \ is also a cop-out (and horrible UX, since I have to enter it every time I source my .project file for this project2).
It seems like expect must have a solution for this.
Yes I know someone who steals my laptop could try to log in, but (a) they'd have to get into my account first, and (b) they'd fail without my PIN, entered by phone, anyway.
No, the password is not saved to disk. I enter it once per shell session related to this project.
You should have got the can't read "VPN_PASSWORD": no such variable at the first place unless you have defined any variable with that name.
Environmental variables can be accessed via the Tcl's special array variable env.
You can straightaway use env(VPN_PASSWORD) to access the same.
send "$env(VPN_PASSWORD)\r"
Reference : env
You have the shell variable $VPN_PASSWORD in an unquoted heredoc, so the shell will substitute the value. Suppose VPN_PASSWORD='foo$bar' => Then expect will see: send "foo$bar\r" and you'll get can't read "bar": no such variable. The solution is to use {braces} instead of double quotes, so that expect will not attempt to expand the "inner" variable.
send {$VPN_PASSWORD}; send "\r"
You need a separate send "\r" because putting \r inside the braces will remove its special meaning, and Tcl won't let you do send {$VPN_PASSWORD}"\r"
Here's a demo:
$ VPN_PASSWORD='foo$bar'
$ expect <<END
send_user "$VPN_PASSWORD\n"
END
can't read "bar": no such variable
while executing
"send_user "foo$bar\n""
$ expect <<END
send_user {$VPN_PASSWORD}; send_user "\n"
END
foo$bar
In Tcl, braces act like single quotes in the shell: everything inside them are literal characters.
It might be cleaner to use the environment to pass the values. Here it is implemented as a shell function
vpnconnect() {
expect <<'END'
set timeout 30
spawn /opt/cisco/anyconnect/bin/vpn -s connect $env(VPN_HOST)
expect "Username:*"
send "\r"
expect "Password:*"
send "$env(VPN_PASSWORD)\r"
expect {accept? [y/n]:*}
send "y\r"
expect eof
END
}
Related
I'm trying to write a script to update the password of an OS X account to a rotating, centrally-stored value. As a prelude to learning to use tclcurl, I just want to get this prototype script working:
#!/usr/bin/expect
set mgrpassword "newpassword" # this will become a tclcurl command later
spawn passwd manager
expect "New password:"
send "$mgrpassword\n"
expect "Retype new password:"
send "$mgrpassword\n"
puts "\nManager password changed."
exit 0
It runs without errors, but it does nothing; the password for the manager account remains unchanged. I've tried it with both \r and \n but that didn't make any difference. Can anyone see what I'm doing wrong or what steps I'm omitting?
(It will always run with admin rights; that's why there is no 'expect "Old password:"' line.)
Just add one more expect statement at the end, like as follows,
send "$mgrpassword\r"
expect eof
Basically, Expect will work with two feasible commands such as send and expect. If send is used, then it is mandatory to have expect (in most of the cases) afterwards. (while the vice-versa is not required to be mandatory)
This is because without that we will be missing out what is happening in the spawned process as Expect will assume that you simply need to send one string value and not expecting anything else from the session.
Your script can be written in the following way as well which makes it robust with the use of exp_continue. It will make the Expect to run again.
set mgrpassword "newpassword"
spawn passwd manager
expect {
timeout { puts "Timeout happened";exit 0}
"password:" {send "$mgrpassword \r";exp_continue}
eof {puts "Manager password changed"; exit 1}
}
So it turns out that
dscl . passwd /Users/manager [passwordstring]
works a lot better/easier than trying to combine passwd with expect. Hope this helps someone else.
I have the following scripts which is supposed to pull the IP address from a file device-list.txt and then telnet to the device, login and execute a show run. The script logs in to the device successfully, but gives me an error after that. Any ideas where im going wrong?
for device in `cat device-list.txt`; do ./test4 $device;done
cat test4
#!/usr/bin/expect -f
set hostname [lindex $argv 0]
set user myusername
set pass mypassword
set timeout 10
log_file -a ~/results.log
send_user "\n"
send_user ">>>>> Working on $hostname # [exec date] <<<<<\n"
send_user "\n"
spawn telnet $hostname
expect "Username:"
send "$user\n"
expect "Password:"
send "$pass\n"
expect "#"
send “term len 0\n”
send “show running-config\n”
expect “end\r”
send “\n”
send “exit\n”
User Access Verification
Username: myusername
Password:
ROUTER#usage: send [args] string
while executing
"send “term len 0\n”"
(file "./test4" line 26)
Your problem is due to incorrect double quotes. You have to use double quotes ", not smart quotes “
send “term len 0\n” ; # Wrong
send "term len 0\r"; # Correct
Note :
Basically, Expect will work with two feasible commands such as send and expect. If send is used, then it is mandatory to have expect (in most of the cases) afterwards. (while the vice-versa is not required to be mandatory)
This is because without that we will be missing out what is happening in the spawned process as Expect will assume that you simply need to send one string value and not expecting anything else from the session.
So, we recommend to use expect after each send, to make sure our commands actually sent to the spawned process. (You have not used expect after sending some commands such as term len 0\r). Also, use \r instead of \n.
I want to write a simple bash script using ncat to open a connection to a ISP and its port.
The first command would be:
nc address port
Upon doing this, I am prompted first to provide a username. I must hit ENTER, and then I will be prompted to provide a password and then I must hit ENTER again.
After this, I want to open a Terminal process window. Can anyone point me to sufficient resources for this type of scripting?
I know the username and password already, but I'm not too sure how to work around the fact that I must provide it and then hit enter. I'm also unsure how to open a new Terminal proceses.
Thanks in advance!
Check out expect script
Expect
Example:
# Assume $remote_server, $my_user_id, $my_password, and $my_command were read in earlier
# in the script.
# Open a telnet session to a remote server, and wait for a username prompt.
spawn telnet $remote_server
expect "username:"
# Send the username, and then wait for a password prompt.
send "$my_user_id\r"
expect "password:"
# Send the password, and then wait for a shell prompt.
send "$my_password\r"
expect "%"
# Send the prebuilt command, and then wait for another shell prompt.
send "$my_command\r"
expect "%"
# Capture the results of the command into a variable. This can be displayed, or written to disk.
set results $expect_out(buffer)
# Exit the telnet session, and wait for a special end-of-file character.
send "exit\r"
expect eof
The secret lies in the HEREDOC
You can solve this problem with something akin to:
$ command-that-needs-input <<EOF
authenticate here
issue a command
issue another command
EOF
Look at the link I provided for here documents - it includes support for variable substitution and lots of other useful things. Enjoy!
Problem statement
I want to access a server without asking me the password (will be mentioned in the script) and run a command on that server.
My Code
#!/usr/bin/expect
spawn sudo su - <server_name>
expect "[sudo] password for chronicles:"
set Password "xxxxxxx"
send "$Password\r"
#set timeout 300
send "whoami\r"
send "ls -ltr\r"
expect eof
Output
invalid command name "sudo"
while executing
Restrictions
I dont have access rights to change env variables or modify
.bash_profile / .bashrc.
su server_name command not allowed
David is right that generally this is a bad idea. There are occasionally good reasons for doing it, or doing something similar (e.g. automatically logging into serial consoles for lights-out management), but you haven't provided any indication as to why it makes sense for you to do it this way.
Caveats aside, the invalid command name is not coming from the spawn line but from the [sudo] in the expect line. Expect is based on tcl, which treats [] square parentheses as special characters indicating command substitution. Additionally, the value passed to expect is a glob pattern not a fixed string, and [] square parentheses are also special characters in globs. So the answer you are looking for is to quote those characters twice:
expect "\\\[sudo\\\] password for chronicles:"
Also note that after sending the password you should probably include another expect line to wait for the root shell prompt.
The secure way to access a server without prompting for a password is through keyed logins over SSH. Don't ever give your password in plain text.
If you simply Google, you will find many articles explaining how to do this. SSH login without password is a perfectly fine explanation.
[] is interpreted as "command quotes" ("command" as in "Tool Command Language", which is what Tcl is short for) in Tcl.
{} is the strongest quote in Tcl, you can use it to prevent any interpretation:
expect {[sudo] password for chronicles:}
of course you could also just omit [sudo]:
expect "password for chronicles:"
I've been trying to automate some configuration backups on my cisco devices, i've already managed to do the script that accomplishes the task but I'm trying to improve it to handle errors too.
I think that's necessary to catch the errors on two steps, first just after the 'send \"$pass\r\"' to get login errors (access denied messages) and at the 'expect \": end\"' line, to be sure that the commands issued were able to pull the configuration from the device.
I've seen some ways to do it if you work on a expect script, but i want to use a bash script to be able to supply a list of devices from a .txt file.
#!/bin/bash
data=$(date +%d-%m-%Y)
dataOntem=$(date +%d-%m-%Y -d "-1 day")
hora=$(date +%d-%m-%Y-%H:%M:%S)
log=/firewall/log/bkpCisco.$data.log
user=MYUSER
pass=MYPASS
for firewall in `cat /firewall/script/firewall.cisco`
do
VAR=$(expect -c "
spawn ssh $user#$firewall
expect \"assword:\"
send \"$pass\r\"
expect \">\"
send \"ena\r\"
expect \"assword:\"
send \"$pass\r\"
expect \"#\"
send \"conf t\r\"
expect \"conf\"
send \"no pager\r\"
send \"sh run\r\"
log_file -noappend /firewall/backup/$firewall.$data.cfg.tmp
expect \": end\"
log_file
send \"pager 24\r\"
send \"exit\r\"
send \"exit\r\"
")
echo "$VAR"
done
You need alternative patterns in the expect statements where you want to catch errors. If you're looking for a specific error message you can specify that, alternatively just specify a timeout handler which will eventually trigger when the normal output fails to appear.
Eg. after send \"$pass\r\" instead of expect \">\" try:
expect \">\" {} timeout {puts stderr {Could not log in}; exit}
ie. if the expected output arrives before the timeout (default 10 sec) do nothing and continue, otherwise complain and exit from expect. You might also need an eof pattern to match the case where your ssh session ends.
Note that since you don't do any variable substitution in expect, you don't need \"\" around your strings, you can use {} or even nothing when it's one word, eg. expect conf and send {no pager}.
BTW I agree with bstpierre that this would be cleaner if you dropped bash and did the whole thing in expect, but if bash does the job that's ok.
If you don't use single quotes (expect -c '...'), then all the $variables will be substituted by bash not expect. May be easier to put the expect code in a separate file, or maybe a heredoc.