Le « shell sécurisé » SSH est un protocole réseau pour établir une connexion sécurisée entre les hôtes, typiquement sur le port 22 (qui est mieux d'être changé). Les clients SSH et les serveurs SSH sont disponibles pour la plupart des systèmes d'exploitation. À l'intérieur de SSH, presque tout autre protocole réseau peut fonctionner, ce qui signifie que vous pouvez travailler à distance sur un autre ordinateur, transmettre un flux audio ou vidéo via un canal chiffré, etc. De plus, via un proxy SOCKS sur un hôte distant vous pouvez vous connecter à d'autres hôtes au nom de cet hôte distant.

L'authentification se fait par mot de passe, mais les développeurs et les administrateurs système utilisent traditionnellement des clés SSH. Le problème est que la clé secrète peut être volée. L'ajout d'une phrase de passe protège théoriquement contre le vol de la clé secrète, mais en pratique, lors de la transmission et du mise en cache des clés, elles peuvent tout de même être utilisées sans confirmation. L'authentification à deux facteurs résout ce problème.

Comment mettre en œuvre l'authentification à deux facteurs

Les développeurs de l'entreprise Honeycomb ont récemment publié un guide détaillé, expliquant comment mettre en place l'infrastructure correspondante sur le client et le serveur.

Le guide suppose que vous avez un hôte de base, accessible sur Internet (bastion). Vous souhaitez vous connecter à cet hôte depuis des ordinateurs portables ou des ordinateurs via Internet et accéder à tous les autres dispositifs qui se trouvent derrière lui. La 2FA garantit qu'un attaquant ne pourra pas faire de même, même s'il accède à votre ordinateur portable, par exemple, en installant un logiciel malveillant.

La première option — OTP

L'OTP – mots de passe numériques à usage unique, qui dans ce cas seront utilisés pour l'authentification SSH avec la clé. Les développeurs notent que ce n'est pas une option idéale, car un attaquant peut lever un faux bastion, intercepter votre OTP et l'utiliser. Mais c'est mieux que rien.

Dans ce cas, côté serveur, les lignes suivantes sont écrites dans la configuration Chef :

• metadata.rb
• attributes/default.rb (depuis attributes.rb)
• files/sshd
• recipes/default.rb (copie de recipe.rb)
• templates/default/users.oath.erb

Du côté client, toute application OTP est installée : Google Authenticator, Authy, Duo, Lastpass, et vous installez brew install oath-toolkit ou apt install oathtool openssl, puis une chaîne aléatoire base16 (clé) est générée. Elle est convertie au format Base32, utilisé par les applications d'authentification mobile, et importée directement dans l'application.

Au final, vous pouvez vous connecter au bastion et constater qu'il demande désormais non seulement une phrase de passe, mais aussi un code OTP pour l'authentification :

➜ ssh -A bastion
Entrez la phrase de passe pour la clé '[snip]' : 
Mot de passe à usage unique (OATH) pour '[user]' : 
Bienvenue sur Ubuntu 18.04.1 LTS...

La deuxième option est l'authentification matérielle.

Dans ce cas, l'utilisateur n'est pas tenu de saisir le code OTP à chaque fois, car le second facteur devient un dispositif matériel ou la biométrie.

La configuration ici est un peu plus complexe avec Chef, et la configuration des clients dépend du système d'exploitation. Cependant, après avoir effectué toutes les étapes, les clients sur MacOS peuvent confirmer l'authentification en SSH par phrase de passe et en posant leur doigt sur le capteur (deuxième facteur).

Les utilisateurs iOS et Android confirment leur connexion en appuyant sur un bouton sur leur smartphone.C'est une technologie spéciale de Krypt.co, qui est même plus sécurisée que l'OTP.

Sur Linux/ChromeOS, il existe une option de travail avec des jetons USB YubiKey. Bien sûr, un attaquant peut volé votre jeton, mais il ne connaît toujours pas la phrase de passe.

Source : habr.com