Skip to content

Files

Latest commit

66db92b · Nov 14, 2021

History

History
87 lines (68 loc) · 5.49 KB

ssh.md

File metadata and controls

87 lines (68 loc) · 5.49 KB

SSH keys

SSH keys serve as a means of identifying yourself to an SSH server using public-key cryptography and challenge-response authentication. One immediate advantage this method has over traditional password authentication is that you can be authenticated by the server without ever having to send your password over the network. Anyone eavesdropping on your connection will not be able to intercept and crack your password because it is never actually transmitted. Additionally, using SSH keys for authentication virtually eliminates the risk posed by brute-force password attacks by drastically reducing the chances of the attacker correctly guessing the proper credentials.

As well as offering additional security, SSH key authentication can be more convenient than the more traditional password authentication.When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.

SSH keys are not without their drawbacks and may not be appropriate for all environments, but in many circumstances they can offer some strong advantages. A general understanding of how SSH keys work will help you decide how and when to use them to meet your needs.

Background

SSH keys are always generated in pairs with one known as the private key and the other as the public key. The private key is known only to you and it should be safely guarded. By contrast, the public key can be shared freely with any SSH server to which you wish to connect.

The public key is generated by you, and then copied to any SSH server to which you wish to connect.

If an SSH server has your public key on file and sees you requesting a connection, it uses your public key to construct and send you a challenge. This challenge is an encrypted message and it must be met with the appropriate response before the server will grant you access. What makes this coded message particularly secure is that it can only be understood by the private key holder. While the public key can be used to encrypt the message, it cannot be used to decrypt that very same message. Only you, the holder of the private key, will be able to correctly understand the challenge and produce the proper response.

This challenge-response phase happens behind the scenes and is invisible to the user. As long as you hold the private key, which is typically stored in the ~/.ssh/ directory, your SSH client should be able to reply with the appropriate response to the server.

A private key is a guarded secret and as such it is advisable to store it on disk in an encrypted form. When the encrypted private key is required, a passphrase must first be entered in order to decrypt it. While this might superficially appear as though you are providing a login password to the SSH server, the passphrase is only used to decrypt the private key on the local system. The passphrase is not transmitted over the network.

Generating an SSH key pair

An SSH key pair can be generated by running the ssh-keygen command, defaulting to 2048-bit RSA (and SHA256) which the ssh-keygen(1) man page says is "generally considered sufficient" and should be compatible with virtually all clients and servers:

 ssh-keygen

Choosing the authentication key type

ssh-keygen defaults to RSA therefore there is no need to specify it with the -t option. But if we want to use another key type, say ed25519, key pairs can be generated with:

ssh-keygen -t ed25519

Set key size

Minimum key size is 1024 bits, default is 2048 (see ssh-keygen(1)) and maximum is 16384.

If you wish to generate a stronger RSA key pair (e.g. to guard against cutting-edge or unknown attacks and more sophisticated attackers), simply specify the -b option with a higher bit value, say 4096, than the default:

ssh-keygen -b 4096

Add generated key to GitHub

  • Login you GitHub account, and then click setting->SSH and GPG keys->SSH keys->New SSH key
  • Copy the generated public key to the input box

Test SSH key

ssh -T git@github.com

For GitHub does not provide shell access, if you are correctly authenticated, some message will print out:

Hi username! You've successfully authenticated, but GitHub does not provide shell access.

Use ssh protocol to access GitHub

When a repository is cloned with https:// protocol, then pushing a branch from local repository still requires username and correspoding password.

With public key copied to GitHub, we can clone a repository using SSH. In this way, the address of repository takes the form of git@github.com:username/repository.git. Now we can push to remote repostory without entering username and password.

Avoid being asked for "Enter passphrase for key"

Take /Users/yumeijie/.ssh/id_rsa for example

Before using Git, add your key to ssh-agent:

  1. Start ssh-agent if not started
$ eval `ssh-agent -s`
  1. Add your private key using ssh-add
$ ssh-add ~/.ssh/id_rsa
Enter passphrase for key '/Users/yumeijie/.ssh/id_rsa': 
Identity added: /Users/yumeijie/.ssh/id_rsa (/Users/yumeijie/.ssh/id_rsa)
  1. Check if the key is added

ssh-add ~/.ssh/id_rsa

 ssh-add -L
  1. Try to connect to your Git server
$ ssh -T git@github.com

Remove the passphrase from the key and use it unencrypted

For example: travis-ci requires 'enter passphrase for /home/travis/.ssh/id_rsa'

$ ssh-keygen -p -P "old_passphrase" -N "" -f ~/.ssh/id_rsa