• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1233
  • Last Modified:

using expect with scp

I am wanting to use expect to automate the copying of files from one system to another with scp, the secure copy command.  Below is the syntax of my scp command:

% scp username@host_a:filename filename

This then gives me the following prompt:

username@host_a's password:

I want to use expect to automate the entering of the password, but I can't figure out how to do this.  I'm aware of some security flaws with this approach and am taking some measures to reduce the risks.  Below is the expect script I have written so far:

#!/usr/bin/expect -f

set timeout 3600
spawn /usr/local/SSH/bin/scp user@server1:setEnv.sh /tmp/setEnv.sh

  -re "*password*"
send "password\r"

My understanding of expect is quite rudimentary, but I am hoping to be able to work this out.  A correction to this script, or a very similar script which leads me to the solution would be great.
1 Solution
You don't say what the problem is, and I don't understand what you are trying to do with the
> expect
> {
>   -re "*password*"
> }

construction: For this purpose, you should be able to get away with:

#!/usr/bin/expect --
# What does "-f" do?

set timeout 3600
spawn /usr/local/SSH/bin/scp user@server1:setEnv.sh /tmp/setEnv.sh

expect "password:"
send "my_password\r"

( This is cribbed from the O'Reilly book
http://www.oreilly.com/catalog/expect/chapter/ch03.html )

For debugging expect scripts, it may be easier to run the expect interpreter and feed it the commands one by one.

If scp encrypts the password before sending it and the file as it's being received, IMO the main security risk is if other people have permission to read or execute your script.

Hope this helps,
why do you need expect for this? scp uses ssh for transport. And ssh could be set up to allow you without password from another mashine, given:
1) you permited that by creating .shosts in you  remote home;
2) remote mashine has your client mashine's public_key;
3) administrator of remote did not block this possibility.

ssh's documentation on subject:-----------
          First, if the machine the user logs in from is listed in
          /etc/hosts.equiv or /etc/shosts.equiv on the remote machine,
          and the user names are the same on both sides, the user is
          immediately permitted to log in.  Second, if .rhosts or
          .shosts exists in the user's home directory on the remote
          machine and contains a line containing the name of the
          client machine and the name of the user on that machine, the
          user is permitted to log in.  This form of authentication
          alone is normally not allowed by the server because it is
          not secure.

          The second (and primary) authentication method is the rhosts
          or hosts.equiv method combined with RSA-based host
          authentication.  It means that if the login would be
          permitted by .rhosts, .shosts, /etc/hosts.equiv, or
          /etc/shosts.equiv, and additionally it can verify the
          client's host key (see $HOME/.ssh/known_hosts and
          /etc/ssh_known_hosts in the FILES section), only then login
          is permitted.  This authentication method closes security
          holes due to IP spoofing, DNS spoofing and routing spoofing.
          [Note to the administrator:  /etc/hosts.equiv, .rhosts, and
          the rlogin/rsh protocol in general, are inherently insecure          and should be disabled if security is desired.]

Good Look!
If you'll post an acopy of exactly what's on the screen when you do an interactive scp copy (names/passwd changed...), I'm fairly sure I could write an expect script that would get the job done. As a reference look at question http://www.experts-exchange.com/jsp/qShow.jsp?ta=unix&qid=10307277 
Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

ssh-keygen to generate a pair of keys for youself.

apppend your ~/.ssh/identity.pub to server1 at /home/user1/.ssh/authorized_keys.

to save the hassle of dealing interaction, use a null passphrase for your private key during key generation.

If you need passphrase, then you need to use ssh-agent to answer the question about passphrase.

with all this setup, you should be able to do
scp this.file user1@server:/tmp/that.file

with no question asked.
ah, my description is for ssh1. If you are useing ssh2, the setup is slightly different. Let me know you are using ssh2 so that we can do it 100% SSH way.

I am using ssh2 and require solution.  I have just bought this answer and unfortunately I do not think this will work.

Please advise.

Thanks, M.
what exactly made you think it will not work?

ssh2 from Fsecure or ssh2 as in openssh?
the public key format is different; and authorization and authentication file are different. openssh's support for ssh2 works similar to ssh1, with ~/.ssh/authorized_keys2 instead of ~/.ssh/authorized_keys as in ssh1.
Fsecure's ssh2 use ~/.ssh2 and 'identification'
Thanks for the prompt reply.  I'll try it in the morning.
Hi all,

Thanks to jyu_88 for the guidance.

The version of secure shell I have downloaded uses two files called 'authorization' and 'identification'.

I have developed a solution.

A good resource to help me was a mirror of the ssh.org's FAQs:


Regards, M.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now