SSH: Security, Tips and Tricks

This post will cover the basics of what SSH is and how to use it on a Unix/Linux based machine. It will also go over a few common helpful tips like using key based authentication and using ‘Screen’ terminal application when performing long terminal commands over a patchy internet connection. It will also briefly touch upon downloading files over SSH.

SSH stands for Secure Shell. SSH is a protocol that uses cryptography to securely connect two machines via a server and client architecture. One of SSH’s strong points is that it’s able to do it over an insecure network (i.e. the internet).

The most popular implementation of the SSH protocol is OpenSSH. The people who implemented and maintain OpenSSH wrote both client and server terminal applications for the protocol. Both applications are most commonly used via Linux terminals, such as BASH shell (which comes with Linux), PuTTY (which is popular with windows users), and other terminal software. An OpenSSH client & server is also often bundled into a default Linux installation.

The OpenSSH client is used to connect to remote machines, whether it be another workstation machine running an OpenSSH server or a web server machine that is also running the OpenSSH server. Once connected, the client can either have some or even full access to the server machine via terminal. The access depends on the configuration. When connected there are also ways of elevating access and permission levels for the client if “remote root” is allowed and the root password is known to the client user.

To successfully make this connection you have to authenticate with the OpenSSH server. There are a few ways you can authenticate with the OpenSSH server. How you can authenticate is up to the administrator of the OpenSSH server.

A popular way to authenticate with an OpenSSH server is key based authentication. We won’t go into detail about why using a password generated by a human to authenticate is usually a lot less secure than a machine generated key. A common best practice is disabling password authentication and forcing all users to use keys.
To install OpenSSH you can use the following commands depending on package manager or OS. In most cases this will already be installed on your system if you are using Linux. If you are a Mac user, you can utilize brew to install OpenSSH.

$ sudo apt-get install ssh # OpenSSH client and server and needed packages for Ubuntu / Debian
$ yum -y install openssh-client #OpenSSH client for Fedora / centOS
$ brew install openssh #OpenSSH client for Mac using homebrew

To generate a set of keys (1 private and 1 public) you can run the following command in terminal. I would recommend to leaving everything default by hitting enter without typing anything when asked questions until you are returned to the terminal, see github reference for more key configuration help.

$ ssh-keygen -t rsa -b 4096 -C ""

If you change directory to the home directory there will be a hidden “.ssh” subdirectory that you can enter.

$ cd ~/.ssh
$ ~/.ssh $ ls
authorized_keys config id_rsa known_hosts

In this directory you will see a couple of files but we are only currently interested in the public key(~/.ssh/ we just generated.

We will need to copy the public key and provide it to the system admin of the OpenSSH server or add it ourselves to the server machine’s “authorized_keys” file if we have access to it.

$ cat ~/.ssh/

Examples of connecting authenticating with public key once it has been added to the server machine:

ssh user@

Once a connection is made and you are authenticated then you have terminal access to the machine and are free to view and manipulate files as you would on your own machine using terminal, like mentioned before, some restrictions may be in place but not necessarily.

To disconnect from the server machine’s terminal just simply type “exit” in terminal to end the SSH session

Using Screen/tmux terminal application on the server machine:
Once an SSH connection to the server is made, Screen and Tmux are nifty terminal applications that allow you to open multiple terminals through one connection. These terminal multiplexing applications do not come standard usually so you have to install them on the server machine. I’ll cover Screen; this is how you install it on several Linux distributions(distros). If you’re using Mac, you’ll find that Screen will already be installed, but you can duplicate the formula using brew if you need recent updates.

$ sudo apt-get install screen # installs screen for Ubuntu / Debian
$ yum -y install screen #OpenSSH client for Fedora / centOS
$ brew install homebrew/dupes/screen

Using terminals through screen is really nice because they are persistent. This means if you don’t explicitly exit them they will continue running in the background even when you disconnect from your SSH session. If you have some sort of terminal command to run that takes a long time to finish then you can play it safe and run it in a screen. This means that even if something was to happen to your machine the terminal window from each you ran it will continue running even if you disconnect. One of SSH weaknesses without screen is if a connection terminates between you and the server mid way through some action then the action process is usually killed and not finished but screen fixes this issue.

Screen basic key bindings and commands cheat-sheet:
Install & Commands:

screen # starts a new screen session and attach yourself to it and open one new terminal, if screen session is live already this opens another new terminal
exit # exist current terminal, if this is the last open terminal in the screen session then command ends the screen session
screen -list # list all sessions you have when attached or unattached.
Screen -x # attach to a non attached screen using PID(first several digits from name in -list)
screen -help # for additional documentation and help for commands not mentioned

Shortcut keys:

“Ctrl + a” followed by ‘c’ - will create and switch to another terminal
“Ctrl + a” followed by ‘n’ - will switch to next terminal, this can be used to quickly cycle through your terminals to get an overview of what is happening
“Ctrl + a” followed by ‘d’ will detach from session

Visit the official screen manual page for shortcuts to see a complete list of shortcuts or use manual pages in Bonus 2.

Bonus 1: Using scp to download files from server’s machine to your local machine. The example command below is being run from the local machine’s terminal to download a file from the server machine. scp is based on SSH and is usually enabled by default on the server side and also uses your public key for authentication.

$ scp user@ip_or_domain:/path/to/file/on/server/machine /path/to/download/location/on/client/machine

Bonus 2: Use Terminal Manual Pages by typing in terminal the following commands and scroll through with arrow keys and close by pressing the ‘q’ key

man ssh
man screen
man scp

Refences & helpful links:

2 Comment

  1. Great writeup, you covered quite a bit in a single post. A little something I would like to add to anyone reading.
    With the whole security/privacy revolution rolling over the internet at the moment, I’ve seen quite a bit of talk lately about disabling passwords authentication and only using key and certificate encryptions to secure SSH connections. One thing I should mention, is you can also enforce a dual method of encryption that requires a publickey and valid password. In other words if a hacker “somehow” manages to get ahold of your publickey or your password, you’re server won’t be completely waiting to be victimized. And since most modern Linux systems have various PAM modules installed by default, it shouldn’t take much to implement.This can be achieved by changing your AuthenticationMethods used in /etc/ssh/sshd_config to something similar to the following:

    AuthenticationMethods publickey,keyboard-interactive:pam

    It also helps to enforce a higher level of encryption, using modern cyphers, locking down users, and using a ~/.ssh/config file to ensure your not using the same publickey across all services that you connect to. I mean look at github they already display all their users publickeys in the open look at user: [GrahamCampbell’s publickey]( Note that if the rsa_id is the only publickey your using and your using it for DigitalOcean, GitHub, AWS, your companies servers, your local NAS, and who knows what else, than your services are already at risk. This is one of those types of “security by obscurity” measure that are often overlooks. I understand it can be a pain in the butt when ur keys have passwords. But if you use a ssh Keychain or ssh-add, you only need to input the password in once and you have nothing to worry about again until you reset your computer.

    One great resource I found for anyone setting up a SSH server is the [Mozilla Security Guidelines for SSH]( And if anyone wants to verify all user keys are openly available, here is a list of GitHubs [most active users]( just replace the username in the previous link with one of the users list here.

  2. Sergei says:

    Thank you very much for this comment, it adds great value to this post, and I personally learned something new myself :).

Comments are closed.