in reply to Re^3: Why I'm Populating authorized_keys with Expect
in thread Populating authorized_keys with Expect

Ok, delving into more gory details...

The environment we're running in is that a perl script on PC is remotely executing a perl script on remA via ssh. That script needs to run a bunch of command sets on remB via ssh, intermixed with some proccessing.

To run the command sets on remB remotely without setting up the public/private keys, the user would have to continually enter the same password over and over again for each command set. By setting up the public/private key, I can remotely run as many sets of commands I want from remA on remB without bothering the user to enter the password over and over.

If ssh had the option to provide the password on the command line then I could programmatically re-enter the password for the user each time, but it doesn't (because of some bad security implications in allowing that), so no dice here.

I could use expect to programmatically provide the password for all the command sets, but then the user would have to enter the password for each session of running this tool. That has its own set of security implications that are non-optimal, so I chose to stay away from this solution as well.

All-in-all, using expect one time to get the public-private keys setup between remA and remB for the user, so they never have to do that again seems to be a good compromise for the level of security that I'm comfortable with.

I do like your explanation of how to reenable ssh tunnels just for me on this machine, as I never thought to try this. However, I'm guessing that doing this would also be politically frowned upon, whereas my current solution seems to not ruffle any feathers.

Things would be so much easier if all I had to do was solve problems from a technical perspective...

Thanks

-Craig

  • Comment on Re^4: Why I'm Populating authorized_keys with Expect

Replies are listed 'Best First'.
Re^5: Why I'm Populating authorized_keys with Expect
by salva (Canon) on Nov 26, 2008 at 16:51 UTC
    Which ssh client software and version is installed in remA?

    Later versions of OpenSSH have support for reusing SSH connections. More or less, it lets you login once and then start other ssh sessions that reuse the existent connection, without reauthenticating. See the documentation for the -S and -M flags on OpenSSH ssh manpage.

    A sample session: 

    salva@ubuntu:~$ ssh -M -S ~/.ssh/mux_socket -N -f 172.20.8.191 
# password prompt, appears here
# after authorization, process goes to background

salva@ubuntu:~$ ssh -S /home/salva/.ssh/mux_socket 172.20.8.191 echo "
+hello"
hello
salva@ubuntu:~$ ssh -S /home/salva/.ssh/mux_socket 172.20.8.191 echo "
+bye"
bye
salva@ubuntu:~$ ssh -S /home/salva/.ssh/mux_socket -O exit 172.20.8.19
+1
Exit request sent.

    [download]

    Lately, I have been working on Net::OpenSSH that is a module that does just that... is still very alpha quality, but at least you could use some code from there.

[reply]
[d/l]
      Now THAT is COOL! I like the idea of being able to reuse your connection session.

      Sadly, the remA machine is running the following ssh version:

      Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f

      Which doesn't have that functionality.

      I would love to use your Net::OpenSSH work, but the remA folks don't want me installing anything on that machine. I think my current plan is the best that I'll be allowed to use.

      Good luck with your Net::OpenSSH work. I'll be keeping an eye out for it.

      Thanks

      -Craig

[reply]
        So, is remA a Solaris box? Is mconnect available there? If so, you can use it to create a direct ssh connection from your PC to remB through remA: 
        $ ssh -o 'ProxyCommand ssh remA mconnect -r -p 22 remB' remB

        [download]
        As you can run Perl scripts in remA, another solution would be to implement your own netcat (or mconnect) in Perl.

        And you can combine that with the multiplexing feature: 

        $ ssh -M -S ~/.ssh/mux_socket -o 'ProxyCommand ssh remA mconnect -r -p
+ 22 remB' -N remB
$ ssh -S ~/.ssh/mux_socket remB COMMAND1
$ ssh -S ~/.ssh/mux_socket remB COMMAND2
...

        [download]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom