A few years ago I published a post about aliases, one of which I set up to allow me to SSH into a shared web server. Someone shared that post to Hacker News, so naturally the gaping flaws in my understanding of both aliases and SSH came to light. One piece of feedback I got was that my alias "sshchuck" was "suboptimal". At the time I barely had a grasp of SSH, but since then I've become far more familiar with it.
This post isn't going to be the holy grail of SSH, just some of the fundamentals that I find interesting and have incorporated in my home network environment.
SSH was designed as a replacement for Telnet which initiated remote sessions in plain text. SSH allows remote sessions over an encrypted connection. Within the OSI model, SSH is generally considered to be at Layer 7, the application layer. By default it uses port 22, but from a security standpoint, it's considered best practice to change it to a different non-standard port number to deter automated brute-force attacks.
Your OpenSSH client config file is stored in your home directly in ~/.ssh/config. A basic configuration includes the host, hostname IP address, the user, and a port number. We could also include options like ServerAliveInterval 60 which sends a keep-alive every 60 seconds to prevent timeouts, or ServerAliveCountMax 3 which will drop the connection if 3 keep-alives go unanswered.
An example SSH config looks something like this:
Host jupiter
Hostname 10.0.0.10
User chuck
Port 21098
Host mercury
Hostname 10.0.0.30
User chuck
Port 22212
Host web-server
Hostname server166.webhosting.net
User chuck12345
Port 22
Host lab-router1
Hostname: 10.10.10.1
User deviceadmin
HostKeyAlgorithms +ssh-rsa
PubkeyAcceptedAlgorithms +ssh-rsa
With this configuration, instead of running ssh chuck@10.0.0.10 -p 21098 to initiate a remote session to my server, I can simply run ssh jupiter. I went from typing 31 characters, to just 11 (or 5 with bash auto-completion) which expends less energy from my fingers, and billions of hours of time saved.
As shown in the last entry of my SSH config, if a device is using a legacy encryption algorithm, I may have issues trying to connect from a machine using modern encryption. I can add HostKeyAlgorithms=+ssh-rsa which will allow the client to accept the server’s ssh-rsa host key. I can also add PubkeyAcceptedAlgorithms=+ssh-rsa which will all allow RSA-based user authentication if the device also uses RSA keys. I have older Cisco gear in my home lab, so I add both of these options. Entering ssh deviceadmin@10.10.10.1 will output an error message stating that it was unable to negotiate. Adding these options make it so I don't have to manually enter ssh -o HostKeyAlgorithms=+ssh-rsa -o PubkeyAcceptedAlgorithms=+ssh-rsa deviceadmin@10.0.1.1 every time I want to login from a modern machine.
Note that SFTP also uses this config file, since it's FTP running over SSH. As Lars helpfully pointed out to me, SFTP and FTP are entirely different protocols. SFTP, despite the name, stands for SSH File Transfer Protocol and is built from the ground up as part of the OpenSSH suite, as opposed to FTP (File Transfer Protocol) which transfers files via plain text and has no meaningful security. SFTP runs inside an encrypted SSH connection via port 22 (by default), providing not just file transfer, but also file system operations like ls, mv, etc. There's also a distinction to be made about FTPS which is literally FTP with SSL/TLS encryption added to it.
Running ssh [host] is great, but you still need to authenticate your session. We can, however, configure a passwordless SSH login.
Assuming you don't have an existing ssh key pair, generate a new key pair with ssh-keygen -t rsa -b 4096 -C "name@example.com". This will generate an RSA key with a key length of 4096 bits. The -C option creates a comment, and conventionally that's the user's email address which is simply an identifier. Hit enter to accept the default file location, then enter again if you want an empty passphrase (less secure, but helps with automation). This generates your private and public keys to ~/.ssh/id_rsa and ~/.ssh/id_rsa.pub respectively.
Now to login to our server without a password, copy the public key to the server we're managing. Run ssh-copy-id [username]@[IP address of server] and you'll be prompted to enter the password. If all went well, you should receive a message Number of key(s) added: 1.
Now, all I need to do is run ssh jupiter and I'm immediately connected to my server.
I can also run an SSH command on another host with entering into a shell. For example I can run ssh chuck@10.0.0.10 "df -h" and it will provide the output of df -h as if it were ran on 10.0.0.10 as the user chuck.
Thanks for reading. Feel free to send comments, questions, or recommendations to hey@chuck.is.