Skip to main content

Reference articleSSH Overview

  • Updated

SSH Overview

This page provides a high-level overview of the Secure Socket Shell (SSH) protocol and Certificate Authorities (CA) and how to use them.

The intention is to equip users of Tehama's Secrets Vault SSH Secrets with helpful background knowledge.

What is SSH?

Secure Socket Shell (SSH) is a communication protocol. This protocol is used, mostly by administrators, to securely log in to remote computers. It provides strong authentication and secure, encrypted data communications.

For example, we have a user, sitting at his/her laptop at home. And we have a work server ("work-server") located at his/her office across town somewhere. Our user has an account, a 'username', to log in as on the work-server.

The user's home and his/her office are linked by an unsecured network connection. e.g.: Rogers internet at the user's home and whatever internet service the office uses.

The user can use SSH protocol authentication commands at a terminal/window on his/her laptop to connect to the work-server as 'username'.

Through this connection, once authentication succeeds, he/she can send/retrieve data to/from the work-server, as well as executing commands on the work-server. All command/data transmission is done using the SSH protocol's secure encrypted data communications.

We are interested in the authentication part of the protocol.

The authentication part of the protocol uses "public-key cryptography". This both:

  • authenticates the remote server (i.e.: verifies that this is the remote server you think it is.); and
  • lets the remote server authenticate you.

So, what is public-key cryptography?

What is public-key cryptography?

Public-key cryptography is also known as asymmetric cryptography.

To understand asymmetric cryptography, let's first explain what 'symmetric' cryptography is.

