Ist es wirklich sicher, während einer Reise von einem Hotel aus eine Verbindung zu einem Server per SSH herzustellen?

Ist es wirklich sicher, während einer Reise über SSH von Hotels aus eine Verbindung zu einem Server herzustellen?

Server :
- CentOS 7
- Autorisierung nur über RSA-Schlüssel - Kennwortauthentifizierung verweigert
- Nicht-Standard-Port

Arbeitsstation :
- Ubuntu 14
- Benutzerpasswort
- Passwort zur Verwendung des RSA-Schlüssels (Standardmethode)

Vielleicht ist es eine gute Idee, die Hälfte des privaten RSA-Schlüssels auf einem USB-Stick zu belassen und diese Hälfte vor dem Herstellen der Verbindung automatisch (per Skript) zu ~ / .ssh / private_key hinzuzufügen?

Das Internet wird entweder über WIFI in Hotels oder über Kabel in einer Mietwohnung bereitgestellt.

UPD
Entschuldigen Sie, dass Sie zunächst unklar sind. Ich meine hier Sicherheit in zwei Aspekten:

Sicherheit nur der SSH-Verbindung über ein nicht vertrauenswürdiges Netzwerk.
Sicherheit eines Computers mit dem für die SSH-Verbindung erforderlichen Schlüssel - wie kann der Server geschützt werden, wenn er gestohlen wird?

security physical-security

— Sergey Serov
quelle

Was für ein halber RSA-Schlüssel? Der öffentliche Teil des SSH-Hostschlüssels? Die Hälfte des privaten Teils Ihres Benutzer-SSH-Schlüssels?

— Andol

Natürlich die Hälfte meines privaten RSA-Schlüssels :) und automatisch per Skript, um diese Hälfte zu ~ / .ssh / private_key hinzuzufügen, bevor eine Verbindung zum Server hergestellt wird.

— Sergey Serov

Sie sind bereits sicherer als die meisten anderen, da Sie Linux verwenden. Da Sie neuere Versionen verwenden, sollten Sie über neue Versionen von OpenSSH verfügen, die stärkere Kryptografie unterstützen. Nach dem FolgenWenn Sie tecmint.com/5-best-practices-to-secure-and-protect-ssh-server können Sie sich auf eine stärkere Verschlüsselung

— chicks

@chicks "sicherer als die meisten Leute, weil Sie Linux verwenden" ist eine dumme Sache zu sagen. SSH ist SSH, unabhängig davon, ob es unter Linux, Unix (Mac) oder Windows ausgeführt wird. Und wir könnten auf eine Reihe äußerst schwerwiegender Sicherheitslücken in Linux in der jüngeren Geschichte hinweisen (Heartbleed, irgendjemand?). Sagen wir einfach, lassen wir die albernen OS-Flammenkriege an den Rändern, wo sie hingehören, weil sie von den eigentlichen Fragen und Problemen ablenken. Vielen Dank! ;-)

— Craig

@chicks Ich denke, das habe ich versucht zu vermitteln. Viele Sicherheitsprobleme in allen Betriebssystemen, und Microsoft hat enorme Fortschritte erzielt, seit es vor einigen Jahren mit der Initiative "Trustworthy Computing" begonnen hat. Ich denke nur, dass die Sache "Sie sind sicherer, weil Linux" die Konversation vom eigentlichen Problem ablenkt ( respektvoll). ;-)

— Craig

Antworten:

In Bezug auf das Herstellen einer ssh-Verbindung über eine explizit nicht vertrauenswürdige Verbindung.

Angenommen, Sie haben bereits einen ~ / .ssh / known_hosts-Eintrag von einer vorherigen Verbindung, dann sollten Sie in der Lage sein, eine Verbindung herzustellen, ohne sich Gedanken darüber zu machen, ob das Netzwerk sicher ist oder nicht. Dasselbe gilt, wenn Sie eine andere Möglichkeit haben, den SSH-Hostschlüssel zu überprüfen.

Wenn Sie noch nie zuvor eine Verbindung zum Server hergestellt haben oder den SSH-Hostschlüssel auf andere Weise überprüfen konnten, sollten Sie möglicherweise das für die Verbindung verwendete Netzwerk genauer betrachten.

— andol
quelle

Danke!! Es ist also sicher, über SSH eine Verbindung zum Server herzustellen, auch über eine öffentliche Wi-Fi-Verbindung?

— Sergey Serov

Tatsächlich gilt diese Antwort für alle Situationen, in denen Sie eine Verbindung zu einem Remote-Server herstellen möchten und ein Teil des Pfads nicht vollständig unter Ihrer Kontrolle steht (praktisch alles, außer die Verbindung zu einem frisch installierten Localhost oder über ein Querverbindungskabel )

— Hagen von Eitzen

