On The Road To Professional Web Development | Secure Shell (SSH)

10 min readJun 4, 2020

*The objective of this article is to prepare for a technical interview. To succeed (1) we must be technically proficient, and (2) we must be capable of communicating our proficiency effectively.

In this post, we’ll first become conversationally fluent on the topic of SSH. Next we’ll run drills to get comfortable using its features in practical ways. Finally we’ll finish the discussion with a curated list of (reportedly) common interview questions.

This post is part of a series on becoming a professional web developer — click here to navigate to the table of contents*

Part I: Secure Shell (SSH)

How Difficult Is It To Master?

SSH is a network protocol. It encrypts data for secure transit over public networks (i.e. the internet). To understand how, we’ll need to learn a bit about public-key cryptography. Additionally, SSH offers many useful commands that we’ll need to learn. Some of these rely on networking concepts, which we’ll touch on when we discuss port forwarding.

SSH: What Is It?

SSH is a protocol for securely operating devices or services over an unsecured network. It’s typically used in a terminal session to remotely login to a terminal on a remote computer. Among other benefits, this is particularly convenient for a large category of system administration tasks.

Where Did SSH Come From?

SSH was preceded by its unsecured ancestors, famously including Telnet, File Transfer Protocol (FTP), and Berkeley R-Commands.

Tatu Ylönen invented SSH in response to his discovery of a password-sniffing attack during his time as a university researcher in Finland circa 1995. Instead of reading about it, you might enjoy this two minute video of Tatu telling the SSH origin story himself.

How Does It Work?

A typical play-by-play example may look something like this:

We’re using a computer with a bash-compatible OS (this is for the convenience of this example — not a requirement). We’ll refer to this as our local computer
We realize we need to securely inspect the contents of important file from another bash-compatible machine. We’ll call this the remote computer
In this example, say the remote computer has IP address remote_ip and we have our own user account called user
From our local computer, we open a terminal session, and in the bash prompt we type ssh user@remote_ip
We’re prompted for a password (which we know because user is our own account)
As soon as we provide the correct password, the bash prompt shows that we’re successfully connected. Interacting with this terminal session from our local computer, we can insert commands as though we are directly logged into the remote computer.
We use standard bash commands to navigate to the file, inspect its contents, then close the SSH connection with exit.
We realize we’ll need to do this many more times in the future, so we take the time to set up a public-private key pair on the remote and local computers. This way, we can interact with the remote computer securely without needing to type a password in every time we want to connect with it via SSH.

What Terminology Comes Up When Discussing SSH?

Berkeley R-Commands: prior to SSH, r-suite utilities enabled Unix users to log in or issue commands to other Unix machines remotely via TCP/IP. “SSH replaced many unsecured technologies, including the then-popular r-commands suite’s many utilities (e.g. rsh, rlogin, rexec, rcp)”
Block Cipher Modes: some ciphers operate on a fixed number of bits (a block), and various modes of operation exist to help hide patterns in the encrypted data. “SSH used cipher block chaining mode (CBC) until a security vulnerability was identified. SSH now uses counter mode (CTR) by default”
Cryptosystem: A cryptosystem is pair of algorithms that take a key and convert plaintext to ciphertext and back. “Plaintext is what you want to protect, ciphertext should appear to be random gibberish”
Diffie-Hellman Key Exchange: a now public domain algorithm (that existed since the 70’s) for securely exchanging keys over a public channel. “The principle behind this algorithm is easy to visualize. It is still in widespread use”
Digital Signature Algorithm (DSA): a federal standard for digital signatures that can also be used for encryption and decryption. “SSH-2 lets you select between RSA and DSA. Key generation in DSA relies on exponentiation over a modulus, while RSA relies on factoring large prime numbers”
File Transfer Protocol (FTP): an unsecured technology SSH effectively made obsolete. “FTP doesn’t encrypt traffic. It is still used for public file sharing, but for security reasons it is always recommended to use SSH FTP (sftp), or a secure variant of FTP called FTPS”
Internet Standard: a specification for internet-related technology. “Internet Standards are created and published by the IETF”
Internet Engineering Task Force (IETF): an organization promoting voluntary Internet standards. “The IETF secsh (secure shell) working group is responsible for the SSH-2 standard”
Message Authentication Code (MAC): wregqfrfqw. “SSH uses hashing MAC (HMAC) by default. Improvements using universal-hashing MAC (UMAC) are possible”
Message Authentication Code (MAC): wregqfrfqw. “SSH uses hashing MAC (HMAC) by default. Improvements using universal-hashing MAC (UMAC) are possible”
Network Service: computer applications that run at the application layer and above (as defined by the OSI model). “Examples include command line, login, file sharing, and remote command execution”
OpenSSH: a suite of networking utilities created and maintained by OpenBSD developers. “OpenSSH started as a fork of the original SSH program developed by Tatu Ylönen”
OpenBSD: OpenSSH was created by several of the OpenBSD developers. “OpenSSH’s logo is inspired by Puffy, OpenBSD’s official mascot”
Public-key Cryptography: a secure way to exchange information over public infrastructure (such as the internet). Includes built-in mechanisms to perform user authentication (to prevent unauthorized attackers from successfully initiating secure connections). “SSH uses a hybrid cryptosystem. Initial key exchange is done using a highly secure but computationally expensive asymmetric-key (a.k.a. public-key) strategy, but the brunt of the data is transferred using a much less expensive symmetric-key strategy. The data is secure only if the key exchange was secure, and it was, so the hybrid system gives us high security at a low computational cost”
Public Key Fingerprint: an identifier for a computer based on a public key. “If the fingerprint changes, SSH will notice and warn you that you might be at risk of connecting to ‘some other computer’. It’s not always malicious, but it’s always worth looking into”
PuTTy: a popular SSH client for Windows. “The name “PuTTY” has no official meaning”
Port 22: the standard port used with SSH. “This is reconfigurable, but a common convention. Some SSH best practices recommend changing the default port to reduce the risk of being discovered by external scanning utilities”
Randomart Image: in OpenSSH, randomart images are text-based images that visually represent a key. These are intended for human use — computers don’t have much need for them. “Randomart makes it easy for us to perform a quick sanity check if we so desire”
RSA (Rivest–Shamir–Adleman): a public-key cryptosystem that’s more secure than Diffie-Hellman, but computationally expensive compared to symmetric-key approaches. “RSA is commonly used, but due to it’s cost it’s mainly used to securely exchange”
Secure Shell (SSH): a network protocol for interacting with network services remotely and securely over an unsecured network (i.e. the internet). “The term SSH is commonly used as a verb — for instance when we’re required to ‘SSH into’ a remote computer. SSH is commonly performed over TCP/IP connections, but performance improvements are possible with SSH-over-SCTP”
SOCKS: an internet protocol that allows one client computer to connect to another computer via a third computer (called a SOCKS server). “SOCKS is an abbreviation for SOCKetS”
SSH-1: the original version of SSH. “SSH-1 is an entirely different protocol from SSH-2. While they have some functional similarities, SSH-2 has more robust security features and is strongly recommended over SSH-1”
SSH-2: this is a modernized version of SSH, and the most current / secure / popular as of this writing. “When people talk about using SSH, they’re typically implicitly referring to SSH-2”
SSH Client: software which uses the SSH protocol to connect to a remote computer (running SSH server software). “Many operating systems have this functionality builtin. Alternatively, PuTTy and OpenSSH offer SSH clients”
SSH Server: a background process that continually checks for incoming connection requests from SSH clients. “Daemons are background processes. SSH server software is commonly called an SSH daemon”
SSH Key: access credentials based on public-key cryptography, typically in the form of long strings of hex code. “SSH keys provide the ability to perform secure transactions without having to type in a password every time. For example, if you want to push code to GitHub without typing in your user information, you can set up SSH keys to make this happen.”
SSH Compensation Attack Detector: preserves data integrity. “This was injected into SSH-1 as a bug fix in response to a vulnerability identified with its error-checking detector, a 32-bit variant of the Cyclic Redundancy Check (CRC) algorithm”
Telnet: an unsecured technology SSH was designed to replace. “Contrary to common misconceptions, SSH is not a Telnet implementation. Telnet is no longer used, but a secure variant called TelnetS lives on”
Tunneling: any of many protocols that allow for the secure transmission of data. “A visualization of SSH tunneling is shown here”

Part II: Using SSH

Part II focuses on using SSH effectively. This is one of the rare posts where setting up a testbed to practice isn’t straightforward. If I find something we can use in-browser, I’ll update this post. For now, if you need a way to practice using SSH, I’ve included an Appendix at the bottom of this post discussing three options.

