You might be working in an environment where you always ssh from your machine to the middle machine and then connect to the destination machine. What a waste of time, lets see how you could automate it. The middle machine is frequently referred to as stepstone host.
On your workstation, add this sniplet to ~/.ssh/config
Host destination
ServerAliveInterval 60
ProxyCommand ssh stepstone nc -w 180 %h %pAfter you have altered your ~./ssh/config go ahead and try to connect directly to your destination machine.
workstation $ ssh destination
username@stepstone's password:
username@destination's password:
destination $Wow your automated it! The only thing is these stupid passwords. Check out how to implement ssh-keys into your session and how to distribute keys. This is not required, but after a few days of password typing, you will want to setup ssh-keys properly.
Here is a sniplet of a more complicated configuration:
ServerAliveInterval 60
Host stepstone
User myotherusername
Host 192.168.1.*
User yourusername
Port 2222
ProxyCommand ssh stepstone nc -w 180 %h %p| About | Consultancy | Articles | Contact |
|
|
|
|
|
| References | Red Hat Certified Architect | By Robert de Bock | Robert de Bock |
| Curriculum Vitae | By Fred Clausen | +31 6 14 39 58 72 | |
| By Nelson Manning | robert@meinit.nl |
Comments
Nice tip, after using this
Nice tip,
after using this for a week, I found lots of
ncprocesses on the stepstone host. It seems thatncdoesn't mind that it's not used anymore.I used a combination of keepalive for
sshand timeout forncto fix it:ProxyCommand ssh stepstone nc %h %p -w 180
ServerAliveInterval 60
If -- like me -- you are
If -- like me -- you are connecting from a Windows machine using PuTTY, there is also a very simple solution:
Enter "ssh name@machine.domain.tld" in the "Remote Command" field of the "SSH" configuration menu.
Like you said, if SSH public keys are installed on all machines, this provides a way to connect straight to the "stepstone" machine and, from there, to the "destination" machine.
I believe this is also possible by using ssh like this:
ssh name@stepstone "ssh name@destination", (note the "..." around the second ssh command) but I haven't tested this.
Ah yes, I've worked in a
Ah yes, I've worked in a similar environment. That was our Mk I technique. Mk II technique allowed full connectivity to the 'remote' network:
Set up dante on tsocks on your machine specifying that 192.168.1.0/24 uses 127.0.0.1:1080 as a proxy.
ssh -D 1080 stepstone
Instant SOCKS proxy. Socksify anything else you want to run and stepstone effectively vanishes.
why not just: ssh -t
why not just:
ssh -t stepstone ssh destination
Hi, I don't understand; the
Hi,
I don't understand; the -t option seems to be something different. From the man of ssh(1)
-t Force pseudo-tty allocation. This can be used to execute arbi- trary screen-based programs on a remote machine, which can be very useful, e.g., when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty.Have I missed something?
Robert de Bock
robert@meinit.nl