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" firstname.lastname@example.org
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 email@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 firstname.lastname@example.org
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 email@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/config file could look as follows:
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
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
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:
The key's randomart image is:
| .=+*..o |
|.o oo++.. |
|+*B+ ..o |
|@++... S |
|+B= o |
|+o = |
|o+o . |
The command created the new key pair
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):
-----BEGIN OPENSSH PRIVATE KEY-----
-----END OPENSSH PRIVATE KEY-----
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC4nA2b61RYIN7kYSdy3FNUer1IzvsN8MXGMnK6vG6CQrWJszxDCg5jJBUbzfwv9Ro2WJ3uMtzlrAD0Iszn0XtzpgW+vpaQAN1RZcEvPeb0wM6hUru7HF2wtmlZI1MXZsnaDXKvy7WmO7oQQIIAjmB7PySBcvctjaKvgIVaJX/r/6oD/kNhNFoUsHtw326IjQe843kkN3tlYgtSesR9/5yk1zSF3q5Y6VKuJ3457TNlNWDLbXpU6P6OP2Yo1C/Tp3/zb/O1qw4xJeUCKL0dHs6ckecqABfZEPfm5vVf4GXkFmup+V3LjopaFQzr+ZGcTQrmvblLacwE9K7AxG1mR6hj [REDACTED]