Part III: SSH Interview Questions

The goal of Part III is to summarize interview questions from across on the web. Questions have been paraphrased to avoid duplicate entries. Drill on these while practicing for the interview, and don’t hesitate to Google solutions.

compare SSH to scp
compare SSH to Telnet
compare SSH-1 to SSH-2
discuss AddressFamily option in SSH config
discuss blowfish option in scp
discuss debug mode
discuss disabling password authentication
discuss disabling root login
discuss encryption methods supported by OpenSSH
discuss error logs
discuss file copy via SSH
discuss limiting SSH access to a specified subnet
discuss ListenAddress in SSH config
discuss LoginGraceTime in SSH config
discuss MaxAuthTries in SSH config
discuss modifying SSH port numbers
discuss OpenSSH authorized_keys file
discuss OpenSSH key types
discuss passing input to SSH from a file
discuss password-free authentication
discuss port forwarding
discuss remote command execution
discuss remote GUI access capabilities of OpenSSH
discuss restarting SSH daemon
discuss scp
discuss scp bandwidth limiting
discuss SSH
discuss SSH ciphers
discuss SSH client config files
discuss SSH connection error troubleshooting
discuss SSH daemon status
discuss SSH IPv6 connections
discuss SSH log files
discuss SSH password access
discuss SSH server config files
discuss ssh-keygen
discuss sshpass
discuss the SSH default port
discuss user and group access policies on SSH servers
discuss welcome/warning messages on SSH servers upon login
discuss where OpenSSH stores trusted keys
list a command to check SSH server version
list an SSH command to access a remote machine
list an SSH command to access a remote machine via a non-default port

Appendix

We need a testbed to practice using SSH. The challenge is that we all have slightly different setups and equipment available to us, so without a web-accessible way to practice (which I’ll continue to search for) we’re not going to have a one-size-fits-all solution. For some of us, getting an SSH testbed up and running will go smoothly. For others, there will be some head banging. But it’s worth the effort! Getting hands-on practice with SSH (or any tool we want to learn) is the best way to solidify our understanding.

Three options available to us include:

Using a second computer (if you have an extra one available, this is the recommended route)
Setting up a virtual machine (a great learning experience, but time consuming. If you just want to get moving with SSH commands, use option 1 or 3)
We can SSH into our own computer, from the same computer (this may sound conceptually strange, but it’s extremely convenient and avoids network-related issues)

Let’s take a closer look at each option (in reference to 1–3 above):

The specifics for SSHing from one computer into another depend on the OS’s installed. Things we’ll need to keep in mind are: the host computer needs an SSH client (e.g. openssh-client), the remote computer needs an SSH server (e.g. openssh-server), the remote computer typically has a GUI-accessible menu we’ll need to use to enable remote login, and we may need to run a terminal command on each machine to let the SSH request through each computer’s firewall (e.g. sudo ufw allow ssh).
We can alternatively set up a virtual machine with VirtualBox. Get VirtualBox, get a copy of Ubuntu server (or your favorite OS), use it to create a VM (it will prompt you to pre-install openssh-server, click yes or just sudo apt install openssh-server on the VM later), set up a bridge network, run ifconfig from the VM to check its IP, run sudo ufw allow ssh from the VM to open up the firewall to allow SSH requests through, then verify you can connect via SSH using the ssh vm_username@vm_ip command.
SSH’ing into our own computer using ssh your_username@your_ip doesn’t appear to do anything — but looks can be deceiving. To demonstrate that something strange is happening (on a Mac / Linux computer), open a new terminal, cd into any folder, then ssh your_username@your_ip. You’ll notice may notice the working directory (pwd) has changed. Type exit to close the current SSH session, and notice how the pwd changes back to the one we were in prior to initiating the SSH connection. Also, we can SSH into our account from an SSH session into our account as many times as we want. We can see how many layers deep we are by running the command who or w (which is typically used to see how many users are connected via SSH). We can use exit (several times if needed) to close all SSH connections and return to our original (non-SSH connected) terminal session.

Closing Thoughts

I hope you’ve enjoyed this post as much as I enjoyed writing it. If you have thoughts you’d like to share, your editorial suggestions are always welcome. This post is part of a series on becoming a professional web developer. If you’d like to see more content like this, please click here to navigate to the table of contents.