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