Heck, for a string manipulation that simple you don't even need `sed`, you can just use the shell -- modulo potential escaping errors (I haven't actually tested this), something like this should do the trick:

    ProxyCommand ssh -aY bastion 'nc -w 900 `x="%h"; echo ${x%%.bast}` %p'

I once made the following while drunk a few years back. It was a nerd-dare...

  # dark magicks for hopping hosts. first version
  # (you'll need to specify target user name though)
  Host *+*
        VerifyHostKeyDNS=no
        ProxyCommand	ssh $(echo %h | sed 's/^\([^+]*\).*$/\1/') nc $(sed -n '/^Host[ \t]*\('$(echo %h | sed 's/^.*+\([^+]*\)$/\1/')'\)$/,/^$/{/^.*HostName[ \t]*/{s///; s/[ \t]*$//; h}}; ${x; /./{p; b}; s/^/'$(echo %h | sed 's/^.*+\([^+]*\)$/\1/')'/p}' ~/.ssh/config) $(sed -n '/^Host[ \t]*\('$(echo %h | sed 's/^.*+\([^+]*\)$/\1/')'\)$/,/^$/{/^.*Port[^0-9]*/{s///;s/[ \t]*$//;h;};};${x;/./{p;q;};s/^/22/p;}' ~/.ssh/config)

This is great stuff -- we're adding .ssh/config automation to the next major rev of https://Userify.com (we're still in beta/MVP mode but coming out soon) so that you can automate each user's .ssh/config on the jumpbox/bastion based on the nodes/clusters that each user can log into. This same mechanism could be used to deploy .ssh/config on your Mac/Linux box.. but this is a really cool trick. wonder if it could be added to Userify somehow..

Can someone explain the use of nc here?

It is proxying the connection from the bastion to the real target.

http://en.wikibooks.org/wiki/OpenSSH/Cookbook/Proxies_and_Ju...

This is very clever :)

why does automating the use of a jump host increase your attack surface?

Calling into sed when you use ssh increases your attack surface to include sed's attack surface. And likely more.

I don't believe you understand how sed is being used here. The sed process doesn't even survive until the beginning of the connection.

It doesn't survive to the beginning of the second connection, but do be aware that nc/echo/sed are all run on bastion. You'd have to rearrange the quoting a bit to get sed locally.

If you're being paranoid, you can also break this like: ssh -v 'foo;bar.bast'

Still, the only way I see this being any kind of "attack surface" is if an attacker could control the hostname you're connecting to, and I'll bet there are much naughtier thing possible in that case.

Does the ProxyCommand directive run the rc scripts of the bastion account? If so, control over the box isn't needed, just control over the bastion user account. Setting a custom $PATH and providing a custom sed, or a custom echo for that matter, would be easier then. Absolute paths are important for this reason. This is exactly why ./ isn't in $PATH (like in DOS/Windows), so someone can't drop a commonly named executable somewhere that accidentally gets run.

Depends on your shell, but you can try this yourself -- for instance:

    $ ssh localhost -o ProxyCommand="ssh localhost 'pstree -a \$PPID >&2 ; nc %h %p'"
    sshd 
      `-bash -c pstree -a $PPID >&2 ; nc localhost 22
          `-pstree -a 6703

Bash invoked this way will be non-interactive. Often bashrc will test "$PS1" to bail early in this case, but the point remains that it does run. I also tried my command with echos before and after that test in my bashrc to confirm what happens.

sed only sees data from the user, so the only person in a position to leverage that attack surface is the user himself.

It will never touch any part of the network, or handle any untrusted input. So this is not a concern.