Key Authentication

Authentication keys provide a cryptographic strength that even extremely long passwords can not offer. Furthermore, they allow to automate access using password-less login in order to script interaction with the computing facilities.

Password based authentication to the compute cluster is not supported! It is required to use an SSH key in order to logon to a submit Node of the Virgo cluster.

An SSH authentication key pair is comprised by the following parts:

A public key that is copied to the login-nodes
A private key that remains with the user (aka. identity key).

Security policies require the use of a strong passphrase for the private key. The private key needs to be kept as secret and is not allowed to be shared with other individuals or co-workers (cf. security-advice)

Key Self-Provisioning

Following files are involved in the configuration of public-private key based authentication:

Files	Description
`~/.ssh/id_ed25519`	Private key protected with passphrase.
`~/.ssh/id_ed25519.pub`	Public key copied to the login-nodes
`~/.ssh/authorized_keys`	Stores the private key located on the login-nodes.

User can self-provision a key pair with the ssh-keygen ¹ command:

# generate a key pair in ~/.ssh
ssh-keygen -q -t ed25519 -f ~/.ssh/id_ed25519

During key generation you will be prompted to enter a strong passphrase.
The passphrase will be required when the private key is used.

Change the passphrase of a private key with the ssh-keygen command:

ssh-keygen -f ~/.ssh/id_ed25519 -p

Authorized Keys

Access to login-nodes and submit-nodes using an SSH keys is granted by storing the public key in the ~/.ssh/authorized_keys file on a login node. Copy your public key to the login nodes with the ssh-copy-id command:

ssh-copy-id $USER@lxpool.gsi.de
# writes to ~/.ssh/authorized_keys

Alternatively use scp to copy a public key to a login node, and append it to the authorized keys file:

# copy your public key
scp ~/.ssh/id_ed25519.pub $USER@lxpool.gsi.de:.ssh/
# login
ssh $USER@lxpool.gsi.de
# append the key to the authorized keys files
cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys

The ~/.ssh/authorized_keys requires specific access permissions in order to be accepted by the ssh command. Use chmod to ensure correct access rights:

chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/authorized_keys

Key Agent

ssh-agent ² stores private keys used for SSH public key authentication. Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using ssh. The SSH agent prints the required environment variables needed for connection to standard output when started. Executing it in conjunction with the eval command will load those variables into the current shell environment:

eval $(ssh-agent)

The ssh-add ³ command loads a private key into a running SSH agent and prompts the user for the passphrase protecting the private key:

Option	Description
`-l`	Lists fingerprints of all identities currently represented by the agent.

# add an private key to the SSH agent
ssh-add ~/.ssh/id_ed25519
# list private keys known by the SSH agent
ssh-add -l

The ssh command supports to forward the connection to a local SSH agent from a login on a remote computer. However avoid this option if possible as described in security advice section:

Option	Description
`-A`	Enables forwarding of the authentication agent connection.

# forward your SSH agent over a jump host
ssh -A -J lxpool virgo.hpc

Key Agent Session

GNOME Keyring, KDE Wallet Manager & Mac OSX Keychain

Depending on you client platform you may already use a program providing functionality similar to the one described in this section.

Commonly used application to store private keys for SSH public key authentication are the GNOME Keyring ⁴ or KDE Wallet Manager ⁵ on Linux and Keychain ⁶ on Apple MacOS X. Windows users should follow instruction about OpenSSH key management ⁷ in the official documentation from Microsoft.

Typically users have multiple parallel shells. Therefore, it will be very convenient to be able to connect with a single ssh-agent from any shell instances. The ssh-agent-session ⁸ shell script provides this functionality.

File	Description
`~/.ssh/agent-session`	Stores agent connection information.

# start the ssh-agent (if not running)
» source ssh-agent-session
ssh-agent started

If the ssh-agent is running already, then the connection information will automatically loaded into the current shell environment:

» source ssh-agent-session
ssh-agent running with process ID 19264

Source this script within the your shell profile to immediately use a shared SSH agent on all newly started shells:

echo "source ~/bin/ssh-agent-session"  >> ~/.bashrc

Footnotes

Manual page ssh-keygen, OpenBSD Foundation
https://man.openbsd.org/ssh-keygen ↩︎
Manual page ssh-agent, OpenBSD Foundation
https://man.openbsd.org/ssh-agent ↩︎
Manual page ssh-add, OpenBSD Foundation
https://man.openbsd.org/ssh-add ↩︎
GNOME Keyring, GNOME Project
https://wiki.gnome.org/Projects/GnomeKeyring ↩︎
KDE Wallet Manager, KDE Project
https://utils.kde.org/projects/kwalletmanager ↩︎
Keychain Access User Guide, Apple Support
https://support.apple.com/guide/keychain-access ↩︎
OpenSSH key management, Microsoft User Documentation
https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement ↩︎
Shell script ssh-agent-session, GitHub
https://github.com/vpenso/scripts/blob/master/bin/ssh-agent-session ↩︎

