Controlling an interactive program from Ruby

ruby-talk
1

Hi,

I want to control an interactive program from Ruby, in the Expect style.
I’d normally use Expect, but I can’t get it installed. I was hoping I
could use Ruby.

I want to copy a large number of files from a remote location using scp.
I already have a script that generates the entire list of files to copy,
and figures out where each one goes. The problem is that these are spread
over 300 directories, and I don’t want to type my password 300 times.

This is what I wantn to automate:

$ scp dcarrera@zeno:/data/tmp/filename some/directory/
$ dcarrera@zeno’s password:

It seems like I should be able to handle that with Ruby.

Any ideas?

Thanks.

···

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

2

I want to copy a large number of files from a remote location using scp.
I already have a script that generates the entire list of files to copy,
and figures out where each one goes. The problem is that these are spread
over 300 directories, and I don’t want to type my password 300 times.

This is what I wantn to automate:

$ scp dcarrera@zeno:/data/tmp/filename some/directory/
$ dcarrera@zeno’s password:

Passwords are unsafe… take a look at ssh-keys.

It seems like I should be able to handle that with Ruby.

cat filelist | xargs scp …
mmm… maybe

···

On Sun, 13 Apr 2003 10:59:27 +0900, Daniel Carrera wrote:

–
Simon Strandgaard

3

I want to copy a large number of files from a remote location using scp.
I already have a script that generates the entire list of files to copy,
and figures out where each one goes. The problem is that these are spread
over 300 directories, and I don’t want to type my password 300 times.

Any ideas?

cat mybigfilelist | xargs -t -J {} -L2 scp {}
[snip]
cat mybigfilelist
source login@desthost:/destination/.
index.rbx admin@microsoft.com:/web/.
COMMAND.COM admin@microsoft.com:/winxp/.
AUTOEXEC.BAT admin@microsoft.com:/winxp/.
ruby.h admin@microsoft.com:/winxp/windows.h

···

On Sun, 13 Apr 2003 10:59:27 +0900, Daniel Carrera wrote:

–
Simon Strandgaard

4

This is what I wantn to automate:

$ scp dcarrera@zeno:/data/tmp/filename some/directory/
$ dcarrera@zeno’s password:

Passwords are unsafe… take a look at ssh-keys.

I’ll take a look at it.
Would you mind elaborating though?
Why are passwords unsafe? I always thought it was the best we got.
I don’t know what ssh-keys are, I’ll google that.

Thanks a lot,

···

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

5

$ scp dcarrera@zeno:/data/tmp/filename some/directory/
$ dcarrera@zeno’s password:

Passwords are unsafe… take a look at ssh-keys.

Thanks. It’s working great now.

···

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

6

This is what I wantn to automate:

$ scp dcarrera@zeno:/data/tmp/filename some/directory/
$ dcarrera@zeno’s password:

Passwords are unsafe… take a look at ssh-keys.

I’ll take a look at it.
Would you mind elaborating though?
Why are passwords unsafe? I always thought it was the best we got.

  • network packets can get sniffed by evil people hooked up
    to your network (hackers).

  • somebody can be watching what you are typing.
    Keystroke recorder, Video…

  • Someone can gain access to your plaintext password file…ugh!

I don’t know what ssh-keys are, I’ll google that.

google is good :slight_smile:

···

On Sun, 13 Apr 2003 11:26:20 +0900, Daniel Carrera wrote:

–
Simon Strandgaard

7

Simon Strandgaard wrote:

This is what I wantn to automate:

$ scp dcarrera@zeno:/data/tmp/filename some/directory/
$ dcarrera@zeno’s password:

Passwords are unsafe… take a look at ssh-keys.

I’ll take a look at it.
Would you mind elaborating though?
Why are passwords unsafe? I always thought it was the best we got.

  • network packets can get sniffed by evil people hooked up
    to your network (hackers).

My understanding was that ssh passwords are not sent in plain text. From
man ssh:

If other authentication methods fail, ssh prompts the user for a pass-
word. The password is sent to the remote host for checking; however,
since all communications are encrypted, the password cannot be seen by
someone listening on the network.

Anyway, I second the suggestion to use ssh-keygen to make RSA/DSA keys.
I was thinking of using expect for the same reason until I got key-based
authentication to work. It’s much nicer.

···

On Sun, 13 Apr 2003 11:26:20 +0900, Daniel Carrera wrote:

8

Simon Strandgaard wrote:

This is what I wantn to automate:

$ scp dcarrera@zeno:/data/tmp/filename some/directory/
$ dcarrera@zeno’s password:

Passwords are unsafe… take a look at ssh-keys.

The reasons given before don’t hold IMHO, as

  • no plaintext is used
  • whoever gets access to the script w/ the password inside can
    equally get the files in ~/.ssh/ and steal the key file
  • if you cannot trust the computer you’re using you’re screwed anyway.
    If “they” have a keystroke recorder, “they” can as well just copy your key
    files. Or they could have a modified ssh binary that saves everything
    it receives somewhere, or…

There’s however one (IMO) valid reason: passwords tend to be weak and
can be “easily” guessed.

I’ll take a look at it.
Would you mind elaborating though?
Why are passwords unsafe? I always thought it was the best we got.

  • network packets can get sniffed by evil people hooked up
    to your network (hackers).

My understanding was that ssh passwords are not sent in plain text. From
man ssh:

If other authentication methods fail, ssh prompts the user for a pass-
word. The password is sent to the remote host for checking; however,
since all communications are encrypted, the password cannot be seen by
someone listening on the network.

Moreover AFAIK the password is not sent at all, not even encrypted.
Rather something like the following happens:

server: send(CHALLENGE)
client: send(HASH_FUNC(F(recx(),PASSWORD)))
server: check whether recx() == HASH_FUNC(F(CHALLENGE,PASSWORD))