Es ist zu beachten, dass, wenn der Client den Hostschlüssel nicht kennt, ein vollständiger MITM-Angriff möglich ist, wenn die Kennwortauthentifizierung verwendet wird. Bei Verwendung der schlüsselbasierten Authentifizierung kann der Angreifer jedoch nur die Identität des Servers annehmen. Der Angreifer kann sich auch nicht beim realen Server authentifizieren. In diesem Fall ist es für einen Angreifer schwierig, eine überzeugende Identität des Servers anzugeben, sodass Sie möglicherweise feststellen können, dass etwas nicht stimmt, bevor es zu spät ist. Kurz gesagt: Die Authentifizierung mit öffentlichen Schlüsseln ist viel sicherer als die Kennwortauthentifizierung .

— Kasperd

@kasperd: Wenn der verbindende Client die Agentenweiterleitung aktiviert hat, kann sogar die Authentifizierung mit öffentlichem Schlüssel das volle MITM-Erlebnis bieten. Aber ja, die Authentifizierung mit öffentlichen Schlüsseln ist normalen Passwörtern jeden Tag vorzuziehen.

— Andol

@kasperd: Nun, ich kann mir leicht vorstellen, dass jemand die Agentenweiterleitung entdeckt, sie aber nicht vollständig versteht, indem er in seine ~ / .ssh / config so etwas wie "Host * \ n \ tForwardAgent yes" schreibt. Die Leute machen alle

— möglichen

Im zweiten Teil Ihrer Frage scheinen Sie besorgt darüber zu sein, dass Ihr Notebook und damit Ihre privaten Schlüssel für Ihre passwortlose SSH-Anmeldung bei Ihren Servern gestohlen werden.

Beachten Sie, dass dies leicht gelöst werden kann (Problem mit privaten Schlüsseln), indem private Schlüssel "verschlüsselt" mit einer "Passphrase" gespeichert werden: Sie können beim Generieren mit dem Dienstprogramm ssh-keygen zunächst verschlüsselt werden , indem am Ende von eine Passphrase angegeben wird den Generierungsprozess oder, falls Sie sie bereits nicht kodiert haben, mit dem ssh-keygen Dienstprogramm mit der -pOption. Sobald der Schlüssel verschlüsselt ist, werden Sie bei jeder Anmeldung aufgefordert, die zugehörige Passphrase einzugeben. Wenn dies zutrifft, läuft alles normal ab.

Wenn Sie die Passphrase nicht jedes Mal eingeben möchten, wenn Sie den ssh-client starten, können Sie den ssh-agent verwenden : Er kann unverschlüsselte private Schlüssel im Speicher verfolgen. Sie können einfach ssh-add ausführen und auf die Datei verweisen, die den verschlüsselten Schlüssel enthält. Nachdem Sie nach der Passphrase gefragt haben, wird der Schlüssel dem vom ssh-agent verwalteten Satz hinzugefügt. Jedes Mal, wenn der SSH-Client einen passphrasengeschützten Schlüssel benötigt, stellt der ssh-agent den zugehörigen unverschlüsselten privaten Schlüssel dem ssh-Client transparent zur Verfügung. Sie müssen es also nicht interaktiv eingeben.

Bitte beachten Sie, dass ssh-agent viele Schlüssel verwalten kann und Sie natürlich Ihr Notebook / Ihren Desktop "optimieren" können, um das zu starten ssh-add Dienstprogramm (zum Auffüllen des Schlüsselsatzes von ssh-agent) beim Anmelden / Starten .

Sollte jemand Ihren Laptop stehlen, sind Ihre privaten Schlüssel wahrscheinlich nicht der einzige "sensible" Inhalt, den Sie herausgeben werden. Beachten Sie, dass es mit heutigen Linux-Desktop-Distributionen SEHR einfach ist, ein Notebook einzurichten, das auf "verschlüsselt" basiert "Dateisystem (das /homeals Starter, aber das ganze /bei Bedarf). Bitte beachten Sie dies auch.

All dies gilt natürlich NICHT , wenn Sie sich NICHT auf IHR EIGENES Notebook verlassen.

PS: wie für die Möglichkeit , die beiden Hälften der unverschlüsselten privaten Schlüssel auf verschiedene Medien gespeichert werden soll : ich stark beraten Sie nicht , dies zu tun, als die beiden Stücke von sensibleren Inhalten in unverschlüsselter Form beibehalten wird viel, viel schlimmer, als zwei halten vollständige Kopien des gesamten Inhalts, verschlüsselt!

— Damiano Verzulli
quelle

Der erste Teil Ihrer Frage ist bereits durch die vorherige Antwort beantwortet. Gemäß Ihrem zweiten Teil würde ich empfehlen, Ihrem SSH-Login mit pam_google_authenticator einen zweiten Faktor hinzuzufügen. Es ist ziemlich einfach einzurichten und auf jeder Distribution zu konfigurieren. Falls der private Schlüssel, den Sie mit sich herumtragen, gestohlen wird, kann er sich ohne das einmalige TOTP-Passwort von google-authenticator nicht auf Ihrem Server anmelden.

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

— Arul Selvan
quelle