My Favorite SSH Tricks

After years and years of administering Linux servers on the web, I’ve picked up a few tricks. I’ve also read many books on SSH including SSH Mastery by Matthew W Lucas and SSH, The Secure Shell from O’Reilly. These are the tricks I’ve integrated into my day-to-day life.

Import Authorized Keys from GitHub

Using Git on GitHub without uploading an SSH key is very frustrating and I don’t recommend it. Since you push your public keys up to GitHub, why not use those when provisioning a server?

Note: Automating this could add an attack vector if someone were to take over your GitHub account. The threat actor could add their ssh key to your account and then get access to whatever servers import identities automatically. Make sure to inspect the ~/.ssh/authorized_keys file to confirm no odd public key is listed. Turn on MFA on your GitHub account to reduce the risk.

# Install on Ubuntu/Debian
apt install ssh-import-id

# OR

# Install using pip
pip install ssh-import-id

ssh-import-id-gh <username>

Using a Jumphost

Jump hosts allow you to connect to a server, THRU another server, all over SSH. This is great for bastion hosts or accessing a home server thru your home router. No need to add additional port forwards to reach the secondary server via SSH.

From the command line

ssh -J jumper@jumphost.internal user@dest.host.domain

SSH Config File

Who wants to remember the -J parameter for every connection? Use your SSH Config file to remember your settings. Edit ~/.ssh/config to configure for your user account.

Host dest-host
  User hunter
  Hostname dest-host.domain
  ProxyJump jump-srv
  IdentityFile ~/.ssh/dest-host.pem
  
Host jump-srv
  User other_user
  Hostname jump-srv
  IdentityFile ~/.ssh/jump-srv

You can now access dest-host thru jump-srv. This is useful if you have one host accessible on the web but would like to access a host inside of your network. Network administrators also configure a jumphost or a bastion host to concentrate access thru a hardened box exposed to the internet.

With this method, you can also see how we specified a different key file for each host. It helps keep your identities separate. I keep multiple key files for work and home and for different purposes depending on what I’m trying to connect to.

Canonical Domains and Hosts

Canonical domains and hosts allow you to use the hostname of a server but really connect via the fully-qualified domain name. This is great for confirming you are hitting the server you expect to access. It also helps with host key matching.

CanonicalizeHostname yes
CanonicalDomains ngetchell.com

Never Prompt for a Passwoord

While it is recommended to use SSH keys over passwords, the below host will force SSH to try your keys first.

Host dmz-host
  Host dmz-host
  User admin_account
  IdentityFile ~/.ssh/admin_account
  
Host *
  PreferredAuthentications publickey

Choose a Key by Domain

If you’re a consultant, being forced to sign into multiple domains, keeping track of each user, key, ports, or hostnames can be difficult. Consider using the following ssh user configuration to create domain specific configurations.

Host *.companyA.com
   User consultant
   IdentityFile ~/.ssh/companyA
   Port 2222
   
Host *.companyB.net
    User vendor
    IdentityFile ~/.ssh/companyB

Using SSH to connect to host1.companyA.com will now automatically connect on port 2222, as user consultant, with your companyA ssh key.

Tunnels

Tunnels via SSH are an easy way to share ports, apps, and services between two hosts.

Local Forward

Local forwards allow a client to connect to a server, then map a port from the server back down to the client. It is a simple way to bridge a mysql connection for use with MySQL Workbench on a client computer. You could also host a web server on a remote hosts then bring that bound port down to your local host.

# ssh -L <local port>:<remote hostname>:<remote port> <remote hostname>
ssh -L 5000:remote-host:443 remote-host
Host remote-host
  LocalForward 5000 localhost:4000

Remote Forward

Remote port fowards do the opposite. Once connected, SSH shares a client port, app, or service with a server.

In the past I’ve used this to establish SSH connections to two servers behind a firewall I had no control over. Since the client starts the connection, most firewalls allow it.

# ssh -R <remote port>:<local hostname>:<local port to foward> <hostname>
ssh -R 5000:localhost:4000 remote-host
Host remote-host
  RemoteForward 5000 localhost:4000

Dynamic or SOCKS Forward

A dynamic forward lets you route various types of traffic through a local port and is primarily used as a SOCKS proxy in the browser. If you have SSH access that allows for forwarding you can route your browser traffic through it as an almost simple VPN. Add-ons like Proxy Toggle for Firefox lets you configure a SOCKS5 proxy that you can quickly turn off an on as needed.

# ssh -D <local port> remote-host
ssh -D 55555 remote-host