SSH Keys/fr: Difference between revisions

From Alliance Doc
Jump to navigation Jump to search
(diane27)
(Diane27)
Line 142: Line 142:
There are a large number of these key constraints, which are documented in the sshd man page ("man sshd" on a linux system).
There are a large number of these key constraints, which are documented in the sshd man page ("man sshd" on a linux system).


== PK Best Practices ==
== Meilleures pratiques ==
* DO encrypt your private key.
* Chiffrez votre clé privée.
* DO avoid copying your private key.  In particular, it should NOT appear on our clusters.
* Ne copiez jamais votre clé privée et, en particulier, ne copiez jamais votre clé privée sur une de nos grappes.
* DO use ssh-agent to make encrypted keys convenient.
* N'utilisez pas <tt>ssh-agent</tt> pour rendre vos clés plus pratiques.
* DO NOT use agent-forwarding if you can avoid it.  With agent-forwarding, any intermediate system(s) become trusted.
* N'utilisez pas <tt>agent-forwarding</tt> à moins que ce soit absolument nécessaire puisque tout système intermédiaire deviendrait fiable.  
* DO apply constraints to your public key to make it less powerful (dangerous).
* Définissez des contraintes pour votre clé publique pour la rendre plus sécuritaire.


Voyez aussi [https://www.youtube.com/watch?v=mRdqM1dgf3Q&feature=youtu.be ces courtes vidéos] sur comment configurer les clés SSH :
Voyez aussi [https://www.youtube.com/watch?v=mRdqM1dgf3Q&feature=youtu.be ces courtes vidéos] sur comment configurer les clés SSH :

Revision as of 17:00, 16 April 2021

Other languages:

Page enfant de SSH

Qu'est-ce qu'une clé SSH?

SSH utilise la cryptographie à clé publique (CP) ou cryptographie asymétrique pour sécuriser les connexions.

Dans ce mode de chiffrement, la clé qui est privée reste secrète et l'autre clé peut être divulguée à d'autres utilisateurs. Tous peuvent utiliser la clé publique pour encoder un message, mais seul le propriétaire de la clé privée peut utiliser cette clé privée pour le décodage.

La clé publique permet aussi de valider l'identité d'un utilisateur. Voyons un exemple : Robert veut communiquer avec Alice qui dit posséder une clé privée, mais il veut s'assurer qu'Alice est bien celle qui le prétend. Robert peut utiliser la clé publique d'Alice pour lui envoyer un message codé et si Alice peut prouver à Robert que son message est compris, nous pouvons au moins en conclure qu'Alice est effectivement propriétaire de la clé privée.

Les systèmes à CP sont au cœur des protocoles SSL et TLS qui protègent la plupart de communications sur l'internet, dont les sites HTTPS.

La CP a plusieurs usages sur nos grappes :

  • Quand vous vous connectez à une grappe, votre client SSH utilise habituellement la clé publique de cette grappe pour vérifier que la connexion se fait au bon serveur.
  • Une session cryptée peut être établie pour prévenir l'interception des messages échangés.
  • Le serveur distant peut utiliser votre clé publique (qui se trouve dans le fichier .ssh/authorized_keys de votre répertoire /home) pour vérifier votre identité et ainsi vous permettre de vous connecter.

Nous vous recommandons fortement d'utiliser l'authentification par CP qui est habituellement plus sécuritaire qu'un mot de passe.

Générer une clé SSH

Ceci exige du travail de configuration de votre part, mais une fois en place, vous y gagnerez en sécurité et en praticabilité.

Vous devez générer une paire de clés et installer la clé publique sur tous les systèmes auxquels vous voulez vous connecter.

De préférence, vous devriez créer une paire de clés sur votre propre ordinateur ou sur un ordinateur que vous croyez sécuritaire. Comme c'est le cas pour les mots de passe, la clé privée de cette paire ne devrait pas être partagée ou copiée sur un autre ordinateur.

When generating a key pair, you will be prompted for a "passphrase". This is a string that is used to encrypt the private key. You should provide a strong passphrase that is memorable, and is not a password. This passphrase offers protection if the private key file is stolen.

The specific process to generate an SSH key pair depends 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.

Installer une clé

Avec la base de données CCDB

Pour installer la clé, le système cible (la destination) doit connaître la partie publique de votre clé. Depuis mars 2021, nous avons ajouté un outil pratique pour faire cela. Voyez

https://ccdb.computecanada.ca/ssh_authorized_keys


ou via le menu suivant dans la CCDB
Ccdb-keys-fig1-FR.png

Collez votre clé publique dans la boîte de texte. Comme la clé privée et la clé publique sont au format texte, vous pouvez les voir, par exemple

cat .ssh/id_rsa.pub

qui devrait résulter en une longue suite de caractères comme

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQC3qeojDkUShnPTq9pI3cCZe+jgD6RKA/6CPsJIWZ8MqbX6wkk6
hHgKqKd2/9d7cj8e03Cfv4JLoD++P9fUPE3UyYrP/uVi4zytp5rmIZI4Qo1LvD1Obs0e78y0Dp7pfG1EHTYdn0p8
zHa0lNLOrZMmzDP0UMVdf4WKuv3Th2K/35yQ7DVIei6X/33Dcmsqd8bTXq7aFlw2y4sa/CHs314G6WYuJ9cTXtsW
Dlc9oWJuOVqILJLeGQpl3BVEM9aKcYksqLMV1UlZF8bHbry0PKCnrJrNMzVulWfnmSOZ+lPcV32OsDRkFaKsdxPy
+PxywieC86mxy1v216jeOdHnhLfOJc/VYDqf4egxReSCb3WOucHBB5J1jtDt47GuamKs+F2T7obqCb0J6oTyzgVF
RIZryxwvh5fQF5jk3LsBGsbhe9GYwDAk54GV6I0rWnXp56mJZjO4JCRQGbwLAJVxH4a7UrBmba2pRcZxEZmbIcBB
Sjb9KPECtaxiY/aty39077DCmcLCmzeOgBdh0zIkdBYu+OJ65MFKMxzoJWPDbZIcbSRGHEVhDnBZMNj1OiJS+E2D
A+F0tPH7J+xox1vUoXGAI0cNv+s/nlVRuOZoZjhk6s7tLXeVcToc+Y9Wqx8fdL7D4FegWwB9lsVhpfC4NaA9R8Ao
OfJUwHSNqUc6SfIt7w== user@machine

You can then paste this public portion of your key into the CCBD form. You should also provide a description for this key so you can keep track of them.
Ccdb-keys-fig2.png

After clicking "Add Key" your SSH key will show up in the section below.
Ccdb-keys-fig3.png

Une fois que votre clé est enregistrée dans la CCDB, elle peut être utilisée pour vous connecter à toutes nos grappes. En date de mars 2021, Dans le cas des nuages, OpenStack n'a pas accès aux clés enregistrées dans la CCDB.

La clé pourrait aussi être d'un autre format, comme cette clé publique au format PEM :

-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAxFm+Fbs+szeV2Vg2T5ufg8az0jD9DD/A0iNLKef2/0gPULn1ebFQ
SvQwts5ZGcza9t6l7fSKObz8FiAwXn+mdmXrxx3fQIepWa2FeCNbTkiKTTpNmERw
H0v3RR3DpJd8cpg5jdJbINlqDUPdqXxZDPIyZuHbEYUiSrb1v5zscVdgVqhJYi9O
OiEj7dPOLp1ko6s7TSgY8ejGnbmUL/gl+/dfhMNKdhLXMXWByucF1577rfAz3qPn
4JMWrG5TCH7Jj8NpIxFhkV9Qjy40Ml81yDqMlbuE9CUZzVhATe8MdIvcXUQej8yl
ddmNnAXmfTDwUd5cJ/VSMaKeq6Gjd/XDmwIDAQAB
-----END RSA PUBLIC KEY-----

Public keys in RFC4716 or PKCS8 formats will look similar to PEM, with small variations in the header and footer lines.

Les clés publiques au format RFC4716 et PKCS8 ressemblent à celles au format PEM et présentent des différences dans les lignes de l'en-tête et de la fin du texte.

Fichier authorized_keys

Le fait d'enregistrer votre clé publique dans la CCDB la rend disponible sur toutes les grappes, ce qui est pratique et souvent souhaitable.

However, there may be circumstances in which you want to install a key only on a specific system. You can do this by adding the key to a file in your home directory on that system. For instance, to install a key that only works on Cedar, copy your public key into the file ~/.ssh/authorized_keys on Cedar. This will allow you to log in to any of Cedar's login nodes using PK. On our systems (or any other with OpenSSH) the ssh-copy-id command is the most convenient way to do this:

 ssh-copy-id -i computecanada-key username@cedar.computecanada.ca 

The authorized_keys mechanism is standard, and almost universally used on the internet. It is however somewhat fragile: Specifically, SSH is quite picky about the permissions on the authorized_keys file, as well as your home directory and the .ssh subdirectory. This is described further in using SSH keys in Linux.

Advanced Key Usage

SSH Key Agent

Although it's important to secure your private key by encrypting it with the passphrase, it is inconvenient to have to enter your passphrase every time you use the key. Rather than leaving the private key unencrypted, we strongly suggest using an SSH key agent. You type the passphrase when starting up the agent, after which the agent supplies the private key for new connections. This avoids storing the unencrypted private key on permanent storage, where it is more vulnerable to being stolen or copied.

Advanced Key Generation

ssh-keygen shown above is using defaults, which are OK, but may not be ideal. for instance:

  • many people prefer a different key type (rather than the RSA default):
ssh-keygen -t ed25519
  • you can specify a comment for the key, which may be convenient for distinguishing among multiple keys:
ssh-keygen -C 'computecanada systems'
  • you can choose the name of the key file:
ssh-keygen -F computecanada-key

(this produces a file "computecanada-key" containing the private part, and "computecanada-key.pub" for the public part.

  • you can choose longer keys for some key types such as RSA:
ssh-keygen -t rsa -b 4096

SSH Key constraints =

The public key syntax permits you to provide a number of very useful constraints that limit what the key is allowed to do. By default, a public key installed without constraints can do anything. For instance, this public key:

 restrict,command="squeue --me" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx

can only perform one simple operation (showing whether you have any jobs in Slurm). An interesting example is:

 restrict,command="/usr/libexec/openssh/sftp-server" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx

which allows the key to be used only for SFTP, which is how sshfs works.

The key constraint can also limit which hosts can connect using the key:

 restrict,from="d24-141-114-17.home.cgocable.net" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx

Limiting by hosts is a powerful way to minimize the danger posed by a key being compromised. In this case, the "restrict" keyword turns off "pty allocation", which makes an interactive session behave peculiarly. For a source-constrained interactive session:

 restrict,from="d24-141-114-17.home.cgocable.net",pty ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGhczaUoV6SzR2VEf9Rp4/P9xHVU8S72CKHrwKU+Yntx

allows pty allocation.

There are a large number of these key constraints, which are documented in the sshd man page ("man sshd" on a linux system).

Meilleures pratiques

  • Chiffrez votre clé privée.
  • Ne copiez jamais votre clé privée et, en particulier, ne copiez jamais votre clé privée sur une de nos grappes.
  • N'utilisez pas ssh-agent pour rendre vos clés plus pratiques.
  • N'utilisez pas agent-forwarding à moins que ce soit absolument nécessaire puisque tout système intermédiaire deviendrait fiable.
  • Définissez des contraintes pour votre clé publique pour la rendre plus sécuritaire.

Voyez aussi ces courtes vidéos sur comment configurer les clés SSH :