If you make

challenge = rand(100000000).to_s + Time.new.to_i.to_s,
def f(chall, pwd)
chall + pwd
end
def hash_func(txt)
Digest::MD5.hexdigest txt
end

you have a working secure (against eavesdropping, not man-in-the-middle attacks)
authentication scheme in Ruby.

Anyway, I second the suggestion to use ssh-keygen to make RSA/DSA keys.
I was thinking of using expect for the same reason until I got key-based
authentication to work. It’s much nicer.

Some sites don’t allow the use of keys :expressionless:

···

On Sun, Apr 13, 2003 at 12:16:54PM +0900, Joel VanderWerf wrote:

On Sun, 13 Apr 2003 11:26:20 +0900, Daniel Carrera wrote:

–
_ _

__ __ | | ___ _ __ ___ __ _ _ __
'_ \ / | __/ __| '_ _ \ / ` | ’ \
) | (| | |__ \ | | | | | (| | | | |
.__/ _,|_|/| || ||_,|| |_|
Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

From: Ean Schuessler ean@novare.net
The unrecognized minister of propaganda,
E
– Debian, joking

9

The passphrase on an ssh key tends to be equally weak (or totally
non-existent, if Daniel’s running ssh with RSA/DSA but empty passphrase).
It’s almost as bad as having a script with a password hard-coded in it.
However you can use a feature in .ssh/authorized_keys which lets you say
that a particular key is only usable from a certain IP address, and/or only
for running a particular command.

Otherwise, the main difference is that only a public key is stored on the
server side, not an encrypted password. If someone breaks into the server,
they can’t do a dictionary attack against a public key.

There are lots of other side-benefits to RSA/DSA authentication though - for
example being able to use the same key on lots of systems without any
security drawbacks, and being able to change the passphrase on your private
key whenever you like without having to log into all those systems. Strongly
recommended.

Regards,

Brian.

···

On Sun, Apr 13, 2003 at 05:06:42PM +0900, Mauricio Fern?ndez wrote:

Passwords are unsafe… take a look at ssh-keys.

The reasons given before don’t hold IMHO, as

  • no plaintext is used
  • whoever gets access to the script w/ the password inside can
    equally get the files in ~/.ssh/ and steal the key file
  • if you cannot trust the computer you’re using you’re screwed anyway.
    If “they” have a keystroke recorder, “they” can as well just copy your key
    files. Or they could have a modified ssh binary that saves everything
    it receives somewhere, or…

There’s however one (IMO) valid reason: passwords tend to be weak and
can be “easily” guessed.

10

Using an ssh-agent, gives you the benefit that you only have to fill in
the passphrase once. ‘ssh-add’ (on linux) can be used to add the
passphrase for a given key to the agent. From then on, all ssh sessions
using that key can easily be scripted without the need for giving in
passphrases. This is more secure than using empty passphrases, and also
more secure than storing the passphrase/password in your filesystem.

Ruben

···

On Sun, 13 Apr 2003, Brian Candler wrote:

The passphrase on an ssh key tends to be equally weak (or totally
non-existent, if Daniel’s running ssh with RSA/DSA but empty passphrase).
It’s almost as bad as having a script with a password hard-coded in it.
However you can use a feature in .ssh/authorized_keys which lets you say
that a particular key is only usable from a certain IP address, and/or only
for running a particular command.

11

The passphrase on an ssh key tends to be equally weak (or totally
non-existent, if Daniel’s running ssh with RSA/DSA but empty passphrase).

Well, I’m not. I realize how silly that would be. My passwords are
acutally fairly good.

Otherwise, the main difference is that only a public key is stored on the
server side, not an encrypted password. If someone breaks into the server,
they can’t do a dictionary attack against a public key.

There are lots of other side-benefits to RSA/DSA authentication though - for
example being able to use the same key on lots of systems without any
security drawbacks, and being able to change the passphrase on your private
key whenever you like without having to log into all those systems. Strongly
recommended.

That’s interesting. Where can I learn more about that?
I understand RSA from a mathematical perspective, but I’m not familiar
with these other advantages you point out.

···

On Sun, Apr 13, 2003 at 06:38:19PM +0900, Brian Candler wrote:

–
Daniel Carrera
Graduate Teaching Assistant. Math Dept.
University of Maryland. (301) 405-5137

12

The passphrase on an ssh key tends to be equally weak (or totally
non-existent, if Daniel’s running ssh with RSA/DSA but empty passphrase).

Well, I’m not. I realize how silly that would be. My passwords are
acutally fairly good.

OK - but then you must be supplying the passphrase to ssh somehow (and the
original thread was because you had problems supplying a normal password to
ssh)

Perhaps you are using ssh-agent? I had forgotten about that.

There are lots of other side-benefits to RSA/DSA authentication though - for
example being able to use the same key on lots of systems without any
security drawbacks, and being able to change the passphrase on your private
key whenever you like without having to log into all those systems. Strongly
recommended.

That’s interesting. Where can I learn more about that?
I understand RSA from a mathematical perspective, but I’m not familiar
with these other advantages you point out.

At the client side, your private key is encrypted with a symmetric cipher,
where the symmetric key is a hash of your passphrase. Hence if someone hits
you over the head and steals your laptop, the private key is no good to them
unless they break the symmetric cipher. They have to look over your
shoulder, watch you type your passphrase, then hit you over the head and
steal your laptop :slight_smile:

There’s an O’Reilly book on SSH which I’ve not seen but apparently is good.

Cheers,

Brian.

···

On Mon, Apr 14, 2003 at 08:23:59AM +0900, Daniel Carrera wrote:

On Sun, Apr 13, 2003 at 06:38:19PM +0900, Brian Candler wrote: