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

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

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

Replies are listed 'Best First'.
Re^4: Why I'm Populating authorized_keys with Expect
by cmv (Chaplain) on Nov 26, 2008 at 16:03 UTC
    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

      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.

      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.

        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