Apprenez ce que OpenSSH a à offrir sur votre PC Linux

Nous avons vanté les vertus de SSH à de nombreuses reprises, tant pour la sécurité que pour l’accès à distance. Jetons un coup d'œil au serveur lui-même, à quelques aspects importants de «maintenance» et à quelques bizarreries qui peuvent ajouter de la turbulence à une conduite par ailleurs fluide..

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é à plusieurs reprises à quel point SSH est un excellent moyen de connecter en toute sécurité et de canaliser les données d'un point à un autre. Examinons brièvement comment les choses fonctionnent pour vous donner une meilleure idée de la raison pour laquelle les choses peuvent parfois devenir bizarres..

Lorsque nous décidons d'établir une connexion avec un autre ordinateur, nous utilisons souvent des protocoles faciles à utiliser. Telnet et FTP me viennent à l’esprit. Nous envoyons des informations à un serveur distant, puis nous recevons une confirmation de notre connexion. Afin d'établir un type de sécurité, ces protocoles utilisent souvent des combinaisons de nom d'utilisateur et de mot de passe. Cela signifie qu'ils sont totalement sécurisés, non? Faux!

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 changer 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 «interposée», et non seulement elle compromet votre compte, mais elle remet en question chaque message envoyé et le fichier reçu. Vous ne pouvez pas savoir si vous parlez à l'expéditeur ou non, 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 des lois empêchant que votre courrier ne soit examiné. Dans l’ensemble, c’est plus sécurisé et l’autorité centrale - Verisign en est un, pour notre exemple HTTPS - s’assure que la personne à qui vous envoyez le courrier envoie un chèque. Ils le font en n'autorisant pas les cartes postales (informations d'identification non chiffrées); à la place, ils prescrivent de véritables enveloppes.

Enfin, regardons SSH. Ici, la configuration est un peu différente. Nous n'avons pas d'authentificateur central ici, mais la situation est toujours sécurisée. C’est parce que vous envoyez des lettres à une personne dont vous connaissez déjà l’adresse - par exemple, en discutant avec elle au téléphone - et que vous utilisez des calculs très sophistiqués pour signer votre enveloppe. Vous le remettez à votre frère, à votre petite amie, à votre père ou à votre fille pour que celui-ci l'emporte à l'adresse. Seulement si les correspondances mathématiques sont à la mode, acceptez-vous que l'adresse est celle qu'elle devrait être. Ensuite, vous recevez une lettre en retour, également protégée des regards indiscrets par ce calcul impressionnant. Enfin, vous envoyez vos informations d'identification dans une autre enveloppe secrète enchantée par un algorithme à la destination. Si les calculs ne concordent pas, nous pouvons supposer que le destinataire d'origine a déménagé et nous devons confirmer son adresse à nouveau..

Avec l'explication aussi longtemps qu'elle est, nous pensons que nous allons la réduire ici. Si vous avez plus de perspicacité, n'hésitez pas à discuter dans les commentaires, bien sûr. Pour l’instant, regardons la fonctionnalité la plus pertinente de SSH, l’authentification de l’hôte.

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. C'est une description assez détaillée de l'adresse, et elle est basée sur des calculs compliqués que nous allons simplement ignorer. Il y a cependant quelques points importants à retenir de ceci:

Comme il n'y a pas 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.)
Généralement, 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.

Vous ne devriez pas vous inquiéter, cependant! Souvent, lorsque la sécurité est une préoccupation, il y aura un endroit spécial où la clé de l'hôte (empreinte ECDSA ci-dessus) peut être confirmée. Dans les entreprises entièrement en ligne, ce sera souvent sur un site de connexion sécurisé uniquement. Vous devrez peut-être (ou choisir!) Appeler votre service informatique pour confirmer cette clé par téléphone. J'ai même entendu parler de certains endroits où la clé se trouve sur votre badge de travail ou sur la liste spéciale «Numéros d'urgence». Et, si vous avez un accès physique à la machine cible, vous pouvez également vérifier vous-même!

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 des clés, mais la valeur par défaut pour OpenSSH au début 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 chiffre 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 du milieu à 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 l'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 de l'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 changé.

Très probablement, le problème est 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 ne savez pas quelle est la raison de ce changement, vous devrez probablement supposer que c'est le dernier sur la liste..

Comment OpenSSH gère les hôtes inconnus

OpenSSH a un paramètre de traitement des hôtes inconnus, reflété dans la variable «StrictHostKeyChecking» (sans guillemets).

Selon 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 n'est pas sûr et n'est pas recommandé, 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]' utilisateur @ hôte

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 demander' [email protected]

Hôtes bloqués à cause de clés modifiées

Si vous essayez 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.

C'est vraiment une chose laide à avoir sur votre écran. Heureusement, notre raison en était un système d’exploitation réinstallé. Alors, zoomons sur la ligne dont nous avons besoin.

Nous y voilà. Vous voyez comment cite le fichier que nous devons éditer? Il nous donne même le numéro de ligne! Alors ouvrons ce fichier dans Nano:

Voici notre clé incriminée, dans la ligne 1. Il suffit d’appuyer sur Ctrl + K pour couper toute la ligne..

C'est beaucoup mieux! Donc, maintenant nous avons appuyé sur Ctrl + O pour écrire (enregistrer) le fichier, puis Ctrl + X pour quitter.

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

Vous verrez une invite 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 en mesure de vous sortir des situations difficiles. L’avertissement / erreur «L’identification de l’hôte distant a changé» est un élément qui déroute de nombreux utilisateurs, même ceux qui connaissent la ligne de commande..