Est-il vraiment sûr de se connecter à un serveur par SSH depuis les hôtels lors d'un voyage?

Est-il vraiment sûr de se connecter à un serveur en utilisant SSH depuis les hôtels pendant un voyage?

Serveur :
- CentOS 7
- Autorisation uniquement par clé RSA - L'authentification par mot de passe est refusée
- Port non standard

Station de travail :
- Ubuntu 14
- mot de passe utilisateur
- mot de passe pour utiliser la clé RSA (méthode standard)

Ce sera peut-être une bonne idée de conserver la moitié de la clé RSA privée sur une clé USB et d'ajouter automatiquement (par script) cette moitié à ~ / .ssh / private_key avant de vous connecter?

Internet se fera soit par WIFI dans les hôtels, soit par câble dans un appartement loué.

UPD
Désolé d'être flou au début. Je veux dire ici la sécurité sous deux aspects:

Sécurité de la connexion SSH uniquement via un réseau non fiable.
Sécurité d'un ordinateur avec la clé nécessaire à la connexion SSH - en cas de vol, comment protéger le serveur ...

security physical-security

— Sergey Serov
source

Quelle demi-clé RSA? La partie publique de la clé d'hôte ssh? La moitié de la partie privée de votre clé ssh d'utilisateur?

— andol

la moitié de ma clé RSA privée bien sûr :) et automatiquement par script pour ajouter cette moitié à ~ / .ssh / private_key avant de me connecter au serveur.

— Sergey Serov

Vous êtes déjà plus sécurisé que la plupart des gens car vous utilisez Linux. Puisque vous utilisez des versions récentes, vous devriez avoir de nouvelles versions d'OpenSSH qui prennent en charge un cryptage plus puissant. Après avoir suivi tecmint.com/5-best-practices-to-secure-and-protect-ssh-server, vous pouvez jouer en vous limitant à une cryptographie plus puissante telle que stribika.github.io/2015/01/04/secure-secure- shell.html

— poussins

@chicks "plus sûr que la plupart des gens parce que vous utilisez Linux" est une chose idiote à dire. SSH est SSH, qu'il s'exécute sur Linux, Unix (le Mac) ou Windows. Et nous pourrions signaler de nombreuses failles de sécurité extrêmement graves dans Linux dans l'histoire récente (Heartbleed, n'importe qui?). Je veux juste dire, laissons les guerres de flammes stupides de l'OS sur la touche où elles appartiennent, car cela distrait des questions et des problèmes réels. Merci! ;-)

— Craig

@chicks Je suppose que c'est ce que j'essayais de transmettre. Beaucoup de problèmes de sécurité dans tous les systèmes d'exploitation, et Microsoft a fait d' énormes progrès depuis le lancement de leur initiative «informatique digne de confiance *» il y a plusieurs années. respectueusement). ;-)

— Craig

Réponses:

Donc, concernant l'établissement d'une connexion ssh sur une connexion explicitement non approuvée.

En supposant que vous avez déjà une entrée ~ / .ssh / known_hosts d'une connexion précédente, oui, vous devriez pouvoir vous connecter sans vous soucier de ce que le réseau est sûr ou non. Il en va de même si vous avez d'autres moyens de vérifier la clé d'hôte ssh.

Si vous ne vous êtes jamais connecté au serveur auparavant, ni si vous n'avez aucun autre moyen de vérifier la clé d'hôte ssh, alors vous voudrez peut-être être plus prudent concernant le réseau que vous utilisez pour vous connecter.

— andol
source

Merci!! Donc, il est sécurisé de se connecter au serveur par SSH même via n'importe quel wi-fi public?

— Sergey Serov

En fait, cette réponse s'applique à toute situation dans laquelle vous souhaitez effectuer une connexion ssh à un serveur distant et où aucune partie du chemin n'est sous votre contrôle total (donc pratiquement rien à part ssh-ing vers un hôte local fraîchement installé ou via un câble de liaison croisée) )

— Hagen von Eitzen

Il convient de noter que si le client ne connaît pas la clé d'hôte, une attaque MITM complète sera possible si l'authentification par mot de passe est utilisée. Mais si l'authentification par clé est utilisée, l'attaquant ne pourra que se faire passer pour le serveur. L'attaquant ne pourra pas également s'authentifier auprès du vrai serveur. Il est difficile pour un attaquant de fournir une usurpation d'identité convaincante du serveur dans ce cas, vous pouvez donc être en mesure de remarquer que quelque chose ne va pas avant qu'il ne soit trop tard. En bref: l'authentification par clé publique est beaucoup plus sûre que l'authentification par mot de passe .

— kasperd

@kasperd: Eh bien, si le transfert de l'agent a activé le transfert d'agent, même l'authentification par clé publique peut fournir une expérience MITM complète. Mais oui, l'authentification par clé publique est définitivement préférable aux mots de passe normaux, quel que soit le jour.

— andol

@kasperd: Eh bien, je peux facilement imaginer que quelqu'un découvre simplement le transfert d'agent, mais ne le comprend pas complètement, en mettant quelque chose comme "Host * \ n \ tForwardAgent yes" dans leur ~ / .ssh / config. Les gens font toutes sortes de choses folles :-)

— andol

Dans la deuxième partie de votre question, vous semblez inquiet du vol de votre ordinateur portable et, avec lui, de vos clés privées pour votre connexion SSH sans mot de passe à vos serveurs.

Veuillez noter que cela peut être facilement résolu (le problème des clés privées) en stockant les clés privées "chiffrées" avec une "phrase secrète": elles peuvent être chiffrées initialement, tout en générant avec l' utilitaire ssh-keygen , en fournissant une phrase secrète à la fin de le processus de génération ou, si vous les avez déjà non encrypté, en utilisant l' utilitaire ssh-keygen avec -poption. Une fois la clé cryptée, à chaque connexion, vous êtes invité à saisir la phrase secrète associée et ... si elle est correcte, tout se déroulera normalement.

De plus, si vous ne voulez pas entrer la phrase secrète à chaque lancement du client ssh, vous pouvez utiliser l' agent ssh : il peut garder une trace, en mémoire, des clés privées non chiffrées. Vous pouvez simplement exécuter ssh-add pointant vers le fichier contenant la clé cryptée et, après avoir demandé la phrase secrète, la clé est ajoutée à l'ensemble géré par ssh-agent. Ensuite, chaque fois que le client SSH requiert une clé protégée par une phrase secrète, l'agent ssh fournit de manière transparente la clé privée non chiffrée associée au client ssh. Donc, pour vous, il n'est pas nécessaire de le saisir de manière interactive.

Veuillez noter que ssh-agent peut gérer de nombreuses clés, et vous pouvez évidemment "régler" votre ordinateur portable / bureau pour lancer l' ssh-addutilitaire (pour remplir le jeu de clés ssh-agent) au moment de la connexion / démarrage.

De plus, si quelqu'un vole votre ordinateur portable, vos clés privées ne sont probablement pas le seul contenu "sensible" que vous allez donner: veuillez noter qu'avec les distributions de bureau Linux d'aujourd'hui, il est TRÈS facile de configurer un ordinateur portable en s'appuyant sur "crypté" "système de fichiers ( /homecomme entrée, mais le tout /si nécessaire). Alors, s'il vous plaît, considérez cela aussi.

Tout ce qui précède, évidemment, ne s'applique PAS si vous ne comptez PAS sur VOTRE PROPRE bloc-notes.

PS: quant à votre possibilité de stocker les deux moitiés de la clé privée non cryptée sur différents supports: je vous conseille fortement de ne pas le faire, car maintenir les deux morceaux de contenu sensible sous une forme non cryptée est beaucoup, bien pire, que de garder deux des copies complètes de tout le contenu, cryptées!

— Damiano Verzulli
source

La première partie de votre question est déjà répondue par la réponse précédente. Selon votre deuxième partie, je recommanderais d'ajouter un deuxième facteur à votre connexion ssh à l'aide de pam_google_authenticator. Il est assez facile à installer et à configurer sur n'importe quelle distribution. Dans le cas où la clé privée que vous transportez est volée, ils ne peuvent pas se connecter à votre serveur sans le mot de passe unique TOTP de Google-Authenticator.

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

— Arul Selvan
source