Training, Open Source computer languages
PerlPHPPythonMySQLApache / TomcatTclRubyJavaC and C++LinuxCSS 
Search for:
Home Accessibility Courses Diary The Mouth Forum Resources Site Map About Us Contact
 
For 2023 (and 2024 ...) - we are now fully retired from IT training.
We have made many, many friends over 25 years of teaching about Python, Tcl, Perl, PHP, Lua, Java, C and C++ - and MySQL, Linux and Solaris/SunOS too. Our training notes are now very much out of date, but due to upward compatability most of our examples remain operational and even relevant ad you are welcome to make us if them "as seen" and at your own risk.

Lisa and I (Graham) now live in what was our training centre in Melksham - happy to meet with former delegates here - but do check ahead before coming round. We are far from inactive - rather, enjoying the times that we are retired but still healthy enough in mind and body to be active!

I am also active in many other area and still look after a lot of web sites - you can find an index ((here))
Automating an SSH connection Expect-Style

Posted by jjinno (jjinno), 30 January 2008
So I have been looking into this topic rather heavily (as of recent) and have even tried my hand at writing my own automation script... except I have a few issues (mostly conceptually) that I cant seem to address, no matter what I try.

I think I have the theory, but I am missing some part of the implementation.

Code:
#!/usr/bin/expect

################################################################
# What we are trying to create here is a method of
# running SSH all at once. AKA - the user enters
# user/pass/host/command all at once, and this
# script takes care of the rest of the hard stuff.
#===============================================================
set USERNAME [lindex $argv 0]
set PASSWORD [lindex $argv 1]
set SERVER [lindex $argv 2]
set COMMAND [lindex $argv 3]

# Since we are going to need something to "expect"
# we may as well put a temp global variable to the
# task.
set NEW_PROMPT "."
set CHECK_FOR "EXPECT_ME"

################################################################
# What we want to do here is:
#  1 - Make sure we are getting *some* interaction
#  2 - Set the remote terminal (on some types of
#      servers) prompt to something pre-specified
#  3 - Expect that we can now see the prompt as the
#      first thing on a line when we hit <ENTER>
#  4 - Send a newline, so that the next thing we
#      can do is start with another expect
#  5 - Return 0 if it didnt fail, or 1 if it failed
#===============================================================
proc setPrompt_fail {} {
   global CHECK_FOR
   expect {
       -re "." {
           send "PS1=$CHECK_FOR\n"
           expect {
               -re "^$CHECK_FOR" {
                   set NEW_PROMPT $CHECK_FOR
                   send "\n"
                   return 0
               }
           }
           return 1
       }
   }
   return 1
}


################################################################
# What we want to do here is:
#  1 - Get the password argument
#  2 - Determine what type of SSH connection is
#      being made: 1st requires authentication
#      and password, 2nd requires only password,
#      3rd requires nothing (passwordless SSH)
#  3 - For each type, send and expect, up to the
#      point of verified login
#  4 - Attempt to set the prompt of the remote
#      machine
#  5 - Return 1 if connect fails, 0 if success
#===============================================================
proc connect_fail {} {
   global PASSWORD
   expect {
       "(yes/no)" {
           send "yes\n"
           expect {
               "assword:" {
                   send "$PASSWORD\n"
                   expect {
                       -re "." {
                           send "\n"
                           if {[setPrompt_fail]} {
                               puts "I couldnt set the remote prompt\n"
                           } else {
                               return 0
                           }
                       }
                   }
               }
           }
       }
       "assword:" {
           send "$PASSWORD\n"
           expect {
               -re "." {
                   if {[setPrompt_fail]} {
                       puts "I couldnt set the remote prompt\n"
                   } else {
                       return 0
                   }
               }
           }
       }
       -re "." {
           if {[setPrompt_fail]} {
               puts "I couldnt set the remote prompt\n"
           } else {
               return 0
           }
       }
   }
   return 1
}

################################################################
# Main Functionality:
#  1 - Turn off logging
#  2 - Spawn SSH connection (using argvs)
#  3 - Do the hard stuff (passwords & stuff)
#  4 - Expect the newly-set prompt
#  5 - Run the argv-quoted command
#  6 - Log ONLY the output from the command
#      not all the prompts and such
#===============================================================
log_user 0
spawn ssh $USERNAME@$SERVER
if {[connect_fail]} {
   puts "Well that was a miserable failure...\n"
} else {
   expect {
       -re "^$NEW_PROMPT" {
           send "$COMMAND\n"
           log_user 1
       }
   }
   send "exit\n"
   expect "logout"
   expect eof
}



Posted by jjinno (jjinno), 30 January 2008
Sorry for the weird post, but apparently I cant figure out how to preview without posting...

Anyway, my first issue is that no matter what I try, I cant seem to "expect" the new prompt that I set.  I can even guarantee that it does switch the prompt by making it happen outside of a conditional.

So, if I set the prompt, and it changes, shouldn't I be able to "expect" it as the first thing on a line after I hit "enter"?

Next, my second issue is that I cant seem to separate the responses.  I mean ideally, I would like to figure out how to make it so that the ONLY stuff that is echo-ed to my local console is the content that would be displayed remotely... so no prompts showing, no extra lines, no logouts, etc... JUST as if you were running a command locally... only its remote.

When I try changing the log_user setting, I still end up getting a prompt or two, and no matter what, I cant seem to lose the logout.

Any help?

Posted by admin (Graham Ellis), 30 January 2008
I've been having a quick look ... I was going to point out log_user but see you have found it already ....

I do notice that in setPrompt_Fail you set a new promt variable that's local to the function and never used - I wonder if there might be a clue in there, and I also note that you're not making any use of expect_out which provides a whole lot of useful info.  You might well be correct on that latter in your case, but it's something which usually crops up somewhere.

Posted by jjinno (jjinno), 30 January 2008
Maybe I am just not understanding exactly how declaration of variables in certain scopes works.

I looked at the code you were referring to, and I definitely had wanted the set to affect the global NEW_PROMPT variable.  I think I achieved a fix for this by including a global declaration for NEW_PROMPT directly under the global declaration for CHECK_FOR

Code:
proc setPrompt_fail {} {
   global CHECK_FOR
   global NEW_PROMPT
   expect {
       -re "." {
           send "PS1=$CHECK_FOR\n"
           expect {
               -re "^$CHECK_FOR" {
                   set NEW_PROMPT $CHECK_FOR
                   send "\n"
                   return 0
               }
           }
           return 1
       }
   }
   return 1
}


While I am still going to need some time to tinker with the expect_out() hint that you gave me (which does look EXTREMELY powerful) I thought I would present the output as I see it, when I turn on log_user:

Quote:
[jjinno@localhost expect]$ ./cmd root password parthanon "ls -l /"
spawn ssh root@parthanon
root@parthanon's password:
Last login: Wed Jan 30 10:53:33 2008 from 192.168.3.100
PS1=EXPECT_ME
[root@parthanon ~]# PS1=EXPECT_ME
EXPECT_MEI couldnt set the remote prompt

Well that was a miserable failure...

[jjinno@localhost expect]$




This page is a thread posted to the opentalk forum at www.opentalk.org.uk and archived here for reference. To jump to the archive index please follow this link.

You can Add a comment or ranking to this page

© WELL HOUSE CONSULTANTS LTD., 2024: Well House Manor • 48 Spa Road • Melksham, Wiltshire • United Kingdom • SN12 7NY
PH: 01144 1225 708225 • FAX: 01144 1225 793803 • EMAIL: info@wellho.net • WEB: http://www.wellho.net • SKYPE: wellho