SFTP using expect script

[Gerard Schrago]

Below the very basic script I have made:
#!/usr/bin/expect
set argc [llength $argv]
set host_id [lindex $argv 0]
set user_id [lindex $argv 1]
set Password [lindex $argv 2]
set remote_file_s_ [lindex $argv 3]
set local_directory [lindex $argv 4]

spawn /usr/bin/sftp $user_id@$host_id
expect "password:"
send "$Password\n"
expect "sftp>"
send "get $remote_file_s_ $local_directory\n"
expect "sftp>"
send "quit\n"
exit

My questions:
How can I return potential errors to the calling process?
Is there a book with comprehensive examples to create state of the art script?

Thanks per advance for your help and support.

[Steven E. Protter]

Shalom,

Normal shell scripts have a variable set with return code for every line of code they execute:

$?

echo steve
rc=$?
return $rc

Returns the error code.

I'm wondering why sftp is being used. scp with password free connection can move these files without a complex expect script.

http://www.hpux.ws/?p=10

SEP

[Horia Chirculescu]

Hello Gerard,

>Is there a book with comprehensive examples to create state of the art script?

You can study the examples that came with expect.

http://expect.nist.gov/#examples

Horia.

[Gerard Schrago]

Thanks to both of you.
Steven, I wish I could use scp but I am bound to use SFTP; this is CIO decision and customer policy. Allthough we are passing over private network, DMZ, etc. we have to be securer than secure ;-)
Thanks and best regards.
Gérard.

[Rita C Workman]

Gerard.

sftp and scp are both part of the SecureShell protocols. The only difference here is the ease of scripting something.
By using the SSH protocols and setting up keys on both sides, you provide a secure method for transferring data *encrypted* between sites without passwords.

One of the MOST unsecure things you could do is put the password in plain text in a file, which is exactly what your script will do. Since mgmt obviously is seeking a safety and security of data transfer, you might want to point this fact out to them. Fact is, one of the biggest and hardest to control security threats is 'inside your shop'. And putting passwords in files - very bad!

Stephen told you well, you need to keep your data secure. And sometimes you have to teach the right way to do that to managers.

Just my 2cents,
Rita

[Steven Schweda]

> [...] I wish I could use scp but I am bound
> to use SFTP [...]

What does the "s" in "scp" stand for?
What does the "s" in "sftp" stand for?
What's the difference in the underlying
encryption software?

> this is CIO decision and customer policy.

Why? (When asking why, try asking the
questions above.)

> [...] sometimes you have to teach [...]

Or try, at least. Or try to get a reason
which makes more sense than none at all.

[mvpel]

I concur, Gerard.

This sort of thing is exactly what Secure Shell public key authentication was designed for, and it shouldn't be hard to make a case to take that approach, and you can use it either on SCP or SFTP - they use the same underlying protocol after all.

http://ask-leo.com/how_can_i_automate_an_sftp_transfer_between_two_servers.html

You can even lock down the authorized_keys so that the key you use for the file transfer can not be used to connect from any other host but the one you're using to fetch the file (from=fetch-host.you.com), and also make it impossible for the key to be used to start a shell (no-pty).

When you lock down the permissions of the password-less private key to 400 for the userid that will be using it, then you'll have a number of layers of security at work, and no plaintext password sitting in a script file.

See also http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html for a decent discussion of the subject.

[Gerard Schrago]

Dear all,

scp versus sftp: scp also require a password prior any transfer unless you specify -B option and then it is still refused with the rply : Permission denied (publickey,gssapi-with-mic,password) which lead to other administrative burden.
That's why I have to stick to the imposed SFTP. Regarding confidentiality it is preserved since the password is passed as an argument by the calling process (a compiled LISP process running on Linux).
With my best regards.

[James R. Ferguson]

Hi Gerard:

> Regarding confidentiality it is preserved since the password is passed as an argument by the calling process

That's not preserving the password's knowledge. A simple 'ps' can expose the arguments passed to the process.

Regards!

...JRF...

[Rita C Workman]

Gerard,

I think you are missing the point. I know it was a learning experience for me the first time I started using it too.

As part of SSH protocols you generate a 'key' (man ssh-keygen). It actually creates two files, one is a .pub (public) key and the other is considered the private key.
You send the public key to the remote server and the file in properly inserted on that system. Albeit under the boxes account /home/dirpath/.ssh or on other platforms or third party vendors it might be added to a database. In any event the remote server sets-up this 'key' file.

Then from the first/primary server you connect to the remote server and make the initial connection. In the background the systems 'shake-hands' so to speak and recognize that both sides have the same keys. Systems are happy and acknowledge each other.

NOW....when your primary server wants to connect next time....NO PASSWORD REQUIRED.
Hence, your local script does not require the password to be part of the syntax.

scp @:/dir/path

Piece of cake !
Encrypted, password-less and secure.
Both using the SSH protocols.

Kindest regards & hope this makes some sense,
Rita

[Chris Campbell 77]

Gerard,
I know your pain. I work in a bank and just finshed a huge project. We have around 100 servers which all interace with each other. Servers are scattered through out internal LAN, and DMZ. It was orginally 2 of us and 1 day into the project my colleague was pulled into another one.

We were required (from our CIO as well) to remove any FTP scripts,.netrc, clear text pw, etc.
I implemented SFTP communicating from UNIX to UNIX, and UNIX to Windows...vice versa.

Feel free to contact me regarding any questions you may have.