Using Multiple Jump Hosts
Sometimes you need to jump through multiple hosts to get somewhere. You can do this using the
ProxyJump command in your
Host machine1 machine2 machine3
You can do a double hop through two hosts if needed, like this:
Host machine1 machine2 machine3
Or match everything in a domain like this:
Match host "*.example.com"
You can even do it depending on your current IP address:
Match host "*.example.com" !exec "ifconfig | grep -q ' 172.16.1.40 '"
Using ssh-copy-id with Jump Hosts
You can pass any
ssh option to
ssh-copy-id with the
-o option. By using the
ProxyJump option, you can use
ssh-copy-id to copy your key to a host via jump host.
Here's an example where I copy my ssh key to leia.spack.org via the jump host jump.spack.org:
# ssh-copy-id -o ProxyJump=jump.spack.org leia.spack.org
Number of key(s) added: 1
And then test it with:
# ssh -J jump.spack.org leia.spack.org
Welcome to Ubuntu 20.04 LTS (GNU/Linux 5.4.0-42-generic x86_64)
Mitigating SSH Brute Force Attacks
Setup a server with an open SSH port, and you'll soon notice a steady stream of attempted logins as attackers try and brute force their way in. The actual risk is low so long as your users have good passwords, but it makes a mess in the logs.
Reading Debian Administration I came across this idea for using iptables to restrict how frequently an IP can try and connect via SSH to your server.
Here is a very simple script which only allows a single IP address to SSH to your server 5 times every 60 seconds. Any IP address or subnet listed in TRUSTED_HOSTS will be able to connect as many times as it wants.
# Requires the ipt_recent kernel modules
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j ULOG --ulog-prefix SSH_brute_force
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 5 --rttl --name SSH -j DROP
for host in $TRUSTED_HOSTS; do
iptables -A SSH_WHITELIST -s $host -m recent --remove --name SSH -j ACCEPT
If you need to connect more frequently, you can either whitelist your IP address or using the connection sharing feature in modern versions of OpenSSH.
Versions of OpenSSH greater than 4.0 have a new feature which allows you to reuse a single SSH connection for all subsequent connections to that same host. This has two primary advantages
- New connections open nearly instantaneously after the first one. This is because all subsequent connections are using an already authenticated channel.
- Since all your SSH connections appear as a single TCP session, you can work around any restrictions at the destination which limits the frequency of connections.
It's easy to implement, add these lines to your
~/.ssh/config, check the ssh man page for details:
Update (8 Apr 08): I've been using this for a while now and the only downside I've found is that Subversion, using the
svn+ssh protocol, doesn't clean up properly after itself and leaves a stale socket file behind when it closes the connection. There are two ways around this, make a normal ssh connection into the server before using Subversion (so Subversion is using the socket but isn't the master), or delete the socket and retry. The error looks like this:
overkill(shand)$ svn ci -m ""
Control socket connect(/Usersfirstname.lastname@example.org:22):