SSH Keys: Difference between revisions
No edit summary |
No edit summary |
||
Line 6: | Line 6: | ||
<!--T:1--> | <!--T:1--> | ||
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. | 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 tell Bob what is in the message, then that person has access to Alice's private key. | ||
<!--T:8--> | <!--T:8--> | ||
Line 13: | Line 13: | ||
<!--T:9--> | <!--T:9--> | ||
On our systems, PK is used in SSH several ways: | On our systems, PK is used in SSH several ways: | ||
* When connecting to our systems, your ssh client normally uses our system's public key to ensure that it has connected to the real (authentic) server. | |||
* PK is used to establish an encrypted session so that all following traffic is secure from eavesdropping. | |||
* The remote server can use your public key (found in .ssh/authorized_keys in your home folder) to verify your identity. If that fails, the remote server can ask for your password. This is really a secondary authentication mechanism, and is less desirable because your password is handled and possibly exposed. | |||
<!--T:10--> | <!--T:10--> | ||
We strongly recommend using PK for authentication. | 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, you must: | To use keys for authentication, you must: | ||
# Generate a key pair (private key and public key). | |||
# Copy the public key to remote servers you want to log in to 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]]. | |||
# Test. | |||
<!--T:3--> | <!--T:3--> | ||
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 | 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 log in to any machine where the public key is installed. | ||
<!--T:4--> | <!--T:4--> | ||
The process of generating an | 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 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 15:50, 30 September 2020
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 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:
- When connecting to our systems, your ssh client normally uses our system's public key to ensure that it has connected to the real (authentic) server.
- PK is used to establish an encrypted session so that all following traffic is secure from eavesdropping.
- The remote server can use your public key (found in .ssh/authorized_keys in your home folder) to verify your identity. If that fails, the remote server 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 key and public key).
- Copy the public key to remote servers you want to log in to 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 log in to any machine 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 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: