For an ssh connection to work, which of the following need to be true check all that apply

The SSH protocol supports many authentication methods. Arguably one the most important of these is Public Key authentication for interactive and automated connections.

Public Key authentication - what and why?

The motivation for using public key authentication over simple passwords is security. Public key authentication provides cryptographic strength that even extremely long passwords can not offer. With SSH, public key authentication improves security considerably as it frees the users from remembering complicated passwords (or worse yet, writing them down).

In addition to security public key authentication also offers usability benefits - it allows users to implement single sign-on across the SSH servers they connect to. Public key authentication also allows automated, passwordless login that is a key enabler for the countless secure automation processes that execute within enterprise networks globally.

Public key cryptography revolves around a couple of key concepts. The sections below explain these briefly.

Asymmetric Cryptography - Algorithms

As with any encryption scheme, public key authentication is based on an algorithm. There are several well-researched, secure, and trustworthy algorithms out there - the most common being the likes of RSA and DSA. Unlike the commonly known (symmetric or secret-key) encryption algorithms the public key encryption algorithms work with two separate keys. These two keys form a pair that is specific to each user.

Key Pair - Public and Private

In the SSH public key authentication use case, it is rather typical that the users create (i.e. provision) the key pair for themselves. SSH implementations include easily usable utilities for this (for more information see ssh-keygen and ssh-copy-id).

Each SSH key pair includes two keys:

• A public key that is copied to the SSH server(s). Anyone with a copy of the public key can encrypt data which can then only be read by the person who holds the corresponding private key. Once an SSH server receives a public key from a user and considers the key trustworthy, the server marks the key as authorized in its authorized_keys file. Such keys are called authorized keys.

• A private key that remains (only) with the user. The possession of this key is proof of the user's identity. Only a user in possession of a private key that corresponds to the public key at the server will be able to authenticate successfully. The private keys need to be stored and handled carefully, and no copies of the private key should be distributed. The private keys used for user authentication are called identity keys.

Setting Up Public Key Authentication for SSH

The following simple steps are required to set up public key authentication (for SSH):

1. Key pair is created (typically by the user). This is typically done with ssh-keygen.

2. Private key stays with the user (and only there), while the public key is sent to the server. Typically with the ssh-copy-id utility.

3. Server stores the public key (and "marks" it as authorized).

4. Server will now allow access to anyone who can prove they have the corresponding private key.

Handling of the Private Key

It is extremely important that the privacy of the private key is guarded carefully. For most user-driven use cases this is accomplished by encrypting the private key with a passphrase.

When a private key is needed the user is asked to supply the passphrase so that the private key can be decrypted. The handling of passphrases can be automated with an SSH agent.

In most automated use cases (scripts, applications, etc) the private keys are not protected and careful planning and key management practises need to be excercised to remain secure and compliant with regulatory mandates.

From Chaos to Order - SSH Key Management

In environments where users are free to self-provision authentication keys it is common that over the years the numbers of provisioned and deployed keys grow very large. Since there is no way to find out who owns or has originally provisioned a given public key found on a server, and since these keys never expire, the true state of access control in large unmanaged environments can be very unclear or outright chaotic.

Managing and controlling access to servers and other IT infrastructure is a legal requirement for any enterprise that operates on regulated markets such as finance, energy, healthcare, or commerce. These enterprises need to employ solutions for SSH key management to control the access granted by SSH keys.