[svlug] Problems with expect and ssh and a mini rant about ssh

[Mike "Szii" Oxford]

Richard Sharpe wrote:
> However, when I added the expect script to my shell script, it looked like 
> ssh was now looking for input from the terminal and the expect script no 
> longer worked.
>
> Has anyone seen this behavior before?
>
> I figured I would ask before I go hacking ssh to add what looks very easy 
> and what would be enormously useful for anyone doing testing. Why wrap ssh 
> in expect scripts and tear your hair out when the password could be passed 
> in on the command line.
>
> I know that the OpenSSH people are ultra paranoid about leaving passwords 
> in memory (since they overwrite it with NULLs after using it), but to 
> refuse to allow us users to make that choice for ourselves seems like 
> enormous arrogance to me. Now, lots of expect scripts keep the password 
> around in memory and lots of people waste their time writing expect 
> scripts to do what could have been done with 10-12 lines of C code (about 
> two-three lines in the routine that deals with passwords and 9-10 in the 
> argument parsing code).
>   
I don't believe you've hit a password issue, it just looks like it.

The issue stems from the builtin shell file descriptors 
(STDIN/STDOUT/STDERR)
not being closed properly, and causing it to hang.  You're running a 
shell within a
shell, and the internal FDs are not being released, causing the outer 
shell to hang waiting
for the inner shell to exit.

Try running with the parameters "0<&- 1>&- 2>&-" sans quotes.

This closes STDIN, STDOUT, STDERR FDs so they don't hang you.
Note the <> symbols, as one is "in" and two are "out" file descriptors.

FWIW, I do not agree with the commandline rant.  It's prone to exposure 
and while "a pain
it also is more secure.  The fact that you cannot use host keys "in all 
situations" is flawed.  That's an
implementation-specific detail which you should take up with Cisco, et 
al.  You may find the same
argument true of commandline passwords.  Is it looking for "Password" or 
"login password" or
"security key" or "passphrase" or ... ?  Just as you could not expect 
host-keys to work in every
situation you cannot expect cmdline passwords to work.  This is why we 
have the tools in *nix, such
as expect, to get the job done.

As a more extreme example, some companies run SecureID cards.   Those 
numbers are not locked
until a user tries to login.  At that point your card should match the 
server's expected code.  You can't
use hostkeys, and you can't pass it via cmdline due to the timing.  In 
this scenario, neither approach
works.

-moxford

More reading:
http://www.tldp.org/LDP/abs/html/io-redirection.html#IOREDIRREF