web-dev-qa-db-fra.com

SSH à partir d'un ordinateur de travail partagé

La question principale: comment puis-je me connecter en toute sécurité à mon ordinateur personnel à la maison à partir d'un ordinateur professionnel?

Contexte: Je fais une grande partie de mon travail sur un ordinateur universitaire, mais l'ordinateur lui-même n'est pas fantastique, donc je SSH dans ma machine à la maison pour exécuter des calculs. Ce système fonctionne bien, mais je suis confronté à un dilemme sur la façon de sécuriser correctement mon ordinateur personnel. D'une part, je voudrais désactiver la connexion par mot de passe SSH et utiliser uniquement les clés SSH. Cependant, cela nécessiterait de générer une clé SSH sur mon ordinateur universitaire qui pourrait être facilement vue/copiée/utilisée par d'autres. Je ne veux pas non plus conserver mon nom d'utilisateur/adresse IP dans un fichier de configuration facilement consultable par les autres.

L'ordinateur universitaire que j'utilise est "le mien" en ce sens qu'il est à mon bureau, mais toute personne possédant un compte peut y accéder en SSH et a un accès en lecture à mon répertoire personnel où les clés SSH sont stockées et je n'ai pas les privilèges Sudo à protéger contre ça.

Que recommandez-vous pour pouvoir vous connecter en toute sécurité d'un ordinateur de travail à un serveur personnel?

34
user5728491

Étant donné que vous avez un ordinateur stable, j'irais de l'avant et utiliserais des clés ssh au lieu d'un mot de passe pour l'accès ssh (même si vous utilisiez un ordinateur de laboratoire différent à chaque fois, une clé ssh dans une clé USB portable serait probablement encore préférable) .

La clé ssh pourrait être volée, mais l'utilisation d'un mot de passe devrait fournir une sécurité similaire à un mot de passe ssh, sauf que vous avez également besoin du fichier de clé . Oui, le client ssh peut être compromis pour voler la phrase secrète de clé, mais la difficulté serait équivalente à celle de compromettre le client pour voler le mot de passe ssh. N'oubliez pas que vous pouvez charger des identités ssh dans un agent de telle manière qu'elles nécessitent une confirmation avant d'être utilisées (ainsi que décharger/ne pas utiliser du tout un agent ssh, bien que je le recommande).

Un jeton matériel (tel que recommandé par Luis) serait préférable pour protéger la clé ssh, mais il pourrait ne pas être une option.

Quant à ne pas afficher l'adresse IP à laquelle vous vous connectez, si vous utilisez le client openssh, vous voulez que le HashKnownHosts yes option ssh_config (pour certaines distributions c'est même la valeur par défaut). Cela ne vaut probablement pas vraiment la peine d'être caché, cependant, il ne devrait pas s'agir de "trucs secrets", et il peut être facilement extrait à froid des journaux du réseau.

Sur le serveur, pour protéger davantage la connexion contre les hôtes aléatoires non autorisés, vous pouvez:

  • Désactivez l'authentification par mot de passe (que vous vouliez faire)
  • Restreindre les utilisateurs qui peuvent se connecter (au seul autorisé)
  • Utiliser un port non standard
  • Restreignez l'adresse IP autorisée à se connecter. Étant une université, "votre" ordinateur aura une adresse IP sortante statique, probablement même une adresse IP publique rien que pour vous. Pire cas, restreindre à la gamme University.

Ce sont principalement des "mesures supplémentaires", car elles ne peuvent pas dissuader un attaquant déterminé qui a abusé de son pouvoir de superutilisateur sur votre ordinateur, ¹ mais je pense qu'il est bon de les répertorier au moins pour les futurs lecteurs.

Cependant, la solution importante à votre problème est vous ne donnez pas un accès général à votre ordinateur personnel. Puisque vous souhaitez vous connecter via ssh, je suppose que votre machine domestique sera une machine Linux/BSD/MacOS.

Vous disposerez probablement d'un compte utilisateur à partir duquel vous effectuez des tâches quotidiennes telles que la navigation sur Internet, la rédaction d'e-mails (personnels) ou la visualisation de vidéos YouTube. Cependant, vous n'avez pas besoin d'accéder à tout cela, car vous ne vous souciez que des calculs. Vous configurez donc un accès séparé et limité pour l'exécution des calculs. Vous pouvez vous connecter à une machine virtuelle ou à un conteneur, mais un seul compte distinct devrait répondre à vos besoins. Vous avez seulement besoin que le matériel soit rapide (euh), un compte avec un peu d'espace et les programmes nécessaires installés sur la machine feraient l'affaire. Quelques autorisations Unix de base qui ne permettaient pas aux autres utilisateurs d'accéder à vos "fichiers personnels" seraient suffisantes. ² Évidemment, gardez votre ordinateur personnel corrigé contre les exploits d'escalade locaux.

Un deuxième problème potentiel serait qu'un attaquant ayant accédé à ce compte à faible privilège compromettrait d'autres appareils de votre réseau local. En plus de sécuriser adéquatement les autres appareils, vous pouvez soit refuser tout accès réseau à cet utilisateur à faible privilège, soit le restreindre à des adresses externes uniquement.

