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

I cannot run nc on remA, since it is not installed, however I can use ssh.

The nc binary does not exist on remA, and there is resistance to do what they consider as "downloading" programs to the machine. Since the machine already has perl, it was easier for me to write the simple UDP forwarding perl script and run it there.

Running ssh on remA is no problem, which is why I'm using this solution. As you surmised, tunnel forwarding is disabled.

Many thanks for helping, even with limited information. Please feel free to ask or point me to any other possibilities that might occur to you.

Thanks

-Craig

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

Replies are listed 'Best First'.
Re^3: Why I'm Populating authorized_keys with Expect
by salva (Canon) on Nov 26, 2008 at 09:12 UTC
    It is still not clear to me what is the problem... If you can run ssh from remA, just ssh to remB and run the commands you need there. You will need to add option -t to your ssh commands in order to allocate a pseudo tty, so that passwords are requested. For instance: 
    $ ssh -t remA ssh remB

    [download]

    Anyway, reenabling ssh tunnels just for you is possible and not so tricky. All you need to do is to run another sshd with your own configuration in remA through another ssh connection:

    Copy /etc/ssh/sshd_config to your home and edit it enabling tunnels. Create a new set of dsa and rsa host keys on your home and set the paths on the configuration file accordingly.

    And then... 

    $ ssh remA -L... -R... -o 'ProxyCommand ssh remA sshd -i -f /your/home
+/your_sshd_config' remA-foo

    [download]
[reply]
[d/l]
[select]
      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

[reply]
        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]

In Section Seekers of Perl Wisdom