Re^6: Why I'm Populating authorized

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

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

Replies are listed 'Best First'.
Re^7: Why I'm Populating authorized_keys with Expect by salva (Canon) on Nov 26, 2008 at 21:26 UTC
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]
Re^8: Why I'm Populating authorized_keys with Expect by cmv (Chaplain) on Dec 03, 2008 at 21:10 UTC
salva++ Brilliant idea to use mconnect! Unfortunately it doesn't work for me. A colleague of mine traced down the problem as far as this... For the record, I can't get the mconnect command to work as an ssh ProxyCommand. I was able to run it under truss, and I can see it forks a child process so that the parent handles the data in one direction and the child handles the data in the other. However, for some reason, it's failing to read the data. The sequence goes like this: `Parent - reads 20 byte version string from remote - writes 20 bytes to local Child - reads 31 byte version string from local - writes 31 byte version string to far end - reads 792 bytes of protocol data from local Parent - reads 744 bytes of protocol data from remote - hangs at read(5, 0x000264B4, 8192) Child - hangs at read(0, 0x000264B4, 8192)` [download] Neither of them writes the supposedly pending protocol data, and both are supposedly attempting to read more data, but not getting it. My guess is that it has something to do with line buffering and both processes are waiting until they get a line terminator which is not forthcoming. (The version number strings are terminated with a new line, but the protocol data block is not). I really wish I could have gotten it to work, it would have been a simple, easy solution for me. Thanks again! -Craig	[reply] [d/l]