Improved SSH security

In this technical newsletter we'd like to help you achieve a higher level of security when communicating with your remote Linux servers (AWS EC2 included).

First, let's pretend your Linux server is my_server.com and your username is my_username.

We'll first present the 4 steps and then we answer some of the "why" questions.

• Step 1: Create the ECDSA key pair
  

  ssh-keygen -t ecdsa -b 521 -C "my_user@my_server.com"

  You'll be prompted to enter the path for the key pair: my suggestion is ~/.ssh/id_ecdsa_my_server
  Then you'll be prompted for a passphrase for the private key. Choose a good one.
• Step 2: Protect the private key
  

  chmod 400 ~/.ssh/id_ecdsa_my_server

  On Windows you can set privileges also by right click on the private key / Properties / Security. Grant just read-only access for your user alone.
• Step 3: Copy the public key to the server
  

  ssh-copy-id -i ~/.ssh/id_ecdsa_my_server.pub my_user@my_server.com

  Note: if your SSH server listens on another port, add -p $port_number option to the above command.
• Step 4: Add your key to ssh-agent
  Enter the following 2 lines in ~/.bashrc or ~/.profile:
  

  eval $(ssh-agent -s)
  ssh-add ~/.ssh/id_ecdsa_my_server

  Then restart your console or run source ~/.bashrc — you'll be prompted for the passphrase.

That's it!
ssh my_user@my_server.com — and this time you should not be prompted for a password.

Why is this better than password-protected SSH?
First, passwords travel through the network between your machine and the remote server. In contrast, the private key will never leave your computer.
Second, you can protect the private key with file-system mechanisms. A key logger is enough to break your password-protected SSH session! But with key pair mechanism, an attacker needs to first gain file system access to your private key in order to connect. After that he/she needs the passphrase.

Why ECDSA instead of RSA?
ECDSA is harder to brute-force and much smaller in size (192b ECDSA is equivalent to ~1024b RSA key in terms of security). On the other hand it takes longer to encrypt and decrypt, but it's not something you observe in an SSH session.

What we did in Step 3?
We need to tell the server to authenticate my_user using the given key. To do that we need to copy the contents of the public key on the remote server inside ~my_user/.ssh/authorized_keys (this is a per-user operation) ssh-copy-id is the best tool that does exactly that.

What if you work on Windows?
I think you'll love Git for Windows. It contains BASH and a part of util-linux ported on Windows. It can replace Putty completely.

Is this the most secure way?
Not really, there is still place for improvement, but I'd like to keep this newsletter short. In a future newsletter we'll overcome a small problem that still remains. Did you spot it?

About this newsletter
This is the second of a series of technical newsletters by Edocti. We want to keep it technical and concise. We present things that we encounter during our R&D projects. Our main focus is Industrial Autonomous Driving, robotics and Industrial IoT. We care about things like RTOS (QNX, Integrity, OSEK) and RT programming, Linux (embedded, Yocto, RT-Linux, POSIX, ...), Deep Learning, computer vision and OpenVX.

You can give us your comments or responses to research@edocti.com