Différences

Ci-dessous, les différences entre deux révisions de la page.

--- issue96:securite [2015/05/16 10:47] – [5] vincent
+++ issue96:securite [2015/05/16 15:12] (Version actuelle) – andre_domenech
@@ Ligne 16: / Ligne 16: @@
 Vous pouvez faire cette opération de plusieurs manières :
-* Mot de passe – vous vous authentifiez auprès du serveur en renseignant votre mot de passe. Cette méthode est simple car vous pouvez généralement retenir votre mot de passe, ce que signifie que vous pouvez facilement vous connecter depuis n'importe quel ordinateur. Cela reste la manière la plus commune de s'authentifier en SSH.
+* Mot de passe – Vous vous authentifiez auprès du serveur en renseignant votre mot de passe. Cette méthode est simple car vous pouvez généralement retenir votre mot de passe, ce que signifie que vous pouvez facilement vous connecter depuis n'importe quel ordinateur. Cela reste la manière la plus commune de s'authentifier en SSH.
-* Clé publique – cette méthode est bien plus sécurisée. Elle implique la création d'un trousseau de clés, bien sûr. Il est possible d'utiliser une pair de clés générée avec PGP ou GPG dans la plupart des versions courantes (la version 2.0.1 3 apporte ce support). Mais il existe aussi une méthode établie utilisant le programme Unix ssh-keygen. Cela est très similaire à la génération d'une pair de clés comme nous l'avons vu plus tôt. Lancez le programme « ssh-keygen », créez un peu d'entropie, générez une phrase de chiffrement secrète pour le protéger, et c'est bon.
-* Kerberos – Il fonctionne avec GSSAPI (General Security Services API). Ce dernier est une interface de programmation qui ne se limite pas qu'à Kerberos - il est sensé inclure plusieurs possibilités et, comme toute API qui se respecte, il ne s'attarde pas sur les détails. Mais la bibliothèque GSSAPI fournie ne supporte que Kerberos, donc il n'est pas encore autant étendu qu'il pourrait le devenir.
-* Keyboard-Interactive – Le serveur envoie une invite de commande ou plus au client pour entrer certaines informations. Il n'est cependant pas compatible avec tous les logiciels clients. Mais il fonctionne avec le terminal.
-Je ne m'étendrai pas sur les deux derniers outils, étant donné que je les trouve très particuliers. Si vous avez besoin d'en savoir plus sur un des deux, une recherche Google vous indiquera probablement ce dont vous avez besoin. Les méthodes les plus communes sont l'entrée d'un mot de passe et l'utilisation d'une clé publique. Et, comme beaucoup de choses concernant la sécurité, il y a un compromis entre sécurité et facilité d'utilisation. Le mot de passe est la façon la plus facile pour s'authentifier et tout le monde sait comment l'utiliser. Mais il est vrai que les mots de passe peuvent contenir des failles. Vous pourriez par exemple n'utiliser qu'un seul mot de passe pour tout, ou en utiliser un facilement devinable. Vous pourriez l'écrire sur un post-it « caché » sous le clavier. Vous pourriez le donner à quelqu'un d'autre, particulièrement dans un environnement professionnel où beaucoup de gens sont amenés à accéder aux mêmes ressources. Étant donné que l'idée de base de l'utilisation de SSH est d'augmenter le niveau de sécurité, je n'aime pas me fier aux mots de passe s'il existe une alternative. Et la clé publique se présente de plus en plus comme une alternative.
+* Clé publique – Cette méthode est bien plus sécurisée. Elle implique la création d'un trousseau de clés, bien sûr. Il est possible d'utiliser une paire de clés générée avec PGP ou GPG dans la plupart des versions courantes (la version 2.0.13 apporte ce support). Mais il existe aussi une méthode bien établie utilisant le programme Unix ssh-keygen. Cela est très similaire à la génération d'une paire de clés comme nous l'avons vu plus tôt. Lancez le programme « ssh-keygen », créez un peu d'entropie, générez une phrase de chiffrement secrète pour le protéger, et c'est bon.
+* Kerberos – Il fonctionne avec GSSAPI (General Security Services API). Ce dernier est une interface de programmation qui ne se limite pas qu'à Kerberos, il est sensé inclure plusieurs possibilités et, comme toute API qui se respecte, il ne s'attarde pas sur les détails. Mais la bibliothèque GSSAPI fournie ne supporte que Kerberos, donc il n'est pas encore aussi étendu qu'il pourrait le devenir.
+* Keyboard-Interactive – Le serveur envoie une  ou plusieurs invite(s) de commande au client pour qu'il entre certaines informations. Il n'est cependant pas compatible avec tous les logiciels clients. Mais il fonctionne avec le terminal.
+Je ne m'étendrai pas sur les deux derniers outils, étant donné que je les trouve très particuliers. Si vous avez besoin d'en savoir plus sur l'un des deux, une recherche Google vous indiquera probablement ce dont vous avez besoin. Les méthodes les plus habituelles sont l'entrée d'un mot de passe et l'utilisation d'une clé publique. Et, comme beaucoup de choses concernant la sécurité, il y a un compromis entre sécurité et facilité d'utilisation. Le mot de passe est la façon la plus facile pour s'authentifier et tout le monde sait comment l'utiliser. Mais il est vrai que les mots de passe peuvent contenir des failles. Vous pourriez par exemple n'utiliser qu'un seul mot de passe pour tout, ou en utiliser un qui soit facilement devinable. Vous pourriez l'écrire sur un post-it « caché » sous le clavier. Vous pourriez le donner à quelqu'un d'autre, particulièrement dans un environnement professionnel où beaucoup de gens sont amenés à accéder aux mêmes ressources. Étant donné que l'idée de base de l'utilisation de SSH est d'augmenter le niveau de sécurité, je n'aime pas me fier aux mots de passe s'il existe une alternative. Et la clé publique se présente de plus en plus comme cette alternative.
 ====== 2 ======
