banner-bad-warning

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

Bien que nous ayons écrit ce guide en pensant à 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 que SSH est un excellent moyen de connecter et de tunneler des données en toute sécurité d’un point à un autre. Voyons brièvement comment les choses fonctionnent afin de mieux comprendre pourquoi les choses peuvent parfois devenir bizarres.

 sshot-2

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 obtenons une confirmation de notre connexion. Afin d’établir un certain 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 du courrier, alors utiliser FTP et Telnet et autres n’est pas comme utiliser des enveloppes postales standard. C’est plus comme utiliser des cartes postales. Si quelqu’un arrive au milieu, il peut voir toutes les informations, y compris les adresses des deux correspondants et le nom d’utilisateur et le mot de passe envoyés. Ils peuvent ensuite modifier le message, conserver les mêmes informations et usurper l’identité d’un correspondant ou de l’autre. C’est ce que l’on appelle une attaque de type «homme du milieu», et non seulement elle compromet votre compte, mais elle remet en question chaque message envoyé et fichier reçu. Vous ne pouvez pas être sûr si vous parlez à l’expéditeur ou non, et même si vous l’êtes, vous ne pouvez pas être sûr que personne ne regarde tout entre les deux.

Voyons maintenant le cryptage SSL, le type qui rend HTTP plus sûr. Ici, nous avons un bureau de poste qui gère la correspondance, qui vérifie si votre destinataire est bien celui qu’il prétend être et a des lois qui protègent votre courrier contre toute consultation. Il est globalement plus sécurisé et l’autorité centrale – Verisign en est un, pour notre exemple HTTPS – s’assure que la personne à qui vous envoyez du courrier vérifie. Ils le font en n’autorisant pas les cartes postales (informations d’identification non chiffrées); ils imposent plutôt de véritables enveloppes.

 sshot-1

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

Avec l’explication tant qu’elle est, nous pensons que nous allons la couper là. Si vous avez plus d’informations, n’hésitez pas à discuter dans les commentaires, bien sûr. Pour l’instant, examinons la fonctionnalité la plus pertinente de SSH, l’authentification de l’hôte.

Clés d’hôte

L’authentification de l’hôte est essentiellement la partie où une personne de confiance prend l’enveloppe (scellée avec des calculs 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 deux choses importantes à retenir:

  1. Puisqu’il n’y a pas d’autorité centrale, la véritable sécurité réside dans la clé d’hôte, les clés publiques et les clés privées. (Ces deux dernières clés sont configurées lorsque vous avez accès au système.)
  2. 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).
  3. Si la clé d’hôte change, vous serez probablement alerté et vous devriez vous méfier!

Étant donné que la clé d’hôte est utilisée avant l’authentification pour établir l’identité du serveur SSH, vous devez vous assurer de vérifier la clé avant de vous connecter. Vous verrez une boîte de dialogue de confirmation comme ci-dessous.

Mais ne vous inquiétez pas! Souvent, lorsque la sécurité est un problème, il y aura un endroit spécial où la clé d’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 de!) 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 professionnel 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 par 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-ci 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 renvoyer 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 est la longueur en bits de la clé, puis la clé elle-même, et enfin vous avez le fichier dans lequel elle est stockée. Comparez cette partie centrale à ce que vous voyez lorsque vous êtes invité à vous connecter à distance. Cela devrait correspondre, et vous êtes prêt. Si ce n’est pas le cas, alors 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 (ou l’adresse Web) de l’ordinateur hôte et son adresse IP.

Modification des clés d’hôte et des problèmes

Il y a 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 d’hôte ont été modifiées manuellement en raison de protocoles de sécurité.
  • Le serveur OpenSSH a été mis à jour et utilise des normes différentes 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é d’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 dirigé vers une autre machine. Si vous n’êtes pas sûr de la raison du changement, vous devez probablement supposer que c’est le dernier de la liste.

Comment OpenSSH gère les hôtes inconnus

 confirm

OpenSSH a un paramètre pour la façon dont il gère les 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 sont pas déjà dans votre fichier known_hosts) peuvent se faire de trois manières.

  • StrictHostKeyChecking est défini sur no; OpenSSH se connectera automatiquement à n’importe quel serveur SSH quel que soit l’état de la clé d’hôte. Ceci n’est pas sécurisé 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 le modifierez à nouveau.
  • StrictHostKeyChecking est configuré pour demander; OpenSSH vous montrera de nouvelles clés d’hôte et demandera une confirmation avant de les ajouter. Cela empêchera les connexions d’accéder aux clés d’hôte modifiées. C’est la valeur par défaut.
  • StrictHostKeyChecking est défini sur yes; Le contraire de «non», cela vous empêchera de vous connecter à tout hôte qui n’est pas déjà présent dans votre fichier known_hosts.

Vous pouvez modifier cette variable facilement sur la ligne de commande en utilisant le paradigme suivant:

ssh -o 'StrictHostKeyChecking [option]' [email protected]

Remplacer [option] avec «non», «demander» ou «oui». N’oubliez pas qu’il existe des guillemets simples entourant cette variable et son paramètre. Remplacez également user @ host 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 en raison de clés modifiées

Si vous avez accès à 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ïaque sécurisé, n’est-ce pas? Au lieu de cela, nous pouvons simplement supprimer la valeur incriminée de notre fichier known_hosts.

mauvais avertissement

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.

Et voilà. Voyez comment il cite le fichier que nous devons modifier? Cela nous donne même le numéro de ligne! Alors, ouvrons ce fichier dans Nano:

 command

1ère ligne

Voici notre clé incriminée, à la ligne 1. Tout ce que nous devons faire est d’appuyer sur Ctrl + K pour couper toute la ligne.

après la 1ère ligne

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

Maintenant, nous obtenons à la place une belle invite, à laquelle nous pouvons simplement répondre par «oui».

terminé

Création de nouvelles clés d’hôte

Pour mémoire, il n’y a vraiment pas trop de raison pour que vous changiez votre clé d’hôte, mais si jamais vous en avez 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, consultez votre documentation!

Ensuite, nous supprimerons toutes les anciennes clés.

sudo rm / etc / ssh / ssh_host_ *

Vous pouvez également les déplacer vers un répertoire de sauvegarde sûr. 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!

création de clés


Maintenant que vous savez comment SSH fonctionne un peu mieux, vous devriez pouvoir vous sortir des endroits difficiles. L’avertissement / erreur «L’identification de l’hôte distant a changé» est quelque chose qui décourage beaucoup d’utilisateurs, même ceux qui connaissent la ligne de commande.

Pour les points bonus, vous pouvez consulter Comment copier des fichiers à distance via SSH sans entrer votre mot de passe. Là, vous en apprendrez un peu plus sur les autres types d’algorithmes de chiffrement et comment utiliser les fichiers de clés pour plus de sécurité.

Laisser un commentaire