--- title: Key Authentication --- Authentication keys provide a cryptographic strength that even extremely long passwords can not offer. Furthermore, they allow to automate access using password-less login in order to script interaction with the computing facilities. ::: {.callout-note appearance="simple"} Password based authentication to the compute cluster is not supported! It is **required to use an SSH key** in order to logon to a submit Node of the Virgo cluster. ::: An SSH authentication key pair is comprised by the following parts: - A **public key** that is copied to the [login-nodes][aQ4hL] - A **private key** that remains with the user (aka. identity key). [aQ4hL]: submit-nodes.html#login-nodes ::: {.callout-important appearance="simple"} Security policies require the use of a **strong passphrase** for the private key. The private key needs to be **kept as secret** and is not allowed to be shared with other individuals or co-workers (cf. [security-advice][TFvmH]) ::: [SODqI]: submit-nodes.html [TFvmH]: submit-nodes.md#security-advice ## Key Self-Provisioning Following files are involved in the configuration of public-private key based authentication: Files | Description -------------------------|------------- `~/.ssh/id_ed25519` | Private key protected with passphrase. `~/.ssh/id_ed25519.pub` | Public key copied to the [login-nodes][aQ4hL] `~/.ssh/authorized_keys` | Stores the private key located on the [login-nodes][aQ4hL]. User can self-provision a key pair with the `ssh-keygen` [^sshky] command: ```bash # generate a key pair in ~/.ssh ssh-keygen -q -t ed25519 -f ~/.ssh/id_ed25519 ``` * During key generation you will be prompted to enter a strong passphrase. * The passphrase will be required when the private key is used. Change the passphrase of a private key with the `ssh-keygen` command: ```sh ssh-keygen -f ~/.ssh/id_ed25519 -p ``` ## Authorized Keys Access to [login-nodes][aQ4hL] and [submit-nodes][SODqI] using an SSH keys is granted by storing the public key in the `~/.ssh/authorized_keys` file on a login node. Copy your public key to the login nodes with the `ssh-copy-id` command: ```bash ssh-copy-id $USER@lxpool.gsi.de # writes to ~/.ssh/authorized_keys ``` Alternatively use `scp` to copy a public key to a login node, and append it to the authorized keys file: ```bash # copy your public key scp ~/.ssh/id_ed25519.pub $USER@lxpool.gsi.de:.ssh/ # login ssh $USER@lxpool.gsi.de # append the key to the authorized keys files cat ~/.ssh/id_ed25519.pub >> ~/.ssh/authorized_keys ``` The `~/.ssh/authorized_keys` requires specific access permissions in order to be accepted by the `ssh` command. Use `chmod` to ensure correct access rights: ```bash chmod 700 $HOME/.ssh chmod 600 $HOME/.ssh/authorized_keys ``` ## Key Agent `ssh-agent` [^sshagt] stores private keys used for SSH public key authentication. Through use of environment variables the agent can be located and automatically used for authentication when logging in to other machines using `ssh`. The SSH agent prints the required environment variables needed for connection to standard output when started. Executing it in conjunction with the `eval` command will load those variables into the current shell environment: ```sh eval $(ssh-agent) ``` The `ssh-add` [^sshadd] command loads a private key into a running SSH agent and prompts the user for the passphrase protecting the private key: Option | Description -------|------------- `-l` | Lists fingerprints of all identities currently represented by the agent. ```bash # add an private key to the SSH agent ssh-add ~/.ssh/id_ed25519 # list private keys known by the SSH agent ssh-add -l ``` The `ssh` command supports to forward the connection to a local SSH agent from a login on a remote computer. However avoid this option if possible as described in [security advice][50MCl] section: [50MCl]: submit-nodes.html#security-advice Option | Description -------|------------- `-A` | Enables forwarding of the authentication agent connection. ```sh # forward your SSH agent over a jump host ssh -A -J lxpool virgo.hpc ``` ## Key Agent Session ::: {.callout-tip collapse="true" title="GNOME Keyring, KDE Wallet Manager & Mac OSX Keychain"} Depending on you client platform you may already use a program providing functionality similar to the one described in this section. Commonly used application to store private keys for SSH public key authentication are the GNOME Keyring [^gnkey] or KDE Wallet Manager [^kdewl] on Linux and Keychain [^keych] on Apple MacOS X. Windows users should follow instruction about _OpenSSH key management_ [^sshwin] in the official documentation from Microsoft. ::: Typically users have multiple parallel shells. Therefore, it will be very convenient to be able to connect with a single `ssh-agent` from any shell instances. The `ssh-agent-session` [^sshats] shell script provides this functionality. File | Description -----------------------|------------- `~/.ssh/agent-session` | Stores agent connection information. ```bash # start the ssh-agent (if not running) » source ssh-agent-session ssh-agent started ``` If the `ssh-agent` is running already, then the connection information will automatically loaded into the current shell environment: ```bash » source ssh-agent-session ssh-agent running with process ID 19264 ``` Source this script within the your shell profile to immediately use a shared SSH agent on all newly started shells: ```bash echo "source ~/bin/ssh-agent-session" >> ~/.bashrc ``` [^gnkey]: GNOME Keyring, GNOME Project <https://wiki.gnome.org/Projects/GnomeKeyring> [^kdewl]: KDE Wallet Manager, KDE Project <https://utils.kde.org/projects/kwalletmanager> [^keych]: Keychain Access User Guide, Apple Support <https://support.apple.com/guide/keychain-access> [^sshadd]: Manual page `ssh-add`, OpenBSD Foundation <https://man.openbsd.org/ssh-add> [^sshagt]: Manual page `ssh-agent`, OpenBSD Foundation <https://man.openbsd.org/ssh-agent> [^sshats]: Shell script `ssh-agent-session`, GitHub <https://github.com/vpenso/scripts/blob/master/bin/ssh-agent-session> [^sshky]: Manual page `ssh-keygen`, OpenBSD Foundation <https://man.openbsd.org/ssh-keygen> [^sshwin]: OpenSSH key management, Microsoft User Documentation <https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_keymanagement>