update ssh keys docu

This commit is contained in:
viessm_h 2024-11-21 14:26:08 +01:00
parent 74c6e6866c
commit 8cf2674d33
Signed by: viessm_h
GPG Key ID: 0C24C120CDED56F0

View File

@ -18,7 +18,7 @@ is through the SSH protocol, and the use of SSH Keys is enforced.
For security reason, users **must always protect SSH Keys with a passphrase**. For security reason, users **must always protect SSH Keys with a passphrase**.
User can check whether a SSH key already exists. These would be placed in the **~/.ssh/** directory. `RSA` encryption User can check whether a SSH key already exists. These would be placed in the **~/.ssh/** directory. `RSA` encryption
is usually the default one, and files in there would be **`id_rsa`** (private key) and **`id_rsa.pub`** (public key). is usually the default one, and files in there would be **`id_rsa`** (private key) and **`id_rsa.pub`** (public key).
```bash ```bash
@ -31,23 +31,31 @@ For creating **SSH RSA Keys**, one should:
* Due to security reasons, ***always try protecting it with a password***. There is only one exception, when running ANSYS software, which in general should not use password to simplify the way of running the software in Slurm. * Due to security reasons, ***always try protecting it with a password***. There is only one exception, when running ANSYS software, which in general should not use password to simplify the way of running the software in Slurm.
* This will generate a private key **id_rsa**, and a public key **id_rsa.pub** in your **~/.ssh** directory. * This will generate a private key **id_rsa**, and a public key **id_rsa.pub** in your **~/.ssh** directory.
2. Add your public key to the **`authorized_keys`** file, and ensure proper permissions for that file, as follows: 2. Add your public key to the **`authorized_keys`** file, and ensure proper permissions for that file, as follows:
```bash ```bash
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys chmod 0600 ~/.ssh/authorized_keys
``` ```
3. Configure the SSH client in order to force the usage of the **psi.ch** domain for trusting keys: 3. Configure the SSH client in order to force the usage of the **psi.ch** domain for trusting keys:
```bash ```bash
echo "CanonicalizeHostname yes" >> ~/.ssh/config echo "CanonicalizeHostname yes" >> ~/.ssh/config
``` ```
4. Configure further SSH options as follows: 4. Configure further SSH options as follows:
```bash ```bash
echo "AddKeysToAgent yes" >> ~/.ssh/config echo "AddKeysToAgent yes" >> ~/.ssh/config
echo "ForwardAgent yes" >> ~/.ssh/config echo "ForwardAgent yes" >> ~/.ssh/config
``` ```
Other options may be added. Other options may be added.
5. Check that your SSH config file contains at least the lines mentioned in steps 3 and 4: 5. Check that your SSH config file contains at least the lines mentioned in steps 3 and 4:
```bash
(base) ❄ [caubet_m@login001:/data/user/caubet_m]# cat ~/.ssh/config ```console
# cat ~/.ssh/config
CanonicalizeHostname yes CanonicalizeHostname yes
AddKeysToAgent yes AddKeysToAgent yes
ForwardAgent yes ForwardAgent yes
@ -57,33 +65,39 @@ For creating **SSH RSA Keys**, one should:
### Using Authentication Agent in SSH session ### Using Authentication Agent in SSH session
By default, when accessing the login node via SSH (with `ForwardAgent=yes`), it will automatically add your By default, when accessing the login node via SSH (with `ForwardAgent=yes`), it will automatically add your
SSH Keys to the authentication agent. Hence, no actions should not be needed by the user. One can configure SSH Keys to the authentication agent. Hence, no actions should not be needed by the user. One can configure
`ForwardAgent=yes` as follows: `ForwardAgent=yes` as follows:
* **(Recommended)** In your local Linux (workstation, laptop or desktop) add the following line in the * **(Recommended)** In your local Linux (workstation, laptop or desktop) add the following line in the
`$HOME/.ssh/config` (or alternatively in `/etc/ssh/ssh_config`) file: `$HOME/.ssh/config` (or alternatively in `/etc/ssh/ssh_config`) file:
```
ForwardAgent yes ```ssh_config
``` ForwardAgent yes
* Alternatively, on each SSH you can add the option `ForwardAgent=yes` in the SSH command. In example: ```
```bash
ssh -XY -o ForwardAgent=yes login001.merlin7.psi.ch * Alternatively, on each SSH you can add the option `ForwardAgent=yes` in the SSH command. In example:
```
```bash
ssh -XY -o ForwardAgent=yes login001.merlin7.psi.ch
```
If `ForwardAgent` is not enabled as shown above, one needs to run the authentication agent and then add your key If `ForwardAgent` is not enabled as shown above, one needs to run the authentication agent and then add your key
to the **ssh-agent**. This must be done once per SSH session, as follows: to the **ssh-agent**. This must be done once per SSH session, as follows:
* Run `eval $(ssh-agent -s)` to run the **ssh-agent** in that SSH session * Run `eval $(ssh-agent -s)` to run the **ssh-agent** in that SSH session
* Check whether the authentication agent has your key already added: * Check whether the authentication agent has your key already added:
```bash
ssh-add -l | grep "/data/user/$(whoami)/.ssh" ```bash
``` ssh-add -l | grep "/data/user/$(whoami)/.ssh"
* If no key is returned in the previous step, you have to add the private key identity to the authentication agent. ```
You will be requested for the **passphrase** of your key, and it can be done by running:
```bash * If no key is returned in the previous step, you have to add the private key identity to the authentication agent.
ssh-add You will be requested for the **passphrase** of your key, and it can be done by running:
```
```bash
ssh-add
```
### Using Authentication Agent in NoMachine Session ### Using Authentication Agent in NoMachine Session
@ -93,11 +107,13 @@ starting the agent or forwarding it.
However, for NoMachine one always need to add the private key identity to the authentication agent. This can be done as follows: However, for NoMachine one always need to add the private key identity to the authentication agent. This can be done as follows:
1. Check whether the authentication agent has already the key added: 1. Check whether the authentication agent has already the key added:
```bash ```bash
ssh-add -l | grep "/data/user/$(whoami)/.ssh" ssh-add -l | grep "/data/user/$(whoami)/.ssh"
``` ```
2. If no key is returned in the previous step, you have to add the private key identity to the authentication agent. 2. If no key is returned in the previous step, you have to add the private key identity to the authentication agent.
You will be requested for the **passphrase** of your key, and it can be done by running: You will be requested for the **passphrase** of your key, and it can be done by running:
```bash ```bash
ssh-add ssh-add
``` ```
@ -135,23 +151,32 @@ chmod u+rw-x,go+r-wx ~/.ssh/id_rsa.pub
Once SSH Key is created, for testing that the SSH Key is valid, one can do the following: Once SSH Key is created, for testing that the SSH Key is valid, one can do the following:
1. Create a **new** SSH session in one of the login nodes: 1. Create a **new** SSH session in one of the login nodes:
```bash ```bash
ssh login001 ssh login001
``` ```
2. In the login node session, destroy any existing Kerberos ticket or active SSH Key: 2. In the login node session, destroy any existing Kerberos ticket or active SSH Key:
```bash ```bash
kdestroy kdestroy
ssh-add -D ssh-add -D
``` ```
3. Add the new private key identity to the authentication agent. You will be requested by the passphrase. 3. Add the new private key identity to the authentication agent. You will be requested by the passphrase.
```bash ```bash
ssh-add ssh-add
``` ```
4. Check that your key is active by the SSH agent: 4. Check that your key is active by the SSH agent:
```bash ```bash
ssh-add -l ssh-add -l
``` ```
4. SSH to the second login node. No password should be requested: 4. SSH to the second login node. No password should be requested:
```bash ```bash
ssh -vvv login002 ssh -vvv login002
``` ```