Expect script not passing password / commands ??

Shell Programming and Scripting
1

Newbie here. My goal is to have the expect script log into the Ubuntu 18.04 server and run two commands (lsb_release -a and ip addr) and eventually pipe the output/results to a file. For now, I would be happy to get this one command or two to run successfully. How to fix this?

#!/usr/bin/expect 
set timeout 60 
spawn ssh admin@192.168.1.12
expect " admin@192.168.1.12's password: " 
send " admin\r" 
expect " admin@server1:~$ " 
send " \r" 
expect " admin@server1:~$ "
send " lsb_release -a "
expect " admin@server1:~$ "

Error: I get the password prompt but the script isn't passing the password (??)

admin@server1:~$ expect test.exp
spawn ssh admin@192.168.1.12
admin@192.168.1.12's password:

Normal response/output using "ssh -l" from the cli.

admin@server1:~$ ssh -l admin 192.168.1.12
admin@192.168.1.12's password:
Welcome to Ubuntu 18.04.1 LTS (GNU/Linux 4.15.0-45-generic x86_64)

... misc output here

*** System restart required ***
Last login: Mon Mar  4 14:40:27 2019 from 192.168.1.10
admin@server1:~$
2

Why do you have so many <space>s at the start of the strings you expect to see from the remote host? You don't show those leading spaces in the normal output that you get when you login manually.

Why do you have <space>s at the start of the strings you send to the remote host? I assume that "admin" is a sample and not your real password for the user "admin" on that server, but you have specified that the first character of the password you are sending to the remote host is a <space>. Is that really what you want?

Why do you have <space>s at the start of the strings you expect to see from the remote host? You haven't shown us <space>s in those spots in the output you get from the remote hosts when you login manually. Why do you expect the remote host to send those <space>s when you try to login programmatically?

You're probably better off just using expect to look for the end of what you expect the remote host to send instead of looking for everything. There is less chance that you have a typo that will keep you from logging in. (I.e., look for "password: " instead of looking for " admin@192.168.1.12's password: " and include the <space> at the end of that ONLY if the remote server actually includes a <space> in the output it sends when it is asking you to supply your password.)

If you type the command lsb-release -a with a leading and trailing <space>, but do not hit the enter key; what does your local system do? Does it guess that you're done and run the command for you, or does it patiently sit there waiting for you to finish the command by hitting the enter key?

If you want the remote system to run that command, shouldn't you send it a \r to tell it that you're done entering the command?

3

When debugging these sort of scripts you should have a much shorter timeout. You don't want to wait for 60 seconds for expect to tell you it missed something:

set timeout 3

Once it's working OK then bump you timeout up to a reasonable value, I still think 60 seconds it too long for a login prompt or for those simple commands to complete.

4

Is there a reason not to generate an SSH key to provide a passwordless connection? Using expect is trying to break through the well considered security practice of SSH.

If you get it set up, then the client just needs to call in in one line. The following allow for progressively more complex calls according to your need. You only need the simplest one that works for you:-

ssh $target_server_name $remote_command_to_run
ssh $user_name@$target_server_name $remote_command_to_run
ssh -i $private_key_location $user_name@$target_server_name $remote_command_to_run

Would that not simplify the client side code? Is there a reason to attack SSH with expect? I assume you have credentials to get to each server. This will take a little effort first time to get the SSH connection set up, but then it is so much easier to actually use and leaves your script much cleaner.

Kind regards,
Robin