Working over SSH Connections

This page contains some tips that will help you work effectively over SSH connections.

Keep SSH Connections Alive

Sometimes, you will press any key and see

packet_write_wait: Connection to [IP REDACTED] port 22: Broken pipe

This happens because SSH automatically logs you out after a certain period of innactivity. This is desirable for security reasons, but can also get annoying when you are trying to work interactively with brief periods of innactivity.

As a work-around, you can pass the -o ServerAliveInterval=60 option to the ssh command. It specifies the number of seconds (in this case 60) that the client will wait before sending a null packet to the server to keep the connection alive. The full command would look as follows:

$ ssh -i /path/to/private/key -o "ServerAliveInterval=60" user@example.com

Using X11 Over SSH

X11 is the X Windows System, the GUI system used by most UNIX-like systems. An important feature of X11 is that it allows you to run GUI sessions remotely.

You can use X11 over an SSH connection by passing the flags -XY to the ssh command. The -X part enables X11 forwarding, and the -Y part enables trusted X11 forwarding. Note they are capital letters (their lowercase variants set completely different options). A command using these options can look as follows:

$ ssh -i /path/to/private/key -XY user@example.com

For the X11 session to work, you need a properly-configured X Windows client.

Linux – it is probably already installed, or you can do so easily.
macOS – download and install XQuartz.
Windows – you need to install a suitable X11 server. Some recommend Xming, but Nabla Zero Labs does not have enough knowledge or experience and thus cannot yet recommend it.

X11 is notoriously slow over SSH and there’s not much remedy. You can try changing the underlying ciphers and enabling compression, but chances are any improvement will be marginal. For example:

$ ssh -XY -c blowfish-cbc -o "Compression yes" -i /path/to/private/key user@example.com

To get a list of your available ciphers, use the following command:

$ ssh -Q cipher

Tweaking the ciphers can have dramatic security implications. Do not modify ciphers unless you know exactly what you are doing. A reasonable use case is when you are logged-in via VPN to your organization – you can reduce the strength of the underlying cipher because the VPN connection itself is already encrypted.

SSH Key Pairs

SSH can authenticate connections based on Public Key Infrastrucure (PKI). In short, you can create a pair of keys: a Private Key and a Public Key.

As their name suggests, the Private Key is private: you should treat it like a password. A Public Key is public: you can distribute it freely to anyone.

The server has a copy of your Public Key and can use it to authenticate your login request. For the login to succeed, you (the client) must have access to the corresponding Private Key (again: anyone with access to the Private Key can authenticate the connection).

You can tell ssh which Private Key to use for authentication via the -i flag (it stands for identity):

$ ssh -i /path/to/private/key user@example.com

If you’d rather not specify the Private Key every time, you can add an entry to the ~/.ssh/config file. That entry relates a server to a username and Private Key.

For example: suppose you have an account in example.com whith username username_1 and Private Key ~/.ssh/keys/example.com. You also have an account in example.org with username username_2 and Private Key ~/.ssh/keys/example.org.

Your ~/.ssh/config file could look as follows:

Host example.com
  User username_1
  IdentityFile ~/.ssh/keys/example.com

Host example.org
  User username_2
  IdentityFile ~/.ssh/keys/example.org

With this configuration in place, you can use ssh as follows:

$ ssh example.com

$ ssh example.org

Notice that we did not need to specify the username or identity file, as they were read directly from the ~/.ssh/config file. If you do not specify a User key, ssh will use your current username (that is, the username associated with the active shell).

In general, we recommend that you use separate Private/Public pairs for each server you connect to. To generate a new key pair, you can use the ssh-keygen command:

$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key ([REDACTED]): MyNewKeyPair
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in MyNewKeyPair.
Your public key has been saved in MyNewKeyPair.pub.
The key fingerprint is:
SHA256:MDBj8CpzoTMhVWD4xp8aZrsMLgYCnXWNG1Kr4BKLlr8 [REDACTED]
The key's randomart image is:
+---[RSA 2048]----+
| .=+*..o         |
|.o oo++..        |
|++oo.o+o         |
|+*B+ ..o         |
|@++...  S        |
|+B= o            |
|+o =             |
|o+o .            |
|o.oE             |
+----[SHA256]-----+

The command created the new key pair MyNewKeyPair and MyNewKeyPair.pub (the file with the .pub extension is the Public Key). Their contents look as follows (these are examples – never use them for any reason other than demonstrating how key pairs look like):

MyNewKeyPair

MyNewKeyPair.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4nA2b61RYIN7kYSdy3FNUer1IzvsN8MXGMnK6vG6CQrWJszxDCg5jJBUbzfwv9Ro2WJ3uMtzlrAD0Iszn0XtzpgW+vpaQAN1RZcEvPeb0wM6hUru7HF2wtmlZI1MXZsnaDXKvy7WmO7oQQIIAjmB7PySBcvctjaKvgIVaJX/r/6oD/kNhNFoUsHtw326IjQe843kkN3tlYgtSesR9/5yk1zSF3q5Y6VKuJ3457TNlNWDLbXpU6P6OP2Yo1C/Tp3/zb/O1qw4xJeUCKL0dHs6ckecqABfZEPfm5vVf4GXkFmup+V3LjopaFQzr+ZGcTQrmvblLacwE9K7AxG1mR6hj [REDACTED]