@@ Ligne 32: / Ligne 35: @@
 Authentification par clé publique
-La première étape passe par la génération d'une paire de clés. Comme nous l'avons vus précédemment dans le tutoriel sur le duel entre cryptographie symétrique et asymétrique, il existe plusieurs algorithmes qui peuvent être utilisés, RSA étant le plus répandu d'entre eux. Le principe de cette méthode consiste à générer deux clés, de façon à ce que la clé 1 décrypte ce que la clé 2 a chiffré, et inversement. Par convention, l'une d'elles est dite publique tandis que l'autre est dite privée. Pour l'algorithme, vous choisissez généralement entre RSA, DSA ou ECDSA. RSA utilise de grands nombres premiers pour générer ses clés, DSA (Digital Signature Algorithm) utilise des logarithmes discrets et ECDSA (Elliptic Curve DSA) utilise des courbes elliptiques. Chacun sont des exemples d'un algorithme à sens unique, ce qui signifie qu'ils utilisent un calcul facile à effectuer mais extrêmement compliqué dans le sens inverse. Actuellement, RSA semble être l'algorithme le plus largement utilisé, mais DSA est légèrement plus résistant et ECDSA est assez nouveau mais arrive vite car hautement efficace. Vu que RSA est le plus répandu, il paraît évident de l'utiliser ici à moins que vous n'ayez une bonne raison de ne pas le faire.
+La première étape passe par la génération d'une paire de clés. Comme nous l'avons vus précédemment dans le tutoriel sur le duel entre cryptographie symétrique et asymétrique, il existe plusieurs algorithmes qui peuvent être utilisés, RSA étant toujours le plus répandu d'entre eux. Le principe de cette méthode consiste à générer deux clés, de façon à ce que la clé 1 décrypte ce que la clé 2 a chiffré, et inversement. Par convention, l'une d'elles est dite publique tandis que l'autre est dite privée. Pour l'algorithme, vous choisissez généralement entre RSA, DSA ou ECDSA. RSA utilise de grands nombres premiers pour générer ses clés, DSA (Digital Signature Algorithm) utilise des logarithmes discrets et ECDSA (Elliptic Curve DSA) utilise des courbes elliptiques. Chacun sont des exemples d'un algorithme à sens unique, ce qui signifie qu'ils utilisent un calcul facile à effectuer, mais extrêmement compliqué dans le sens inverse. Actuellement, RSA semble être l'algorithme le plus largement utilisé, mais DSA est légèrement plus résistant et ECDSA est assez nouveau, mais arrive vite car hautement efficace. Vu que RSA est le plus répandu, il paraît logique de l'utiliser à moins que vous n'ayez une bonne raison de ne pas le faire.
-Le prochain choix que vous aurez à effectuer concerne la longueur de la clé et ici la valeur par défaut devrait être 2048 bits. 1024 bits, c'est plus que le record actuel de piratage par brute force mais pas tant que ça. Si vous avez un ordinateur puissant, choisissez 3072 bits. Si vous voulez en savoir plus sur la commande ssh-keygen, allez voir dans man-page. Cela devrait vous donner deux fichiers placés dans le même répertoire ~/.ssh/. Le fichier id_rsa (si vous utilisez RSA) est votre clé privée. L'autre fichier, id_rsa.pub, est votre clé publique.
+Le prochain choix que vous aurez à effectuer concerne la longueur de la clé et ici la valeur par défaut devrait être 2 048 bits. 1 024 bits, c'est plus que le record actuel de piratage par force brute, mais pas tant que ça. Si vous avez un ordinateur puissant, choisissez 3 072 bits. Si vous voulez en savoir plus sur la commande ssh-keygen, allez voir dans man-page. Cela devrait vous donner deux fichiers placés dans le même répertoire ~/.ssh/. Le fichier id_rsa (si vous utilisez RSA) est votre clé privée. L'autre fichier, id_rsa.pub, est votre clé publique.
 ====== 3 ======
