SSH Keys: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
No edit summary
(try to make the explanation and motivation clearer, some updates.)
Line 6: Line 6:


<!--T:1-->
<!--T:1-->
SSH relies on [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography] for its encryption. These cryptosystems have a private key, which must be kept secret, and a public key, which may be disseminated freely. In these systems, anyone may use the public key to encode a message; but only someone who posesses the private key can decode the message. This can also be used to verify identities; if someone is claiming to be Alice, the owner of some private key, Bob can send Alice a message encoded with Alice's well-known public key. If the person claiming to be Alice can then tell Bob what the message really was, then that person at the very least has access to Alice's private key.
SSH relies on [https://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography] (PK) for its security. PK is based on a "keypair", which consists of a private part (to be kept secret) and a public part, which can be disseminated freely. Anyone can use the public key to encode a message, but only someone who knows the private key can decode the message. PK can also be used to verify identities: if someone is claiming to be Alice, then a second party, Bob, can send Alice a message encoded with Alice's public key. If the person claiming to be Alice can then tell Bob what is in the message, then that person has access to Alice's private key.
 
PK systems are the basis for the SSL and TLS protocols that protect most internet traffic, such as https websites.
 
On our systems, PK is used in SSH several ways:
- First, when connecting to our systems, your ssh client normally our system's public key to ensure that it has connected to the real (authentic) server.
- Second, the PK is used to establish an encrypted session, so that all following traffic is secure from eavesdropping.
- Third, the remote system can use your public key (found in .ssh/authorized_keys in your home folder) to verify your identity.
- If that fails, the remote system can ask for your password.  This is really a secondary authentication mechanism, and is less desirable because your password is handled and possibly exposed.
 
We strongly recommend using PK for authentication.  This requires some additional configuration, but winds up being both more secure and more convenient.


<!--T:2-->
<!--T:2-->
To use keys for authentication, we:
To use keys for authentication, you must:
*Generate a key pair (private and public)
*Generate a key pair (private and public)
*Copy the public key to remote systems we wish to be able to log into and add it to the desired user's <code>authorized_keys</code> file (see [[Using_SSH_keys_in_Linux|using ssh keys in linux]])
*Copy the public key to remote systems you want to log into and add it to your <code>.ssh/authorized_keys</code> file (see [[Using_SSH_keys_in_Linux|using ssh keys in linux]])
*Ensure permissions are set properly, as described in [[Using_SSH_keys_in_Linux|using ssh keys in linux]]
*Ensure permissions are set properly, as described in [[Using_SSH_keys_in_Linux|using ssh keys in linux]]
*Test.
*Test.


<!--T:3-->
<!--T:3-->
When generating a key pair '''supply a strong passphrase'''.  If you do not supply a passphrase, or if it can be guessed, then anyone who gains a copy of your private key can login to any machines which use the matching public key for authentication.  
When generating a key pair, you must '''supply a strong passphrase'''.  If you do not supply a passphrase, or if it can be guessed, then anyone who obtains a copy of your private key can login to any machines where the public key is installed.


<!--T:4-->
<!--T:4-->
The process of generating an ssh key pair will depend on the operating system you have. For generating a key pair in windows using Putty or MobaXterm see [[Generating SSH keys in Windows]], for generating key pairs in linux/Mac's/Windows Cygwin see [[Using SSH keys in Linux]]. In addition if you are using the cloud, OpenStack also provides a method for creating keypairs see the [[Cloud_Quick_Start#SSH_key_pair|ssh key pair]] section on the cloud quick start page.
The process of generating an ssh key pair will depend on the operating system you use. For the Windows Putty or MobaXterm clients, see [[Generating SSH keys in Windows]]. For a Unix-like environment (Linux, Mac, Windows Subsystem for Linux or Cygwin), see [[Using SSH keys in Linux]]. In addition if you are using the cloud, OpenStack also provides a method for creating keypairs see the [[Cloud_Quick_Start#SSH_key_pair|ssh key pair]] section on the cloud quick start page.


<!--T:6-->
<!--T:6-->

Revision as of 04:36, 18 September 2020

Other languages:

Parent page: SSH

SSH relies on public key cryptography (PK) for its security. PK is based on a "keypair", which consists of a private part (to be kept secret) and a public part, which can be disseminated freely. Anyone can use the public key to encode a message, but only someone who knows the private key can decode the message. PK can also be used to verify identities: if someone is claiming to be Alice, then a second party, Bob, can send Alice a message encoded with Alice's public key. If the person claiming to be Alice can then tell Bob what is in the message, then that person has access to Alice's private key.

PK systems are the basis for the SSL and TLS protocols that protect most internet traffic, such as https websites.

On our systems, PK is used in SSH several ways: - First, when connecting to our systems, your ssh client normally our system's public key to ensure that it has connected to the real (authentic) server. - Second, the PK is used to establish an encrypted session, so that all following traffic is secure from eavesdropping. - Third, the remote system can use your public key (found in .ssh/authorized_keys in your home folder) to verify your identity. - If that fails, the remote system can ask for your password. This is really a secondary authentication mechanism, and is less desirable because your password is handled and possibly exposed.

We strongly recommend using PK for authentication. This requires some additional configuration, but winds up being both more secure and more convenient.

To use keys for authentication, you must:

  • Generate a key pair (private and public)
  • Copy the public key to remote systems you want to log into and add it to your .ssh/authorized_keys file (see using ssh keys in linux)
  • Ensure permissions are set properly, as described in using ssh keys in linux
  • Test.

When generating a key pair, you must supply a strong passphrase. If you do not supply a passphrase, or if it can be guessed, then anyone who obtains a copy of your private key can login to any machines where the public key is installed.

The process of generating an ssh key pair will depend on the operating system you use. For the Windows Putty or MobaXterm clients, see Generating SSH keys in Windows. For a Unix-like environment (Linux, Mac, Windows Subsystem for Linux or Cygwin), see Using SSH keys in Linux. In addition if you are using the cloud, OpenStack also provides a method for creating keypairs see the ssh key pair section on the cloud quick start page.

Here are some links to two-minute videos on setting up SSH keys: