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 email@example.com firstname.lastname@example.org
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 via SSH are an easy way to share ports, apps, and services between two hosts.
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 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