¹ Par exemple. la clé ssh ne fonctionnerait pas à partir d'autres machines, mais elles pourraient passer par le vôtre pour accéder à

² Il existe toutes sortes de canaux secondaires de processeur mais la plupart du temps non pertinents, vous pouvez désactiver sshd lorsque vous y accédez localement, et ne devriez pas laisser les choses sensibles s'exécuter de toute façon (non, vous ne devriez pas laisser une autorité de certification y fonctionner ????).

45
Ángel

Si vous êtes autorisé à installer et exécuter votre propre logiciel sur cet ordinateur, il existe des solutions qui vous permettent d'utiliser l'authentification par clé avec une clé sur du matériel externe comme un smartphone ou un jeton de sécurité:

J'ai essayé l'ancien et je l'utilise souvent.

13
Luis Casillas

Si vous souhaitez être sécurisé à l'aide d'un ordinateur public, votre meilleur pari est d'utiliser l'authentification multifacteur; par exemple, une clé privée SSH de confiance (qui autorise uniquement l'accès aux serveurs avec une configuration d'authentification multifacteur) ainsi que l'utilisation de votre appareil mobile comme deuxième facteur (soit par approbation dans une application sur votre appareil ou en tapant un code d'accès) (par exemple, via authentificateur Google ).

N'oubliez pas que toute activité sur cet ordinateur public peut être dangereuse. Quelqu'un a peut-être installé des enregistreurs de frappe matériels/logiciels, un administrateur en tant que root peut regarder dans votre répertoire privé, etc. Si vous cryptez la clé SSH sur le disque, un administrateur peut vider la mémoire après l'avoir décryptée pour l'utiliser et reconstruire la version décryptée, etc.

9
dr jimbob

Tout d'abord, certaines choses devraient être corrigées ... sur un système * nix, même si /home/username dispose d'autorisations de lecture universelle (c'est-à-dire 755 ou un ls -ld ~/ ressemble à rwxr-xr-x) le ~/.ssh le répertoire et son contenu doivent être 600 (pour les fichiers) et 700 (pour les répertoires). En fait, ssh devrait refuser de se connecter si ces fichiers sont lisibles par un utilisateur autre que l'utilisateur propriétaire. Et si votre ~/ doit être lisible par tout le monde pour une raison quelconque (par exemple, pour qu'Apache puisse lire ~/public_html et le diffuser sur uni.edu/~username), vous pouvez toujours modifier les perms sur ~/.ssh - juste chmod 700 ~/.ssh et chmod 600 ~/.ssh/* corrigera cela.

En ce qui concerne la connexion sécurisée à votre machine domestique, vous pouvez générer une clé privée sur une autre machine de confiance (comme votre machine domestique), la copier sur une clé USB ou tout autre support portable approprié à l'aide d'un système de fichiers qui prend en charge les autorisations Linux (I ' d formatez-le simplement comme ext4 pour plus de simplicité) et mettre la clé là-dessus. Ensuite, lorsque vous êtes à l'université, vous pouvez insérer et monter la clé USB et faire un ssh -i /path/to/private/keyfile -p <port number> [email protected]

Si vous êtes paranoïaque à propos de quelqu'un qui copie la clé du ram sur votre machine, etc., alors vous ne devriez tout simplement pas vous connecter à un endroit non lié au travail.

1
ivanivan

En tant que réponse générique, vous ne pouvez pas. C'est vrai, que l'ordinateur de travail soit un PC Windows transmis par un ancien employé avec un compte d'utilisateur partagé et un logiciel malveillant connu que personne n'a réussi à supprimer, ou un ordinateur portable utilisé uniquement par vous avec une version bénie de l'Université. " sécurité renforcée "Solaris installé dessus, ou quoi que ce soit entre les deux. Quoi qu'il en soit, il pourrait y avoir un enregistreur de frappe bien caché ou des outils d'accès à distance.

Cependant, dans votre situation particulière (en particulier comme expliqué dans les commentaires), vous êtes probablement en sécurité en utilisant l'authentification par clé privée, avec des autorisations de système de fichiers pour protéger la clé privée contre les collègues en général. Pour vous protéger contre les administrateurs, vous devez vous fier à la politique de l'université et à son respect; contre le vol physique du système, la sécurité physique de votre laboratoire ou bureau.

Je ferai écho à la recommandation d'Ángel de créer un compte séparé pour votre identité "professionnelle" sur l'ordinateur domestique. Bien sûr, si vous vous connectez à votre domicile dans le but d'accéder à des fichiers personnels, cela pourrait ajouter quelques tracas; mais dans le but indiqué, cela devrait en fait éviter l'encombrement et la distraction.

Et une fois que vous avez le compte séparé, vous pouvez faire autre chose pour le verrouiller: iptables règles pour l'empêcher de se connecter à des parties inutiles d'Internet; règles de temps de connexion pour empêcher la connexion lorsque vous ne seriez jamais au bureau de toute façon; règles pour limiter quelle adresse IP peut se connecter à ce compte.

Et bien sûr, une fois qu'un tel système est installé, gardez un œil sur les journaux et fermez tout s'il y a un signe d'intrus.

0
david