Bien que ce guide ait été conçu pour Linux, cela peut également s'appliquer à OpenSSH sous Mac OS X et Windows 7 via Cygwin.
Pourquoi c'est sécurisé
Nous avons mentionné à maintes reprises que SSH est un excellent moyen de se connecter en toute sécurité et de canaliser les données d’un point à un autre. Examinons brièvement le fonctionnement des choses afin d’avoir une meilleure idée de la raison pour laquelle les choses peuvent parfois devenir bizarres.
Si nous considérons notre processus de connexion comme un courrier, utiliser FTP, Telnet, etc. n’est pas comme utiliser des enveloppes de publipostage standard. C’est plus comme utiliser des cartes postales. Si quelqu'un se trouve au milieu, il peut voir toutes les informations, y compris les adresses des deux correspondants, ainsi que le nom d'utilisateur et le mot de passe envoyés. Ils peuvent ensuite modifier le message en conservant les mêmes informations et emprunter l'identité d'un correspondant ou de l'autre. Cette attaque est connue sous le nom d’attaque «interférant», et non seulement elle compromet votre compte, mais elle remet en question chaque message envoyé et chaque fichier reçu. Vous ne pouvez pas savoir avec certitude si vous parlez à l'expéditeur, et même si vous le faites, vous ne pouvez pas être sûr que personne ne regarde tout entre les deux.
Voyons maintenant le cryptage SSL, le type qui rend le protocole HTTP plus sécurisé. Ici, nous avons un bureau de poste qui traite la correspondance, qui vérifie si votre destinataire est bien celui qu'il prétend être et dispose de lois empêchant que votre courrier ne soit examiné. C’est plus sûr dans l’ensemble, et l’autorité centrale - Verisign en est un, pour notre exemple HTTPS - s’assure que la personne à qui vous envoyez le courrier effectue le chèque. Ils le font en n'autorisant pas les cartes postales (informations d'identification non chiffrées); au lieu de cela, ils prescrivent de véritables enveloppes.
Avec l'explication aussi longtemps qu'elle est, nous pensons la couper là-bas. Si vous avez plus de perspicacité, n'hésitez pas à discuter dans les commentaires, bien sûr. Pour l’instant, cependant, examinons la fonctionnalité la plus pertinente de l’authentification SSH, l’authentification.
Clés de l'hôte
L'authentification de l'hôte est essentiellement la partie où une personne de confiance prend l'enveloppe (scellée avec des maths magiques) et confirme l'adresse de votre destinataire. Il s’agit d’une description assez détaillée de l’adresse, basée sur des calculs compliqués que nous allons simplement ignorer. Il y a cependant quelques points importants à retenir de ceci:
- En l'absence d'autorité centrale, la sécurité réelle réside dans la clé de l'hôte, les clés publiques et les clés privées. (Ces deux dernières touches sont configurées lorsque vous avez accès au système.)
- Habituellement, lorsque vous vous connectez à un autre ordinateur via SSH, la clé d’hôte est stockée. Cela rend les actions futures plus rapides (ou moins verbeuses).
- Si la clé de l'hôte change, vous serez probablement alerté et vous devrez vous méfier!
Étant donné que la clé de l'hôte est utilisée avant l'authentification pour établir l'identité du serveur SSH, vous devez vérifier la clé avant de vous connecter. Vous verrez une boîte de dialogue de confirmation comme ci-dessous.
Vérification de la clé d’hôte de votre système
Il existe 4 types d'algorithmes de chiffrement utilisés pour créer les clés, mais la valeur par défaut d'OpenSSH à compter de cette année est ECDSA (avec quelques bonnes raisons). Nous allons nous concentrer sur celui-là aujourd'hui.Voici la commande que vous pouvez exécuter sur le serveur SSH auquel vous avez accès:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Votre sortie devrait retourner quelque chose comme ceci:
256 ca:62:ea:7c:e4:9e:2e:a6:94:20:11:db:9c:78:c3:4c /etc/ssh/ssh_host_ecdsa_key.pub
Le premier nombre correspond à la longueur en bits de la clé, à la clé elle-même et enfin au fichier dans lequel elle est stockée. Comparez cette partie centrale à ce que vous voyez lorsque vous êtes invité à vous connecter à distance. Il devrait correspondre, et vous êtes tous ensemble. Si ce n’est pas le cas, quelque chose d’autre pourrait se produire.
Vous pouvez afficher tous les hôtes auxquels vous vous êtes connecté via SSH en consultant votre fichier known_hosts. Il est généralement situé à:
~/.ssh/known_hosts
Vous pouvez l'ouvrir dans n'importe quel éditeur de texte. Si vous regardez, essayez de faire attention à la façon dont les clés sont stockées. Ils sont stockés avec le nom de l’ordinateur hôte (ou adresse Web) et son adresse IP.
Changer les clés et les problèmes de l'hôte
Il existe plusieurs raisons pour lesquelles les clés d’hôte changent ou ne correspondent pas à ce qui est enregistré dans votre fichier known_hosts.
- Le système a été réinstallé / reconfiguré.
- Les clés de l'hôte ont été modifiées manuellement en raison de protocoles de sécurité.
- Le serveur OpenSSH mis à jour et utilise différentes normes en raison de problèmes de sécurité.
- Le bail IP ou DNS a changé. Cela signifie souvent que vous essayez d'accéder à un autre ordinateur.
- Le système a été compromis d'une manière telle que la clé de l'hôte a été modifiée.
Le problème est très probablement l'un des trois premiers et vous pouvez ignorer le changement. Si le bail IP / DNS a changé, il peut y avoir un problème avec le serveur et vous pouvez être routé vers une autre machine. Si vous n’êtes pas sûr de la raison du changement, vous devrez probablement supposer que c’est le dernier sur la liste.
Comment OpenSSH gère les hôtes inconnus
En fonction de votre configuration, les connexions SSH avec des hôtes inconnus (dont les clés ne figurent pas déjà dans votre fichier known_hosts) peuvent aller de trois manières.
- StrictHostKeyChecking est défini sur no; OpenSSH se connectera automatiquement à n’importe quel serveur SSH, quel que soit le statut de la clé de l’hôte. Ceci est peu sûr et déconseillé, sauf si vous ajoutez un groupe d’hôtes après une réinstallation de votre système d’exploitation, après quoi vous pourrez le restaurer.
- StrictHostKeyChecking est configuré pour demander; OpenSSH vous montrera les nouvelles clés d’hôte et vous demandera une confirmation avant de les ajouter. Cela empêchera les connexions d’aller aux clés d’hôte modifiées. C'est la valeur par défaut.
- StrictHostKeyChecking est défini sur yes; L'opposé de "non", cela vous empêchera de vous connecter à un hôte qui n'est pas déjà présent dans votre fichier known_hosts.
Vous pouvez facilement modifier cette variable sur la ligne de commande en utilisant le paradigme suivant:
ssh -o 'StrictHostKeyChecking [option]' user@host
Remplacez [option] par «non», «demander» ou «oui». Sachez qu'il existe des guillemets simples entourant cette variable et son paramètre. Remplacez également utilisateur @ hôte par le nom d'utilisateur et le nom d'hôte du serveur auquel vous vous connectez. Par exemple:
ssh -o 'StrictHostKeyChecking ask' [email protected]
Hôtes bloqués à cause de clés modifiées
Si vous tentez d'accéder à un serveur dont la clé a déjà été modifiée, la configuration OpenSSH par défaut vous empêchera d'y accéder. Vous pouvez modifier la valeur StrictHostKeyChecking pour cet hôte, mais cela ne serait pas entièrement, complètement, paranoïde sécurisé, n'est-ce pas? Au lieu de cela, nous pouvons simplement supprimer la valeur incriminée de notre fichier known_hosts.
Maintenant, nous recevons un joli message à la place, auquel nous pouvons simplement répondre par «oui».
Création de nouvelles clés d'hôte
Pour mémoire, il n’ya vraiment aucune raison de changer de clé d’hôte, mais si vous en trouvez le besoin, vous pouvez le faire facilement.
Tout d'abord, accédez au répertoire système approprié:
cd /etc/ssh/
C’est généralement là que se trouvent les clés d’hôte globales, bien que certaines distributions les placent ailleurs. En cas de doute, vérifiez votre documentation!
Ensuite, nous allons supprimer toutes les anciennes clés.
sudo rm /etc/ssh/ssh_host_*
Vous pouvez également les déplacer dans un répertoire de sauvegarde sécurisé. Juste une pensée!
Ensuite, nous pouvons dire au serveur OpenSSH de se reconfigurer:
sudo dpkg-reconfigure openssh-server
Une invite s’affiche pendant que votre ordinateur crée ses nouvelles clés. Ta-da!
Maintenant que vous savez comment SSH fonctionne un peu mieux, vous devriez être capable de vous sortir de situations difficiles. L'avertissement / l'erreur «L'identification de l'hôte distant a changé» est une chose qui choque de nombreux utilisateurs, même ceux qui sont familiers avec la ligne de commande.
Pour obtenir des points bonus, vous pouvez consulter Comment copier à distance des fichiers sur SSH sans entrer votre mot de passe. Vous en apprendrez un peu plus sur les autres types d’algorithmes de chiffrement et sur l’utilisation des fichiers de clés pour une sécurité accrue.