@@ Ligne 45: / Ligne 48: @@
 Si vous utilisez Windows, vous pouvez télécharger puttygen.exe, qui fonctionne avec PuTTY. Vous trouverez les instructions à l'adresse https://kb.siteground.com/how_to_generate_an_ssh_key_on_windows_using_putty/. Vos deux fichiers se trouveront aux emplacements C:\Users\Your ID Name\.ssh\id_rsa (votre clé privée) et C:\Users\Your ID Name\.ssh\id_rsa.pub (votre clé publique).
-Une fois les clés générées, vous aurez besoin d'ajouter votre clé publique sur votre compte sssh du serveur. La procédure peut varier. Sur un système plus ou moins publique, il se peut que vous deviez passer par un site web qui ajoutera la clé sur votre compte ssh. Dans un contexte professionnel, vous pourriez voir que le département informatique s'occupe de la génération des clés et de les ajouter sur le serveur. Vous aurez donc besoin de vérifier comment ils gèrent cela avec le serveur.
+Une fois les clés générées, vous aurez besoin d'ajouter votre clé publique sur votre compte ssh du serveur. La procédure peut varier. Sur un système plus ou moins public, il se peut que vous deviez passer par un site Web qui ajoutera la clé sur votre compte ssh. Dans un contexte professionnel, le département informatique peut peut-être s'occuper de la génération des clés et de leur ajout sur le serveur. Vous aurez donc besoin de vérifier comment ils gèrent cela avec le serveur.
-Si vous avez accès au serveur (i.e. vous êtes administrateur de ce serveur), il existe un fichier nommé $HOME/.ssh/authorized_keys contenant les clés publiques de tous les utilisateurs, une à chaque ligne (et les lignes sont longues, évidemment). Étant donné que vous n'avez pas encore envoyé votre clé sur le serveur, cette connexion à celui-ci nécessitera d'être authentifié par l'utilisation d'un mot de passe, mais une fois que vous l'aurez ajoutée, il n'y en aura plus besoin. Copiez simplement le fichier contenant votre clé publique, puis rentrez le nom du fichier dans authorized_keys avec cat pour l'ajouter. Si vous êtes administrateur de ce serveur et avez les droits nécessaires pour effectuer ces opérations, assurez-vous d'avoir correctement défini les permissions de façon à ce que personne ne puisse lire le fichier s'il rentre dans le serveur. L'idée est de sécuriser le serveur, après tout.
+Si vous avez accès au serveur (i.e. vous êtes administrateur de ce serveur), il existe un fichier nommé $HOME/.ssh/authorized_keys contenant les clés publiques de tous les utilisateurs, une à chaque ligne (et les lignes sont longues, évidemment). Étant donné que vous n'avez pas encore envoyé votre clé sur le serveur, cette connexion-ci nécessitera d'être authentifié par l'utilisation d'un mot de passe, mais une fois que vous l'aurez ajoutée, il n'y en aura plus besoin. Copiez simplement le fichier contenant votre clé publique, puis rentrez le nom du fichier dans authorized_keys avec cat pour l'ajouter. Si vous êtes administrateur de ce serveur et avez les droits nécessaires pour effectuer ces opérations, assurez-vous d'avoir correctement défini les permissions de façon à ce que personne d'autre ne puisse lire le fichier s'il rentre dans le serveur. L'idée est de sécuriser le serveur, après tout.
 ====== 4 ======
@@ Ligne 57: / Ligne 60: @@
 **In any Unix-like system, the program ssh-agent should be installed. Many display managers will have hooks into the ssh-agent, and will find your key (xdm and kdm are two such) if it is in the default location. You will know this if, when you boot up, you get a pop-up window asking you for your passphrase. Ubuntu is a little different, so you can read the Ubuntu man page for this here. For windows users, the PuTTY ssh agent is called Pageant. If you place a shortcut to it in the startup folder, it will run automatically every time you boot Windows.**
-AGENTS
+Agents
-En pratique, vous aurez besoin de rentrer votre phrase secrète à chaque nouvelle session ssh. Même s'il est possible de créer une clé publique sans phrase secrète, c'est une très mauvaise idée de ne pas le faire. Et choisir une phrase secrète courte et mémorisable est presque aussi mal. La phrase secrète nécessite d'être longue pour être utile. Je vous recommande tout d'abord de stocker celle-ci dans un gestionnaire de mots de passe, comme KeePassX (voir le tutoriel sur les mots de passe, l'entropie et le bonnes pratique pour choisir son mot de passe pour plus d'informations à ce sujet). Mais si vous ouvrez beaucoup de sessions ssh par jour, cela va finir par vous lasser. Heureusement il existe une solution sécurisée appelée agent SSH. Un agent SSH est un programme conservé dans la mémoire qui retient votre clé privée décryptée. Chaque fois que vous allez sur un site utilisant SSH, ce programme génère un message à partir de cette clé que le serveur décrypte en utilisant votre clé publique (qu'il possède). Quand vous éteignez votre ordinateur à la fin de la journée, votre clé est supprimée de la mémoire, et vous aurez à rentrer une nouvelle fois votre phrase secrète le lendemain quand vous redémarrerez. En revanche cela comporte quelques désavantages évidents au niveau sécurité. Si vous ne verrouillez pas votre ordinateur à chaque fois que vous vous en éloignez, votre clé privée peut être récupérée par n'importe qui.
+En pratique, vous aurez besoin de rentrer votre phrase secrète à chaque nouvelle session ssh. Même s'il est possible de créer une clé publique sans phrase secrète, c'est une très mauvaise idée de le faire. Et choisir une phrase secrète courte et facile à retenir est presque aussi mal. La phrase secrète nécessite d'être longue pour être utile. Je vous recommande tout d'abord de stocker celle-ci dans un gestionnaire de mots de passe, comme KeePassX (voir le tutoriel sur les mots de passe, l'entropie et les bonnes pratiques pour choisir son mot de passe, pour plus d'informations à ce sujet). Mais si vous ouvrez beaucoup de sessions ssh par jour, cela va finir par vous lasser. Heureusement il existe une solution relativement sûre appelée agent SSH. Un agent SSH est un programme conservé dans la mémoire qui retient votre clé privée décryptée. Chaque fois que vous allez sur un site utilisant SSH, ce programme génère un message à partir de cette clé que le serveur décrypte en utilisant votre clé publique (qu'il possède). Quand vous éteignez votre ordinateur à la fin de la journée, votre clé est supprimée de la mémoire, et vous aurez à rentrer une nouvelle fois votre phrase secrète le lendemain quand vous redémarrerez. En revanche cela comporte quelques désavantages évidents au niveau sécurité. Si vous ne verrouillez pas votre ordinateur à chaque fois que vous vous en éloignez, votre clé privée peut être récupérée par n'importe qui.
-Dans un système basé sur Unix, le programme ssh-agent devrait être installé par défaut. Beaucoup de gestionnaires de fenêtres se relient à ssh-agent et reconnaîtront votre clé (xdm et gdm par exemple) si elle se trouve dans l'emplacement par défaut. Vous saurez cela si une fenêtre apparaît au démarrage vous demandant votre phrase secrète. Ubuntu est un peu différent, vous pouvez donc lire la page concernée dans le man page d'Ubuntu. Pour les utilisateurs de Windows, l'agent ssh de PuTTY s'appelle Pageant. Si vous placez un raccourci vers celui-ci dans un dossier de démarrage, il sera automatiquement lancé à chaque démarrage de Windows.
+Dans tout système basé sur Unix, le programme ssh-agent devrait être installé par défaut. Beaucoup de gestionnaires de fenêtres se relient à ssh-agent et reconnaîtront votre clé (xdm et gdm par exemple) si elle se trouve dans l'emplacement par défaut. Vous saurez cela si une fenêtre apparaît au démarrage vous demandant votre phrase secrète. Ubuntu est un peu différent, vous pouvez donc lire la page concernée dans le man-page d'Ubuntu. Pour les utilisateurs de Windows, l'agent ssh de PuTTY s'appelle Pageant. Si vous placez un raccourci vers celui-ci dans le dossier de démarrage, il sera automatiquement lancé à chaque démarrage de Windows.
 ====== 5 ======
@@ Ligne 68: / Ligne 71: @@
 **There are some things to keep in mind here. First, just as with your PGP key for e-mail, which we discussed previously, if you lose your key you are in trouble. Backing up is important. If you don’t back up your keys, you may find one day that you no longer have access to those remote systems. You might be able to get new access by deleting the old keys and getting new ones added, but if you log into a lot of sites that will be a royal pain. Also, what happens if a computer that has your keys on it is decommissioned, sold, or compromised in some way? How secure is your access now? One recommendation is that you don’t use the same keys on different machines to help guard against this. It might seem like additional work to create key pairs on each machine separately, but if the point is security it just might be a good idea.**
-DERNIER AVERTISSEMENT
+Dernier avertissement
-Il y a certains points à garder en mémoire. Tout d'abord, vous serez bien embêté si vous perdez votre clé, ceci est également valable avec votre clé PGP pour vos e-mails dont nous avons parlé précédemment. Faire des sauvegardes est important. Si vous ne sauvegardez pas vos clés, vous pourriez vous retrouver un jour à ne plus avoir accès à vos systèmes distants. Vous pourriez peut-être créer un nouvel accès en supprimant les anciennes clés et en refaire de nouvelles, mais si vous vous connectez à beaucoup de sites, cela sera long et fastidieux. Aussi, que se passera-t-il si l'ordinateur contenant vos clés est démantelé, vendu, ou hors d'usage ? Comment continuer à sécuriser votre accès ? Une solution serait de ne pas utiliser les mêmes clés sur différentes machines pour éviter cela. Cela peut vous sembler fastidieux de créer des paires de clés sur chaque machine séparément, mais si le but est de sécuriser l'ensemble, cela pourrait être une bonne idée.
+Il y a certains points à garder en mémoire. Tout d'abord, tout comme avec votre clé PGP pour vos e-mails dont nous avons parlé précédemment, vous serez bien embêté si vous perdez votre clé. La sauvegarde des clés est capitale. Si vous ne sauvegardez pas vos clés, vous pourriez vous retrouver un jour à ne plus avoir accès à vos systèmes distants. Vous pourriez peut-être créer un nouvel accès en supprimant les anciennes clés et en en faisant de nouvelles, mais si vous vous connectez à beaucoup de sites, cela sera long et fastidieux. Aussi, que se passera-t-il si l'ordinateur contenant vos clés est démantelé, vendu, ou corrompu d'une façon ou d'une autre ? Jusqu'à quel point votre accès est-il sécurisé maintenant ? Une solution serait de ne pas utiliser les mêmes clés sur différentes machines pour augmenter votre protection. Créer des paires de clés sur chaque machine séparément peut vous sembler fastidieux, mais, si le but est de sécuriser l'ensemble, cela pourrait être une bonne idée.