Symmetric cryptography uses one key. For a protocol using symmetric cryptography, (let's call it SymProtocol) both ends of your connection would have a copy of this key.

Data encrypted by this key can be decrypted by this same key.

For example, the user working from home would have a copy of this key on his/her laptop and the work-server located at the office would have a copy of this same key.

The user sends data using the SymProtocol to the work-server. SymProtocol uses the key to encrypt it before sending it. The work-server receives the encrypted data. SymProtocol decrypts the data on the work-server using the work-server's copy of the same key.

If anyone gets hold of this key, and intercepts the encrypted data, they too can use the SymProtocol to decrypt it with their (nefariously obtained) copy of this key.

So now let's explain what 'asymmetric' cryptography is.

Asymmetric cryptography uses two keys. For a protocol using asymmetric cryptography, (let's call it SSH - go figure!) one end of your connection would have one of these keys and the other end of your connection would have the other one.

One key is called the public key and the other is called the private key. These are referred to as the SSH keys.

Data encrypted by one of these keys can only be decrypted by the other one. e.g.: if the public key encrypts data, then only the private key can decrypt that data. And conversely, if the private key encrypts data, then only the public key can decrypt that data.

For example, the user working from home would have a copy of the private key on his/her laptop and the work-server server located at the office would have a copy of the public key.

The user sends data using SSH to the work-server. SSH uses the private key to encrypt it before sending it. The work-server receives the encrypted data. SSH decrypts the data on the work-server using the public key.

Of course if anyone gets hold of BOTH of these key, and intercepts the encrypted data, they too can use SSH to decrypt it with their (nefariously obtained) copies of both keys.

It is possible for the public key to be intercepted, but usually, the private key of the pair is very hard to get hold of.

This is because the private key is generated right there in the computer it lives in (the user's laptop in our example above) and should never be sent around anywhere.

Clearly asymmetric cryptography, AKA public-key cryptography, is safer.

So, how are SSH keys (public and private) generated?

How are SSH keys (public and private) generated?

Generating SSH keys is really simple.

First, the user's end of your connection (the user's laptop in our example) must have SSH protocol enabling software installed.

On Linux machines this is usually openssh. See https://www.openssh.com/ for more information on openssh.

On Windows machines you can use Powershell's 'Win32 OpenSSH'. See the section 'How do I use SSH on Windows machines?' for more details.

Examples below will assume you are working on Linux machines with openssh installed.

Next, you need a command line tool to generate keys. 'openssh' provides the "ssh-keygen" utility to do this.

Log in to the computer where you wish to generate the keys (the user's laptop in our example), open a command-line terminal and ...

prompt> ssh-keygen -t rsa -b 4096 -C "description of key-pair"

where

  • -t rsa tells it to use the 'rsa' encryption (other encryption types are dsa, edsa, etc) (default is rsa);
  • -b 4096 tells it how many bits to make the key (default depends on encryption type - for rsa it is 2048); and
  • -C "description of key-pair" is just a way to add an identifying comment to the keys (default is 'user@host').

You will be asked to provide:

  • the path/filename to save the keys to:
    enter any path you like; or select the default which is ~/.ssh/id-rsa (or ~/.ssh/id-<encryption-type> if you specified a different encryption type). The private key will be stored in 'path/filename' and the associated public key in 'path/filename.pub'.
  • a passphrase for the keys:
    enter any string; or select the default which is an empty passphrase.

Then you are done.

You will find the keys under the path you gave. The private key will be called "filename" and the public key will be called "filename.pub".

Now these new SSH keys exist on your computer.

Somehow the server at the other end of the connection you want to make (the work-server in our example) needs to get hold of the public key.

So how do you copy the public key to the server you want to ssh to?

How do you copy the public key?

This is how you copy the public key to the other end of the connection (to the server you want to connect to from one in which you generated the keys - the work-server in our example).

Note, you must be able to log in to the server via password or other credentials.

First, the server must also have SSH protocol enabling software installed (for example 'openssh' for Linux and Powershell's 'Win32 OpenSSH' for Windows).

Use the 'ssh' utility to push the public key into the '.ssh/authorized_keys' folder under the home account for 'username', where username is the user on the server that you want to ssh to.

prompt> cat path/filename.pub | ssh username@ip-of-the-server 'cat >> ~/.ssh/authorized_keys'

where

  • username:
    is the identity (user) that you want to work under on the server.
  • path/filename.pub:
    is the path and file name of the public key you want to copy over to the server.
  • ip-of-the-server:
    is the ip address of the server.

Give username's credentials (password) when prompted.

This adds the public key to the list of authorized keys in the server.

Note, an alternate way to do this is using 'ssh-copy-id' where it is available.

Now you can use the 'ssh' utility to connect to the server without being prompted for credentials, as long as you provide the private key to 'ssh' on the command line.

So, do you do that (use SSH to connect to the server without having to provide credentials)?

How do you SSH into a server?

You have generated your SSH keys, private and public, on your computer. You have copied the public key over to the server you want to connect to (the work-server in our example). Now you want to SSH into the server.

From your computer:

prompt> ssh -i filename username@ip-of-the-server

where

  • filename:
    is the path and file name of your private SSH key.
  • username:
    is the identity (user) that you want to work under on the server.
  • ip_of_the_server:
    is the ip address of the server.

But what if you don't want to have to copy the public key to the server? After all, that would seem unsafe.

There is a way around that. By using a trusted Certificate Authority (CA).

What is a Certificate Authority (CA)?

What is a Certificate Authority (CA)?

A Certificate Authority (CA) is, essentially, just an enhanced set of SSH keys, one private and one public, along with a secure environment for storing the private one and sundry other configuration data.

The 'private' key is called the CA key, usually with naming convention <filename>.key.pem.

The 'public' key is called the CA cert, usually with naming convention <filename>.cert.pem.

How are they enhanced? Well they contain more information than regular SSH keys. For example, the name of the CA and its contact information.

There are a lot of CAs out there in internet-land that you can use, like DigiCert and VeriSign, usually for a fee. These companies jump through hoops to prove that they are trustworthy.

Or you can create your own CA. Details for creating your own CA can be found online.

So we know what a CA is. But what does it do exactly?

What does a Certificate Authority (CA) do?

A Certificate Authority (CA) generates 'digital certificates', also known as 'SSH certificates'.

And what is an SSH certificate? It is a signed SSH public key.

So ... you guessed it. Basically, all a CA does is sign SSH public keys and turn them into SSH certificates.

(The SSH public key has been 'certified' by the CA, as it were.)

Is that all there is to it? No. There is more. Much more. When an SSH public key is signed by a CA, it also gains the following awesome properties:

  • an expiry date
  • a username (uniquely linking the public key to a particular user)
  • the ability to be authenticated on the server (at the other end of the connection) without being copied there first.

Okay, so the first property, an expiry date, is awesome because it means that even if a hacker gets hold of your public key, they won't be able to use it forever.

The second property, a username, is just as neat, since every time someone ssh's into a server using this set of keys, it will leave a trail of exactly who they are - which is great for auditing.

The third property, the ability to authenticate the key on the server without first copying the public key over to it, means you can avoid the risks that copying the key to the server and the risks that storing the key on the server entail.

This sounds too simple.

Well, yes, there is one more thing. The server must have 'trusted' the same CA used to sign the public key.

So how do you make your server 'trust' a CA?

How does a server 'trust' a CA?

A server trusts a CA by adding (copying) its public key (its 'cert.pem') into its list of trusted CA user keys.

Note, as above, your server must have SSH protocol enabling software installed (for example 'openssh' for Linux and Powershell's 'Win32 OpenSSH' for Windows).

Have an administrator in the Room's connected organization, with credentials on the server, copy the CA cert to the server, then edit the sshd_config file to trust it, adding it to the 'TrustedUserCAKeys' line:

prompt> scp ~/.ssh/my_ca_cert.pem @ip-address:/

Add/edit the following line to the file /etc/ssh/sshd_config:

TrustedUserCAKeys /my_ca_cert.pem

*Note, just add another 'TrustedUserCAKeys' line if you want multiple trusted CAs configured on the server.

**Note, in windows the path to the sshd_config file is relative to sshd binaries directory.

***Note, if the server has 'authorized principals' configured (a list of usernames that are allowed to log in via ssh using a CA cert), then any usernames to be used with this CA must be added to the list of principals.)

Now that it is trusted, how does it work?

Well, now when you ssh to that server, using an SSH certificate (signed public key) that was signed by that CA, it will check with the CA to see if the certificate is valid (has not expired etc) before successfully authenticating you. No need for that computer to have ever seen that SSH certificate (signed public key) before.

How do I use SSH on Windows?

To use SSH on Windows machines, you can install Powershell's ''Win32 OpenSSH' as follows.

From: https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH

  • Download the latest build of the 'Win32 OpenSSH' as a zip file.
  • Extract it somewhere in your environment.
  • Configure it as required. See instructions on the website.
  • CD to it.
  • Run the ssh executable from a powershell terminal as follows: ./ssh.exe

You should also find 'scp.exe' and 'ssh-keygen.exe' collocated with 'ssh.exe'.

You can, mostly, use this ssh executable as you would on Linux. Check the description in the above link for limitations.