Saturday, November 3, 2012

passwordless ssh, scp , expect and ssh-agent

I have a soa user on host1, and a pvernet user on host2. pvernet@host2 can sudo su - soa, and carry out soa operations on host2.

My problem is to automate all operations on host2 with scripts running on host1.

ssh requires a password to be manually entered each time (no way to pass it as parameter, don't ask me why, I find it EXTREMELY annoying... probably for security reasons, but hey give me the option and let me decide).

An alternative is using http://en.wikipedia.org/wiki/Expect :

Create a file "remotels.expect" :
spawn ssh pvernet@host2 ls /opt/oracle
expect "password:"
send "mypassword\r"

set results $expect_out(buffer)
expect eof


then run it with "expect -f remotels.expect".

When you try to embed in the .expect file a "sudo su - soa" followed by a "expect password:", then a command "touch bla.txt", the command "touch bla.txt" is still executed as "pvernet" and not as soa. No clue why. Maybe I am "expecting" a bit too much from Expect.

The alternatives are:

  •  passwordless ssh with a passwordless rsa key (pvernet on host1 -> soa on host2) https://blogs.oracle.com/jkini/entry/how_to_scp_scp_and , it's very easy to setup (remember to chmod 644 authentication_keys !!!) and works like a charm.... but anybody gaining access to "pvernet" on host1 would then be able to run any command as "soa" on host2, which is a major security breach.



  • setting up a password protected rsa key + Expect (pvernet on host1 -> soa on host2): when you run the "ssh" command you would me prompted NOT with the soa password, but with the rsa key password...let Expect provide that rsa password, and then you need not to "sudo" since you act on host2 as "soa". I still need to test this. This is the same as the .ssh/identity approach described here http://www.slac.stanford.edu/BFROOT/www/Computing/Offline/DataDist/ssh-idfile.html



  • using ssh-agent to provide the "pvernet@host2" password for you, then use Expect to "sudo su - soa" remotely... this also can be tricky, still need to test.



Of course I have no option to set sudo to NOPASSWORD in the sudoers file.



No comments: