[svlug] Fun with ssh connections to internal machines

Jason Fritcher jkf at wolfnet.org
Mon Nov 17 17:15:23 PST 2014

I like the article and have been doing something similar for a couple years now, although with a few tweaks.

To keep the number of connections to the bastion host down, I open a single master session that remains in the background, and then further sessions are opened through the existing master session. Makes establishing new connections much faster as the full SSH handshake doesn’t have to occur between your local machine and the bastion. The master session also doesn’t tie up a TTY on the bastion and keeps the last log clean.

I started off using netcat as the article suggests, but discovered that if the SSH session doesn’t exit cleanly, there is a good chance the nc process will get lost and linger forever on the bastion. I’ve cleaned up lost nc processes that were over a year old. As an alternative, most, all?, modern ssh clients support -W, which causes a cleartext connection to be opened across the secure channel, to the specific host:port pair from the remote side. And because its the remote sshd process that opens up the connection, it gets cleaned up nicely in a non-clean disconnect.

Here are the snippets of .ssh/config that I use to make this all work.

Host *
  ControlPath /home/<username>/.ssh/master-%r@%h:%p

Host <bastion short name>
  Hostname <bastion fqdn>

Host <host behind bastion> *.<domain behind bastion>
  ProxyCommand ssh -W %h:%p <bastion short name>
  AgentForward yes

The Host * config establishes the path for the control socket to live for the master process. Other SSH sessions will look for a matching master session to open their connections through instead of establishing a new session, and only open a new connection if there is no master.

The Host <bastion short name> section serves two purposes, one it lets you establish options for connecting to the bastion, but it also provides a reference to the host by all the other hosts and ensures consistent hostname/ports for looking for the master socket. Do NOT do things like ssh agent forwarding in this block as we don’t want to expose those services on the bastion itself.

The third Host block is used to configure your connections to the hosts behind the bastion. You can add individual host entries, or use globbing on domain name or IP addresses to match against this block. This is the block you want to do things like ssh agent forwarding or X11 forwarding, etc.

To use this, in the morning, I run this command once to establish the master connection to the bastion host…

ssh -MNf <bastion short name>

and then I can connect to hosts behind the bastion as simply as this from my local machine…

ssh <host behind bastion>

I really like this pattern as it changes the bastion host from a machine you login through to more of an authenticated proxy.

Let me know if any part of this needs expanding upon.



> On Nov 17, 2014, at 3:01 PM, Don Marti <dmarti at zgp.org> wrote:
> Some people on this list could tell you stories about
> "unsanitary" use of SSH...here's an approach that is
> likely to keep you and your internal system safe even
> from a compromised bastion host (which does happen.)
>  http://osv.io/blog/blog/2014/11/17/ssh-without-trusting-bastion-host/
> Clever use of ssh ProxyCommand and the "nc" utility.
> (Yes, I know it's on an OSv blog, but it's about
> basic Linux tools...)
> -- 
> Don Marti                    
> http://zgp.org/~dmarti/
> dmarti at zgp.org
> _______________________________________________
> svlug mailing list
> svlug at lists.svlug.org
> http://lists.svlug.org/lists/listinfo/svlug

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4127 bytes
Desc: not available
Url : http://lists.svlug.org/archives/svlug/attachments/20141117/547528f1/smime.bin

More information about the svlug mailing list