Sometimes during day to day development I get a Port already in use error (or a variant of it), and I quickly want to see which process I forgot to terminate.
We can get the PID of the process occupying a port (e.g. 8888) with:
$ lsof -ti:8888
In order to quickly kill it, we can just pipe the output into the kill command
$ lsof -ti:8888 | kill -9
When using SSH bastion hosts it is common to set up new connections for many of the use cases discussed in the previous section throughout the day.
Normally we would start a new TCP connection for each one of them. However, open TCP connection are a finite resource on any machine, and each one of them takes some time to set up.
Multiplexing is a feature provided by SSH which alleviates these problems. It allows a single TCP connection to carry multiple SSH sessions. The TCP connection will be established and kept alive for a specific period of time and new SSH sessions will be established over that connection.
It works by creating a “control socket” file which will be used every time we want start a new connection.
We need to pass two command line arguments in order to leverage this feature:
Continue readingIf you are using SSH between Unix-like operating systems, you can also forward GUI applications over SSH. This is especially useful if your server doesn’t really have a user interface, but you need to check something on the fly with a web browser running on it.
This is possible because all Unix-like systems share a common GUI windowing system called X11, which is what provides the basic framework for the desktop environment: drawing and moving windows on the display device and interacting with a mouse and keyboard, etc.
Continue readingIn the previous section we saw how to make use of a jump host as a proxy to run commands into a remote machine.
Sometimes however, having a shell is not necessary, and the connectivity aspect of having a secure channel to the remote host is way more interesting.
SSH’s port forwarding feature allows us to create a secure channel to the remote host, and then use it to carry any type of traffic back and forth.
Scenario: you want to reach a specific application (which listens on a specific port) on the remote server.
For example (as in the image) we might want to connect to a PostgreSQL database application that is listening on port 5432 on the remote server, which is in a private subnet.
Continue readingSometimes some servers are unreachable to us due to network topology barriers, which are put in place for security reasons.
A common way to allow developers and sysadmins access is to provide public “bastion” or jump hosts, where one can obtain a shell and then use it to connect to one’s destination.
Looking at the picture above, things may seem pretty simple – but how is authentication handled when more than two parties are involved in a connection?
Continue readingIf you are using key pair based authentication with a passphrase for your keys, things can quickly get tedious as you have to input the passphrase every time you want to connect somewhere. If you want to avoid that, you can optionally use another preinstalled tool: ssh-agent.
The ssh-agent is a little helper program that keeps track your identity keys and their passphrases. The agent is consulted by the SSH client during the authentication process instead of the user having to specify a key – and having to type its passphrase all over again.
Adding keys
Simply add your private key file to the agent like this
Continue readingMuch like how the authorized_keys file is used to authenticate clients on the server, there is another file in the ~/.ssh folder called known_hosts, which is used to authenticate servers to the client.
Whenever SSH is configured on a new server it always generates a public and private key pair for the server, just like you did for your user in the previous section. Every time you connect to any SSH server, it shows you its public key first, together with a proof that it possesses the corresponding private key. If you do not have its public key yet, then your computer will ask for it and add it into the known_hosts file.
This way, the client can check that the server is a known one, and not some rogue server trying to pass off as the right one.
That’s why when you connect to a server for the first time, you might get a message like this:
Continue readingThere are two ways of authenticating to a server with SSH: user/password based authentication (which is now by many considered outdated and insecure) and key pair based authentication. Let’s start from the legacy one and build up to the modern way of doing things:
In this version, all you will need to to connect to your server is to run
Continue readingI have written this guide for developers who might be superficially familiar with the basics of SSH – maybe even fiddled with a file or two without really knowing what’s going on – and would like a more cohesive overview of its most powerful features.
This is essentially an organised collection of the main gotchas and topics that gave me (a dev, not a sysadmin) the most dexterity in jumping about from machine to machine in the cloud.
It is meant to be read in succession as each topic builds on the previous, but I also tried to keep them loosely coupled in case the reader is only interested in a particular section.
Have fun.
Disclaimer: This does not mean to be a complete list of all that is possible with SSH. That would probably take a book. Or two. But any feedback about additions is welcome.
SSH is a protocol built on top of TCP that is intended to provide a secure channel for a client and a server to communicate. In its implementation, it consists of two programs:
Continue reading