SSH via Expect disconnects

[Robert Denton]

Hello all,

I am using an expect script to initiate an SSH session to another host
as such:

#! /usr/bin/expect -f

spawn /usr/bin/ssh -R 3214:localhost:22 host.domain.tld
expect -re "word:"
send "<password>\r"
expect eof

This works just fine, or seems to. Then, when on the other host, I
issue the following command to pick-up that ssh session locally, I am
prompted for the password, I enter it, and then the session
disconnects, with the error: connection closed by 127.0.0.1. Here is
the command used:

ssh -p 3214 localhost

Here's the kicker: if I remove Expect from the equation, and just do
it all manually, the disconnect doesn't occur. Are there any Expect
experts out there who can offer a suggestion?

Thanks, Robert.

[Andreas Wilm]

Hi,

> I am using an expect script to initiate an SSH session to another host
> as such:
>
> #! /usr/bin/expect -f
>
> spawn /usr/bin/ssh -R 3214:localhost:22 host.domain.tld
> expect -re "word:"
> send "<password>\r"
> expect eof

...

I would recommend to use keys instead of a password (see
http://www.cs.utk.edu/~england/ssh.html for example).
Otherwise you will have to save your password plain-text inside your script.
This also means you don't need expect at all.

Regards,
Andreas

---

Andreas Wilm

-------------------------------------------
Heinrich-Heine-Universitaet Duesseldorf
Institut fuer Physikalische Biologie
http://www.biophys.uni-duesseldorf.de/
http://www.biophys.uni-duesseldorf.de/~wilm
-------------------------------------------

[Cameron Laird]

In article <c1n24j$sre$1...@news1.rz.uni-duesseldorf.de>,

Andreas Wilm <wi...@biophys.uni-duesseldorf.de> wrote:
>Hi,
>
>> I am using an expect script to initiate an SSH session to another host
>> as such:
>>
>> #! /usr/bin/expect -f
>>
>> spawn /usr/bin/ssh -R 3214:localhost:22 host.domain.tld
>> expect -re "word:"
>> send "<password>\r"
>> expect eof
>...
>
>I would recommend to use keys instead of a password (see
>http://www.cs.utk.edu/~england/ssh.html for example).
>Otherwise you will have to save your password plain-text inside your script.
>This also means you don't need expect at all.

.
.
.
Not good enough.

Oh, I agree that it's always timely to recommend ssh keys, AND
to simplify out of the need for such processes as Expect.

However, I also see plenty of legitimate needs for password
dirtiness and Expect, so, whatever best serves Mr. Denton in
this particular case, I think there's real value in pursuing
the question another step or two.

First, he's gone about this just right. His description is
clear, and he's taken all the steps I'd recommend. I'm puz-
zled.

I'm sure there's a solution. My approach would be to try
autoexpect <URL: http://wiki.tcl.tk/autoexpect > next, assum-
ing, again, that a move to ssh keys doesn't serve him better.

I'm curious to learn how this turns out.
--

Cameron Laird <cla...@phaseit.net>
Business: http://www.Phaseit.net

[Don Libes]

cla...@lairds.com (Cameron Laird) writes:

> I'm curious to learn how this turns out.

Me too. Besides Cameron's good suggestions, other things to try:

0) Doublecheck your script and make sure you are really sending the
same thing that you are handentering when running this manually. For
instance "\r".

1) Which ssh binary is being spawned vs run by hand. Are they the
same?

2) Add delays before (and maybe even during) send. Perhaps there's a
weakness in your ssh.

If none of that pans out, you can fall back to the heavyweight tools.

3) Run truss on ssh and compare with and without Expect.

4) Use sockspy and compare the actual traffic between the two
scenarios.

Don

[Robert Denton]

Hello again,

I have received one suggestion that I explore the idea of using keys
instead of Expect to supply the password. The idea of using Key pairs
was indea my first avenue of exploration into this problem and it
worked quite well for a while. I did the following on the device I
wanted to connect from:

1. ssh-keygen -t dsa
2. scp ~/.ssh/id_dsa.pub host.domain.tld:.ssh/authorized_keys2
3. ssh-agent sh -c 'ssh-add < /dev/null && bash'

And this worked as expected until I rebooted the machine and
discovered that the passphrase for the Key needed to be entered again,
interactively. This will not work for me because once this device is
deployed, I will not have access to the command line at all, not via
SSH ror any other method. (Which is why I need _it_ to contact _me_ ;)

Thus, I need Expect to do the job for me, and now the problem is as
described below. The session is somehow disconnected once I issue:

ssh -p 3214 localhost

Once again, can anyone council me on what would cause this behavior? I
have poured through the manpage for Expect as well as SSH, and I have
done extensive googling on the problem with little luck.

Robert.

[Robert Denton]

Well as it turn out, using autoexpect was the answer. I am not sure why
exactly still but here is the difference between the two scripts, as you can
see, mine is much simpler (but doesn't work). I have carved all the comments
out of the auto-script for the sake of the post:

MINE:

#! /usr/bin/expect -f

spawn /usr/bin/ssh -R 4321:localhost:22 host.domain.tld

expect -re "word:"
send "password\r"
expect eof

AUTOEXPECT:

#!/usr/bin/expect -f

set force_conservative 0 ;# 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
set send_slow {1 .1}
spawn ssh -R 4321:localhost:22 host.domain.tld
match_max 100000
expect -exact "us...@host.domain.tld's password: "
sleep .1
send -s -- "password\r"
expect eof

Thanks the the help on this. r.
--

"Don Libes" <li...@nist.gov> wrote in message
news:s6a1xog...@peace.mel.nist.gov...

[Don Libes]

Looks like a timing issue - likely the getpass() bug that is common on
Linux systems. See the Expect FAQ for the full explanation.

Don

[Mewtwo]

goo...@headsprout.com (Robert Denton) wrote in message news:<b3c8e994.0402...@posting.google.com>...

You can create SSH keys without a passphrase so you will not be
prompted for one. This is sometimes necessary for server keys.

Also, regarding the original Expect problem: what operating system
and version are you running Expect on? What version of Expect and Tcl?

There have been problems on certain implementations of Unix
(e.g. AIX 4.3.3, 5L) and certain versions of Tcl (e.g. 8.3.2?).
Those problems seem to have arisen from an assumption in Tcl and
Expect that a read which returns 0 bytes indicates end of file.
It appears that assumption is false for terminal devices on some
Unix implementations. There are related posts in the archive for
this newsgroup.

[Robert Denton]

Well as it turn out, using autoexpect was the answer (please refer to thread
started on 2-26-04). I am not sure why

exactly still but here is the difference between the two scripts, as you can
see, mine is much simpler (but doesn't work). I have carved all the comments
out of the auto-script for the sake of the post:

MINE:

#! /usr/bin/expect -f

spawn /usr/bin/ssh -R 4321:localhost:22 host.domain.tld

expect -re "word:"
send "password\r"
expect eof

AUTOEXPECT:

#!/usr/bin/expect -f

set force_conservative 0 ;# 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
set send_slow {1 .1}
spawn ssh -R 4321:localhost:22 host.domain.tld
match_max 100000
expect -exact "us...@host.domain.tld's password: "
sleep .1
send -s -- "password\r"
expect eof

Thanks the the help on this. r.
--

--

"Mewtwo" <mew...@catlover.com> wrote in message
news:eb0be410.04030...@posting.google.com...