One place for hosting & domains

      einem

      Konfigurieren der SSH-Schlüssel-basierten Authentifizierung auf einem Linux-Server


      Einführung

      SSH oder Secure Shell ist ein verschlüsseltes Protokoll zur Verwaltung und Kommunikation mit Servern. Wenn Sie mit einem Linux-Server arbeiten, verbringen Sie wahrscheinlich die meiste Zeit in einer Terminalsitzung, die über SSH mit Ihrem Server verbunden ist.

      Es gibt zwar einige verschiedene Möglichkeiten, sich bei einem SSH-Server anzumelden, doch in diesem Leitfaden konzentrieren wir uns auf die Einrichtung von SSH-Schlüsseln. SSH-Schlüssel bieten eine einfache, aber extrem sichere Möglichkeit der Anmeldung an Ihrem Server. Aus diesem Grund ist dies die Methode, die wir für alle Benutzer empfehlen.

      Funktionsweise von SSH-Schlüsseln

      Ein SSH-Server kann Clients mit einer Vielzahl von verschiedenen Methoden authentifizieren. Die grundlegendste davon ist die Passwort-Authentifizierung, die einfach zu verwenden, aber nicht die sicherste ist.

      Obwohl Passwörter auf sichere Weise an den Server gesendet werden, sind sie im Allgemeinen nicht komplex oder lang genug, um wiederholten, hartnäckigen Angreifern zu widerstehen. Moderne Verarbeitungsleistung kombiniert mit automatisierten Skripten machen das Brute-Forcing eines passwortgeschützten Kontos sehr gut möglich. Obwohl es andere Methoden gibt, um zusätzliche Sicherheit (fail2ban usw.) hinzuzufügen, erweisen sich SSH-Schlüssel als eine zuverlässige und sichere Alternative.

      SSH-Schlüsselpaare sind zwei kryptografisch sichere Schlüssel, die zur Authentifizierung eines Clients gegenüber einem SSH-Server verwendet werden können. Jedes Schlüsselpaar besteht aus einem öffentlichen Schlüssel und einem privaten Schlüssel.

      Der private Schlüssel wird vom Client aufbewahrt und sollte absolut geheim gehalten werden. Jede Kompromittierung des privaten Schlüssels ermöglicht es dem Angreifer, sich ohne zusätzliche Authentifizierung an Servern anzumelden, die mit dem zugehörigen öffentlichen Schlüssel konfiguriert sind. Als zusätzliche Vorsichtsmaßnahme kann der Schlüssel auf der Festplatte mit einer Passphrase verschlüsselt werden.

      Der zugehörige öffentliche Schlüssel kann ohne negative Folgen geteilt werden. Der öffentliche Schlüssel kann zur Verschlüsselung von Nachrichten verwendet werden, die nur der private Schlüssel entschlüsseln kann. Diese Eigenschaft wird als eine Möglichkeit zur Authentifizierung mit dem Schlüsselpaar verwendet.

      Der öffentliche Schlüssel wird auf einen Remote-Server hochgeladen, an dem Sie sich mit SSH anmelden möchten. Der Schlüssel wird zu einer speziellen Datei innerhalb des Benutzerkontos hinzugefügt, bei dem Sie sich anmelden werden, namens ~/.ssh/authorized_keys.

      Wenn ein Client die Authentifizierung mit SSH-Schlüsseln versucht, kann der Server den Client daraufhin testen, ob er im Besitz des privaten Schlüssels ist. Wenn der Client beweisen kann, dass er den privaten Schlüssel besitzt, wird eine Shell-Sitzung erzeugt oder der angeforderte Befehl wird ausgeführt.

      Erstellen von SSH-Schlüsseln

      Der erste Schritt zur Konfiguration der SSH-Schlüsselauthentifizierung an Ihrem Server ist die Erstellung eines SSH-Schlüsselpaares auf Ihrem lokalen Computer.

      Dazu können wir ein spezielles Dienstprogramm namens ssh-keygen verwenden, das in der standardmäßigen OpenSSH-Suite von Tools enthalten ist. Standardmäßig erstellt dies ein RSA-Schlüsselpaar mit 2048 Bit, das für die meisten Verwendungen ausreichend ist.

      Erstellen Sie auf Ihrem lokalen Computer ein SSH-Schlüsselpaar durch Eingabe von:

      ssh-keygen
      
      Generating public/private rsa key pair.
      Enter file in which to save the key (/home/username/.ssh/id_rsa):
      

      Das Dienstprogramm fordert Sie auf, einen Speicherort für die zu erzeugenden Schlüssel auszuwählen. Standardmäßig werden die Schlüssel im Verzeichnis ~/.ssh innerhalb des Home-Verzeichnisses Ihres Benutzers gespeichert. Der private Schlüssel wird id_rsa genannt und der zugehörige öffentliche Schlüssel wird id_rsa.pub genannt.

      In der Regel ist es am besten, an dieser Stelle den Standardspeicherort beizubehalten. Auf diese Weise kann Ihr SSH-Client Ihre SSH-Schlüssel automatisch finden, wenn Sie versuchen, sich zu authentifizieren. Wenn Sie einen nicht standardmäßigen Pfad auswählen möchten, geben Sie diesen jetzt ein, andernfalls drücken Sie ENTER, um die Standardeinstellung zu akzeptieren.

      Wenn Sie zuvor ein SSH-Schlüsselpaar erstellt hatten, sehen Sie möglicherweise eine Eingabeaufforderung, die wie folgt aussieht:

      /home/username/.ssh/id_rsa already exists.
      Overwrite (y/n)?
      

      Wenn Sie den Schlüssel auf der Festplatte überschreiben, können Sie sich nicht mehr mit dem vorherigen Schlüssel authentifizieren. Seien Sie sehr vorsichtig bei der Auswahl von „Ja“, da dies ein destruktiver Prozess ist, der nicht rückgängig gemacht werden kann.

      Created directory '/home/username/.ssh'.
      Enter passphrase (empty for no passphrase):
      Enter same passphrase again:
      

      Als Nächstes werden Sie aufgefordert, eine Passphrase für den Schlüssel einzugeben. Dies ist eine optionale Passphrase, die zur Verschlüsselung der privaten Schlüsseldatei auf der Festplatte verwendet werden kann.

      Sie fragen sich vielleicht, welche Vorteile ein SSH-Schlüssel bietet, wenn Sie trotzdem eine Passphrase eingeben müssen. Einige der Vorteile sind:

      • Der private SSH-Schlüssel (der Teil, der mit einer Passphrase geschützt werden kann) wird niemals im Netzwerk offengelegt. Die Passphrase wird nur zur Entschlüsselung des Schlüssels auf dem lokalen Rechner verwendet. Das bedeutet, dass netzwerkbasiertes Brute-Forcing gegen die Passphrase nicht möglich ist.
      • Der private Schlüssel wird innerhalb eines eingeschränkten Verzeichnisses aufbewahrt. Der SSH-Client erkennt keine privaten Schlüssel, die nicht in eingeschränkten Verzeichnissen aufbewahrt werden. Der Schlüssel selbst muss ebenfalls eingeschränkte Berechtigungen haben (Lese- und Schreibrechte nur für den Eigentümer). Das bedeutet, dass andere Benutzer auf dem System nicht herumschnüffeln können.
      • Jeder Angreifer, der hofft, die Passphrase des privaten SSH-Schlüssels zu knacken, muss bereits Zugriff auf das System haben. Das bedeutet, dass sie bereits Zugriff auf Ihr Benutzerkonto oder das Root-Konto haben werden. Wenn Sie sich in dieser Position befinden, kann die Passphrase den Angreifer daran hindern, sich sofort an Ihren anderen Servern anzumelden. Dies gibt Ihnen hoffentlich Zeit zur Erstellung und Implementierung eines neuen SSH-Schlüsselpaares und zum Entfernen des Zugriffs des kompromittierten Schlüssels.

      Da der private Schlüssel niemals dem Netzwerk ausgesetzt wird und durch Dateiberechtigungen geschützt ist, sollte diese Datei niemals für jemand anderen als Sie (und den Root-Benutzer) zugänglich sein. Die Passphrase dient als eine zusätzliche Schutzschicht, falls diese Bedingungen kompromittiert werden.

      Eine Passphrase ist eine optionale Ergänzung. Wenn Sie eine eingeben, müssen Sie sie jedes Mal bei Verwendung dieses Schlüssels angeben (es sei denn, Sie verwenden eine SSH-Agentensoftware, die den entschlüsselten Schlüssel speichert). Wir empfehlen die Verwendung einer Passphrase, aber wenn Sie keine Passphrase festlegen möchten, können Sie einfach ENTER drücken, um diese Eingabeaufforderung zu umgehen.

      Your identification has been saved in /home/username/.ssh/id_rsa.
      Your public key has been saved in /home/username/.ssh/id_rsa.pub.
      The key fingerprint is:
      a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host
      The key's randomart image is:
      +--[ RSA 2048]----+
      |     ..o         |
      |   E o= .        |
      |    o. o         |
      |        ..       |
      |      ..S        |
      |     o o.        |
      |   =o.+.         |
      |. =++..          |
      |o=++.            |
      +-----------------+
      

      Sie haben jetzt einen öffentlichen und privaten Schlüssel, die Sie zur Authentifizierung verwenden können. Der nächste Schritt besteht darin, den öffentlichen Schlüssel auf Ihrem Server abzulegen, damit Sie sich mithilfe der SSH-Schlüsselauthentifizierung anmelden können.

      Einbetten Ihres öffentlichen Schlüssels bei der Erstellung Ihres Servers

      Wenn Sie einen neuen DigitalOcean-Server einrichten, können Sie Ihren öffentlichen SSH-Schlüssel automatisch in das Root-Konto Ihres neuen Servers einbinden.

      Am Ende der Droplet-Erstellungsseite gibt es eine Option, mit der Sie SSH-Schlüssel zu Ihrem Server hinzufügen können:

      SSH-Schlüssel einbetten

      Wenn Sie bereits eine öffentliche Schlüsseldatei zu Ihrem DigitalOcean-Konto hinzugefügt haben, sehen Sie diese hier als auswählbare Option (im obigen Beispiel gibt es zwei vorhandene Schlüssel: „Arbeitsschlüssel“ und „Heimschlüssel“). Um einen vorhandenen Schlüssel einzubetten, klicken Sie ihn einfach an und er wird hervorgehoben. Sie können mehrere Schlüssel auf einem einzigen Server einbetten:

      SSH-Schlüsselauswahl

      Wenn Sie noch keinen öffentlichen SSH-Schlüssel in Ihr Konto hochgeladen haben oder wenn Sie einen neuen Schlüssel zu Ihrem Konto hinzufügen möchten, klicken Sie auf die Schaltfläche „+ Add SSH Key“ (SSH-Schlüssel hinzufügen). Daraufhin erscheint eine Eingabeaufforderung:

      SSH-Schlüssel-Eingabeaufforderung

      Fügen Sie im Feld „SSH Key content“ (SSH-Schlüsselinhalt) den Inhalt Ihres öffentlichen SSH-Schlüssels ein. Angenommen, Sie haben Ihre Schlüssel mit der oben beschriebenen Methode erzeugt, können Sie den Inhalt Ihres öffentlichen Schlüssels auf Ihrem lokalen Computer abrufen, indem Sie eingeben:

      cat ~/.ssh/id_rsa.pub
      
      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNqqi1mHLnryb1FdbePrSZQdmXRZxGZbo0gTfglysq6KMNUNY2VhzmYN9JYW39yNtjhVxqfW6ewc+eHiL+IRRM1P5ecDAaL3V0ou6ecSurU+t9DR4114mzNJ5SqNxMgiJzbXdhR+j55GjfXdk0FyzxM3a5qpVcGZEXiAzGzhHytUV51+YGnuLGaZ37nebh3UlYC+KJev4MYIVww0tWmY+9GniRSQlgLLUQZ+FcBUjaqhwqVqsHe4F/woW1IHe7mfm63GXyBavVc+llrEzRbMO111MogZUcoWDI9w7UIm8ZOTnhJsk7jhJzG2GpSXZHmly/a/buFaaFnmfZ4MYPkgJD [email protected]
      

      Fügen Sie diesen Wert in seiner Gesamtheit in das größere Feld ein. Im Feld „Comment (optional)“ (Kommentar (optional)) können Sie eine Bezeichnung für den Schlüssel auswählen. Diese wird als Schlüsselname in der DigitalOcean-Oberfläche angezeigt:

      SSH neuer Schlüssel

      Wenn Sie Ihr Droplet erstellen, werden die von Ihnen ausgewählten öffentlichen SSH-Schlüssel in der Datei ~/.ssh/authorized_keys des Root-Benutzerkontos abgelegt. Dadurch können Sie sich von dem Computer mit Ihrem privaten Schlüssel an dem Server anmelden.

      Kopieren eines öffentlichen Schlüssels auf Ihren Server

      Wenn Sie bereits über einen Server verfügen und bei der Erstellung keine Schlüssel eingebettet haben, können Sie trotzdem Ihren öffentlichen Schlüssel hochladen und zur Authentifizierung an Ihrem Server verwenden.

      Welche Methode Sie verwenden, hängt weitgehend von den verfügbaren Tools und den Details Ihrer aktuellen Konfiguration ab. Die folgenden Methoden führen alle zu demselben Ergebnis. Die einfachste, am meisten automatisierte Methode steht an erster Stelle und die folgenden erfordern jeweils zusätzliche manuelle Schritte, wenn Sie die vorangegangenen Methoden nicht verwenden können.

      Kopieren Ihres öffentlichen Schlüssels mit SSH-Copy-ID

      Die einfachste Methode, Ihren öffentlichen Schlüssel auf einen vorhandenen Server zu kopieren, ist die Verwendung eines Dienstprogramms namens ssh-copy-id. Aufgrund ihrer Einfachheit wird diese Methode empfohlen, wenn sie verfügbar ist.

      Das Tool ssh-copy-id ist in vielen Distributionen in den OpenSSH-Paketen enthalten, sodass Sie es möglicherweise auf Ihrem lokalen System zur Verfügung haben. Damit diese Methode funktioniert, müssen Sie bereits über einen passwortbasierten SSH-Zugriff auf Ihren Server verfügen.

      Um das Utility zu verwenden, müssen Sie lediglich den Remote-Host, zu dem Sie eine Verbindung herstellen möchten, und das Benutzerkonto angeben, auf das Sie mit einem Passwort SSH-Zugriff haben. Dies ist das Konto, auf das Ihr öffentlicher SSH-Schlüssel kopiert werden soll.

      Die Syntax lautet:

      ssh-copy-id username@remote_host
      

      Sie sehen eventuell eine Nachricht wie diese:

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Dies bedeutet nur, dass Ihr lokaler Computer den Remote-Host nicht erkennt. Dies geschieht, wenn Sie zum ersten Mal eine Verbindung zu einem neuen Host herstellen. Geben Sie „yes“ ein und drücken Sie ENTER, um fortzufahren.

      Als nächstes durchsucht das Dienstprogramm Ihr lokales Konto nach dem Schlüssel id_rsa.pub, den wir zuvor erstellt haben. Wenn der Schlüssel gefunden wurde, werden Sie zur Eingabe des Passworts für das Konto des Remotebenutzers aufgefordert:

      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
      /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
      [email protected]'s password:
      

      Geben Sie das Passwort ein (Ihre Eingabe wird aus Sicherheitsgründen nicht angezeigt) und drücken Sie ENTER. Das Utility stellt mit dem von Ihnen angegebenen Passwort eine Verbindung zum Konto auf dem Remote-Host her. Anschließend wird der Inhalt Ihres Schlüssels ~/.ssh/id_rsa.pub in eine Datei im Stammverzeichnis ~/.ssh des Remote-Kontos namens authorized_keys kopiert.

      Sie werden eine Ausgabe sehen, die wie folgt aussieht:

      Number of key(s) added: 1
      
      Now try logging into the machine, with:   "ssh '[email protected]'"
      and check to make sure that only the key(s) you wanted were added.
      

      Zu diesem Zeitpunkt wurde Ihr Schlüssel id_rsa.pub in das Remote-Konto hochgeladen. Sie können mit dem nächsten Abschnitt fortfahren.

      Kopieren Ihres öffentlichen Schlüssels mit SSH

      Wenn Sie nicht über ssh-copy-id verfügen, aber einen passwortbasierten SSH-Zugriff auf ein Konto auf Ihrem Server haben, können Sie Ihre Schlüssel mit einer herkömmlichen SSH-Methode hochladen.

      Wir können dies tun, indem wir den Inhalt unseres öffentlichen SSH-Schlüssels auf unserem lokalen Computer ausgeben und ihn über eine SSH-Verbindung an den Remote-Server leiten. Auf der anderen Seite können wir sicherstellen, dass das Verzeichnis ~/.ssh unter dem von uns verwendeten Konto vorhanden ist und dann den von uns geleiteten Inhalt in eine Datei namens authorized_keys innerhalb dieses Verzeichnisses ausgeben.

      Wir werden das Umleitungssymbol >> verwenden, um den Inhalt anzuhängen, anstatt ihn zu überschreiben. Dadurch können wir Schlüssel hinzufügen, ohne zuvor hinzugefügte Schlüssel zu zerstören.

      Der vollständige Befehl sieht wie folgt aus:

      cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
      

      Sie sehen eventuell eine Nachricht wie diese:

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Dies bedeutet nur, dass Ihr lokaler Computer den Remote-Host nicht erkennt. Dies geschieht, wenn Sie zum ersten Mal eine Verbindung zu einem neuen Host herstellen. Geben Sie „yes“ ein und drücken Sie ENTER, um fortzufahren.

      Danach werden Sie aufgefordert, das Passwort des Kontos einzugeben, mit dem Sie versuchen, eine Verbindung herzustellen:

      [email protected]'s password:
      

      Nach Eingabe Ihres Passworts wird der Inhalt Ihres Schlüssels id_rsa.pub an das Ende der Datei authorized_keys des Kontos des Remote-Benutzers kopiert. Fahren Sie mit dem nächsten Abschnitt fort, wenn dies erfolgreich war.

      Manuelles Kopieren Ihres öffentlichen Schlüssels

      Wenn Sie keinen passwortbasierten SSH-Zugang zu Ihrem Server zur Verfügung haben, müssen Sie den obigen Vorgang manuell ausführen.

      Der Inhalt Ihrer Datei id_rsa.pub muss irgendwie zu einer Datei unter ~/.ssh/authorized_keys auf Ihrem Remote-Rechner hinzugefügt werden.

      Um den Inhalt Ihres Schlüssels id_rsa.pub anzuzeigen, geben Sie Folgendes in Ihren lokalen Computer ein:

      cat ~/.ssh/id_rsa.pub
      

      Sie werden den Inhalt des Schlüssels sehen, der etwa so aussehen kann:

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test
      

      Greifen Sie mit einer beliebigen verfügbaren Methode auf Ihren Remote-Host zu. Wenn Ihr Server beispielsweise ein DigitalOcean-Droplet ist, können Sie sich über die Web-Konsole im Bedienfeld anmelden:

      DigitalOcean-Konsolenzugriff

      Sobald Sie Zugriff auf Ihr Konto auf dem Remote-Server haben, sollten Sie sicherstellen, dass das Verzeichnis ~/.ssh angelegt ist. Dieser Befehl erstellt bei Bedarf das Verzeichnis oder unternimmt nichts, wenn es bereits vorhanden ist:

      mkdir -p ~/.ssh
      

      Jetzt können Sie die Datei authorized_keys in diesem Verzeichnis erstellen oder ändern. Sie können den Inhalt Ihrer Datei id_rsa.pub an das Ende der Datei authorized_keys anfügen und diese bei Bedarf mit folgendem Befehl erstellen:

      echo public_key_string >> ~/.ssh/authorized_keys
      

      Ersetzen Sie im obigen Befehl public_key_string​​​​ durch die Ausgabe des Befehls cat~/.ssh/id_rsa.pub, den Sie auf Ihrem lokalen System ausgeführt haben. Sie sollte mit ssh-rsa AAAA... beginnen.

      Wenn dies funktioniert, können Sie mit der Authentifizierung ohne Passwort fortfahren.

      Authentifizieren an Ihrem Server mit SSH-Schlüsseln

      Wenn Sie eines der oben genannten Verfahren erfolgreich abgeschlossen haben, sollten Sie sich beim Remote-Host anmelden können,* ohne* das Passwort des Remote-Kontos zu verwenden.

      Der grundlegende Prozess ist der gleiche:

      ssh username@remote_host
      

      Wenn Sie zum ersten Mal eine Verbindung zu diesem Host herstellen (wenn Sie die letzte Methode oben verwendet haben), wird möglicherweise Folgendes angezeigt:

      The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
      ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
      Are you sure you want to continue connecting (yes/no)? yes
      

      Dies bedeutet nur, dass Ihr lokaler Computer den Remote-Host nicht erkennt. Geben Sie „yes“ ein und drücken Sie dann ENTER, um fortzufahren.

      Wenn Sie keine Passphrase für Ihren privaten Schlüssel angegeben haben, werden Sie sofort angemeldet. Wenn Sie eine Passphrase für den privaten Schlüssel bei der Erstellung des Schlüssels angeben haben, werden Sie aufgefordert, ihn nun einzugeben. Anschließend sollte eine neue Shell-Sitzung mit dem Konto auf dem Remote-System für Sie erzeugt werden.

      Wenn dies erfolgreich war, fahren Sie fort, um zu erfahren, wie Sie den Server sperren können.

      Deaktivieren der Passwort-Authentifizierung auf Ihrem Server

      Wenn Sie sich mit SSH ohne Passwort bei Ihrem Konto anmelden konnten, haben Sie die auf SSH-Schlüssel-basierte Authentifizierung für Ihr Konto erfolgreich konfiguriert. Ihr passwortbasierter Authentifizierungsmechanismus ist jedoch weiterhin aktiv. Dies bedeutet, dass Ihr Server weiterhin Brute-Force-Angriffen ausgesetzt ist.

      Stellen Sie vor dem Ausführen der in diesem Abschnitt beschriebenen Schritte sicher, dass entweder die SSH-Schlüssel-basierte Authentifizierung für das Root-Konto auf diesem Server konfiguriert ist oder vorzugsweise, dass Sie die SSH-Schlüssel-basierte Authentifizierung für ein Konto auf diesem Server mit sudo-Zugriff konfiguriert haben. Dieser Schritt sperrt passwortbasierte Anmeldungen. Daher ist es von entscheidender Bedeutung, dass Sie weiterhin über administrativen Zugriff verfügen.

      Sobald die obigen Bedingungen erfüllt sind, melden Sie sich mit SSH-Schlüsseln an Ihrem Remote-Server entweder als „root“ oder mit einem Konto mit sudo-Berechtigungen an. Öffnen Sie die Konfigurationsdatei des SSH-Daemons:

      sudo nano /etc/ssh/sshd_config
      

      Suchen Sie in der Datei nach einer Anweisung namens PasswordAuthentication. Dies kann auskommentiert werden. Kommentieren Sie die Zeile aus und setzen Sie den Wert auf „Nein“. Dadurch wird Ihre Fähigkeit, sich über SSH mit Kontopasswörtern anzumelden, deaktiviert:

      PasswordAuthentication no
      

      Wenn Sie fertig sind, speichern und schließen Sie die Datei. Um die gerade vorgenommenen Änderungen tatsächlich zu implementieren, müssen Sie den Dienst neu starten.

      Auf Ubuntu- oder Debian-Rechnern können Sie diesen Befehl eingeben:

      sudo service ssh restart
      

      Auf CentOS/Fedora-Rechnern wird der Daemon sshd genannt:

      sudo service sshd restart
      

      Nach Abschluss dieses Schritts haben Sie Ihren SSH-Daemon erfolgreich so umgestellt, dass er nur noch auf SSH-Schlüssel reagiert.

      Zusammenfassung

      Sie sollten nun die SSH-Schlüssel-basierte Authentifizierung auf Ihrem Server konfiguriert haben, sodass Sie sich ohne Angabe eines Kontopasswortes anmelden können. Von hier aus gibt es viele Richtungen, in die Sie gehen können. Wenn Sie mehr über das Arbeiten mit SSH erfahren möchten, sehen Sie sich unseren Leitfaden über SSH-Grundlagen an.



      Source link

      Nutzung von SFTP zur sicheren Übertragung von Dateien mit einem Remote-Server


      Einführung

      FTP oder „File Transfer Protocol“ (Dateiübertragungsprotokoll) war eine beliebte unverschlüsselte Methode zur Übertragung von Dateien zwischen zwei Remote-Systemen.

      SFTP, das für SSH File Transfer Protocol (SSH-Dateiübertragungsprotokoll) oder Secure File Transfer Protocol (sicheres Dateiübertragungsprotokoll) steht, ist ein separates Protokoll, das mit SSH verpackt ist und auf ähnliche Weise funktioniert, jedoch über eine sichere Verbindung. Der Vorteil ist die Fähigkeit zur Nutzung einer sicheren Verbindung zur Übertragung von Dateien und zum Durchlaufen des Dateisystems sowohl auf dem lokalen als auch auf dem Remote-System.

      In fast allen Fällen ist SFTP aufgrund der zugrunde liegenden Sicherheitsfunktionen und der Fähigkeit, eine SSH-Verbindung einzubinden, gegenüber FTP vorzuziehen. FTP ist ein unsicheres Protokoll, das nur in begrenzten Fällen oder auf Netzwerken verwendet werden sollte, denen Sie vertrauen.

      Obwohl SFTP in viele grafische Tools integriert ist, wird in diesem Leitfaden die Verwendung über die interaktive Befehlszeilenschnittstelle demonstriert.

      Verbindung mit SFTP

      Standardmäßig verwendet SFTP das SSH-Protokoll, um eine sichere Verbindung zu authentifizieren und zu erstellen. Aus diesem Grund sind die gleichen Authentifizierungsmethoden verfügbar, die auch in SSH vorhanden sind.

      Obwohl Passwörter einfach zu verwenden und standardmäßig eingerichtet sind, empfehlen wir Ihnen, SSH-Schlüssel zu erstellen und Ihren öffentlichen Schlüssel auf jedes System zu übertragen, auf das Sie zugreifen müssen. Dies ist wesentlich sicherer und kann Ihnen auf lange Sicht Zeit sparen.

      Bitte sehen Sie sich diesen Leitfaden zur Einrichtung von SSH-Schlüsseln für den Zugriff auf Ihren Server an, wenn Sie dies noch nicht getan haben.

      Wenn Sie über SSH eine Verbindung zu dem Rechner herstellen können, haben Sie alle notwendigen Voraussetzungen erfüllt, um SFTP zur Verwaltung von Dateien zu verwenden. Testen Sie den SSH-Zugriff mit dem folgenden Befehl:

      • ssh sammy@your_server_ip_or_remote_hostname

      Wenn dies funktioniert, geben Sie zum Verlassen Folgendes ein:

      Jetzt können wir eine SFTP-Sitzung aufbauen, indem wir den folgenden Befehl ausgeben:

      • sftp sammy@your_server_ip_or_remote_hostname

      Sie stellen eine Verbindung zum Remote-System her, und Ihre Eingabeaufforderung ändert sich in eine SFTP-Eingabeaufforderung.

      Wenn Sie an einem benutzerdefinierten SSH-Port arbeiten (nicht dem Standard-Port 22), können Sie eine SFTP-Sitzung wie folgt öffnen:

      • sftp -oPort=custom_port sammy@your_server_ip_or_remote_hostname

      Dadurch werden Sie über den von Ihnen angegebenen Port mit dem Remote-System verbunden.

      Hilfe in SFTP erhalten

      Der nützlichste Befehl, den Sie zuerst lernen sollten, ist der Hilfebefehl. Damit haben Sie Zugriff auf eine Zusammenfassung der SFTP-Hilfe. Sie können sie aufrufen, indem Sie einen der folgenden Befehle in die Eingabeaufforderung eingeben:

      oder

      Damit wird eine Liste der verfügbaren Befehle angezeigt:

      Output

      Available commands: bye Quit sftp cd path Change remote directory to 'path' chgrp grp path Change group of file 'path' to 'grp' chmod mode path Change permissions of file 'path' to 'mode' chown own path Change owner of file 'path' to 'own' df [-hi] [path] Display statistics for current directory or filesystem containing 'path' exit Quit sftp get [-Ppr] remote [local] Download file help Display this help text lcd path Change local directory to 'path' . . .

      Einige der angezeigten Befehle werden wir in den folgenden Abschnitten näher betrachten.

      Wir können durch die Dateihierarchie des Remote-Systems navigieren, indem wir eine Reihe von Befehlen verwenden, die ähnlich wie ihre Shell-Gegenstücke funktionieren.

      Orientieren wir uns zunächst, indem wir herausfinden, in welchem Verzeichnis wir uns derzeit im Remote-System befinden. Genau wie in einer typischen Shell-Sitzung können wir Folgendes eingeben, um das aktuelle Verzeichnis zu erhalten:

      Output

      Remote working directory: /home/demouser

      Wir können den Inhalt des aktuellen Verzeichnisses des Remote-Systems mit einem anderen vertrauten Befehl anzeigen:

      Output

      Summary.txt info.html temp.txt testDirectory

      Beachten Sie, dass die Befehle innerhalb der SFTP-Schnittstelle nicht die normalen Shell-Befehle sind und nicht so funktionsreich sind, aber sie implementieren einige der wichtigeren optionalen Flags:

      Output

      drwxr-xr-x 5 demouser demouser 4096 Aug 13 15:11 . drwxr-xr-x 3 root root 4096 Aug 13 15:02 .. -rw------- 1 demouser demouser 5 Aug 13 15:04 .bash_history -rw-r--r-- 1 demouser demouser 220 Aug 13 15:02 .bash_logout -rw-r--r-- 1 demouser demouser 3486 Aug 13 15:02 .bashrc drwx------ 2 demouser demouser 4096 Aug 13 15:04 .cache -rw-r--r-- 1 demouser demouser 675 Aug 13 15:02 .profile . . .

      Um in ein anderes Verzeichnis zu gelangen, können wir diesen Befehl ausgeben:

      Wir können nun das Remote-Dateisystem durchlaufen, aber was, wenn wir auf unser lokales Dateisystem zugreifen müssen? Wir können Befehle auf das lokale Dateisystem richten, indem wir ihnen ein l für lokal voranstellen.

      Alle bisher besprochenen Befehle haben lokale Entsprechungen. Wir können das lokale Arbeitsverzeichnis ausgeben:

      Output

      Local working directory: /Users/demouser

      Wir können den Inhalt des aktuellen Verzeichnisses auf dem lokalen Rechner auflisten:

      Output

      Desktop local.txt test.html Documents analysis.rtf zebra.html

      Wir können auch das Verzeichnis wechseln, mit dem wir auf dem lokalen System interagieren möchten:

      Übertragung von Dateien mit SFTP

      Das Navigieren der Remote- und lokalen Dateisysteme ist nur von begrenztem Nutzen, wenn keine Möglichkeit besteht, Dateien zwischen den beiden Systemen zu übertragen.

      Übertragung von Remote-Dateien auf das lokale System

      Wenn wir Dateien von unserem Remote-Host herunterladen möchten, können wir dies tun, indem wir den folgenden Befehl ausgeben:

      Output

      Fetching /home/demouser/remoteFile to remoteFile /home/demouser/remoteFile 100% 37KB 36.8KB/s 00:01

      Wie Sie sehen können, lädt der Befehl get eine Remote-Datei in eine Datei mit dem gleichen Namen auf dem lokalen Dateisystem herunter.

      Wir können die Remote-Datei unter einem anderen Namen kopieren, indem wir den Namen anschließend angeben:

      Der Befehl get nimmt auch einige Options-Flags an. Beispielsweise können wir ein Verzeichnis und seinen gesamten Inhalt kopieren, indem wir die Option rekursiv angeben:

      Wir können SFTP anweisen, die entsprechenden Berechtigungen und Zugriffszeiten beizubehalten, indem wir das Flag -P oder -p verwenden:

      Übertragung lokaler Dateien auf das Remote-System

      Die Übertragung von Dateien auf das Remote-System lässt sich ebenso einfach mit dem entsprechend benannten Befehl „put“ erreichen:

      Output

      Uploading localFile to /home/demouser/localFile localFile 100% 7607 7.4KB/s 00:00

      Die gleichen Flags, die mit get funktionieren, gelten auch für put. Um also ein vollständiges lokales Verzeichnis zu kopieren, können Sie ausgeben:

      Anmerkung: In den Versionen von OpenSSH, die mit aktuellen Ubuntu-Versionen (zumindest 14.04 bis 15.10) ausgeliefert werden, gibt es derzeit einen Fehler, der verhindert, dass der obige Befehl korrekt funktioniert. Wenn Sie den obigen Befehl ausgeben, um Inhalte auf einen Server zu übertragen, der die fehlerhafte Version von OpenSSH verwendet, wird der folgende Fehler ausgegeben: Couldn't canonicalise: No such file or directory (Keine Kanonisierung möglich: keine solche Datei oder solches Verzeichnis).

      Um dieses Problem zu umgehen, erstellen Sie zuerst das Zielverzeichnis auf der Remote-Seite, indem Sie mkdir localDirectory eingeben. Anschließend sollte der obige Befehl ohne Fehler abschließen.

      Ein bekanntes Tool, das beim Herunterladen und Hochladen von Dateien nützlich ist, ist der Befehl df, der ähnlich wie die Kommandozeilenversion funktioniert. Damit können Sie überprüfen, ob Sie über ausreichend Speicherplatz verfügen, um die gewünschten Übertragungen durchzuführen:

      Output

      Size Used Avail (root) %Capacity 19.9GB 1016MB 17.9GB 18.9GB 4%

      Bitte beachten Sie, dass es keine lokale Variante dieses Befehls gibt, jedoch können wir dies umgehen, indem wir den Befehl ! eingeben.

      Der Befehl ! versetzt uns in eine lokale Shell, in der wir jeden auf unserem lokalen System verfügbaren Befehl ausführen können. Wir können die Festplattennutzung überprüfen, indem wir Folgendes eingeben:

      und dann

      Output

      Filesystem Size Used Avail Capacity Mounted on /dev/disk0s2 595Gi 52Gi 544Gi 9% / devfs 181Ki 181Ki 0Bi 100% /dev map -hosts 0Bi 0Bi 0Bi 100% /net map auto_home 0Bi 0Bi 0Bi 100% /home

      Jeder andere lokale Befehl wird wie erwartet funktionieren. Um zu Ihrer SFTP-Sitzung zurückzukehren, geben Sie Folgendes ein:

      Sie sollten nun wieder die SFTP-Eingabeaufforderung sehen.

      Einfache Dateimanipulation mit SFTP

      Mit SFTP können Sie die Art der grundlegenden Dateiwartung durchführen, die bei der Arbeit mit Dateihierarchien nützlich ist.

      Beispielsweise können Sie den Eigentümer einer Datei auf dem Remote-System ändern:

      Beachten Sie, dass der SFTP-Befehl im Gegensatz zum Systembefehl chmod keine Benutzernamen akzeptiert, sondern stattdessen UIDs verwendet. Leider gibt es keine einfache Möglichkeit, die entsprechende UID innerhalb der SFTP-Schnittstelle zu kennen.

      Eine aufwändige Umgehung könnte erreicht werden mit:

      • get /etc/passwd
      • !less passwd

      Output

      root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/bin/sh man:x:6:12:man:/var/cache/man:/bin/sh . . .

      Beachten Sie, dass wir den Befehl ! nicht für sich allein gegeben haben, sondern als Präfix für einen lokalen Shell-Befehl verwendet haben. Dies funktioniert, um jeden Befehl auszuführen, der auf unserem lokalen Rechner verfügbar ist, und hätte zuvor mit dem lokalen Befehl df verwendet werden können.

      Die UID wird in der dritten Spalte der Datei stehen, die durch Doppelpunkt abgegrenzt ist.

      Auf ähnliche Weise können wir den Gruppeneigentümer einer Datei ändern mit:

      Auch hier gibt es keine einfache Möglichkeit, eine Auflistung der Gruppen des Remote-Systems zu erhalten. Wir können dies mit dem folgenden Befehl umgehen:

      • get /etc/group
      • !less group

      Output

      root:x:0: daemon:x:1: bin:x:2: sys:x:3: adm:x:4: tty:x:5: disk:x:6: lp:x:7: . . .

      Die dritte Spalte enthält die ID der Gruppe, die mit dem Namen in der ersten Spalte verknüpft ist. Das ist, wonach wir suchen.

      Zum Glück funktioniert der Befehl chmod wie erwartet auf dem Remote-Dateisystem:

      Output

      Changing mode on /home/demouser/publicFile

      Es gibt keinen Befehl zur Manipulation lokaler Dateiberechtigungen, aber Sie können die lokale umask festlegen, sodass alle auf das lokale System kopierten Dateien die entsprechenden Berechtigungen aufweisen.

      Das kann mit dem Befehl lumask geschehen:

      Output

      Local umask: 022

      Jetzt haben alle regulären Dateien, die heruntergeladen werden (solange das Flag -p nicht verwendet wird) 644 Berechtigungen.

      Mit SFTP können Sie Verzeichnisse sowohl auf lokalen als auch auf Remote-Systemen mit lmkdir bzw. mkdir erstellen. Diese funktionieren wie erwartet.

      Der Rest der Dateibefehle zielt nur auf das Remote-Dateisystem ab:

      Diese Befehle replizieren das grundlegende Verhalten der Shell-Versionen. Wenn Sie diese Aktionen auf dem lokalen Dateisystem ausführen müssen, denken Sie daran, dass Sie durch Ausgabe des folgenden Befehls in eine Shell wechseln können:

      Oder führen Sie einen einzelnen Befehl auf dem lokalen System aus, indem Sie dem Befehl das ! voranstellen, wie hier:

      Wenn Sie mit Ihrer SFTP-Sitzung fertig sind, verwenden Sie exit oder bye, um die Verbindung zu schließen.

      Zusammenfassung

      Obwohl SFTP ein einfaches Tool ist, ist es sehr nützlich für die Verwaltung von Servern und die Übertragung von Dateien zwischen ihnen.

      Beispielsweise können Sie SFTP verwenden, um bestimmten Benutzern die Übertragung von Dateien ohne SSH-Zugriff zu ermöglichen. Weitere Informationen zu diesem Vorgang finden Sie in unserem Tutorial Aktivieren von SFTP ohne Shell-Zugriff.

      Wenn Sie gewohnt sind, FTP oder SCP für Ihre Übertragungen zu verwenden, ist SFTP eine gute Möglichkeit, die Stärken beider zu nutzen. Obwohl es nicht für jede Situation geeignet ist, ist es ein flexibles Tool, das Sie in Ihrem Repertoire haben sollten.



      Source link

      Verwenden von SSH zum Herstellen einer Verbindung mit einem Remoteserver


      Einführung

      Ein wesentliches Tool, das ein Systemadministrator beherrschen sollte, ist SSH.

      SSH oder Secure Shell ist ein Protokoll, das zur sicheren Anmeldung bei Remotesystemen verwendet wird. Es ist die häufigste Methode für den Zugriff auf Remote-Linux-Server.

      In diesem Leitfaden diskutieren wir, wie SSH zur Herstellung einer Verbindung mit einem Remotesystem genutzt werden kann.

      Grundlegende Syntax

      Um per SSH eine Verbindung mit einem Remotesystem herzustellen, verwenden wir den Befehl ssh. Die grundlegendste Form des Befehls ist:

      Der remote_host in diesem Beispiel ist die IP-Adresse oder der Domänenname, mit der oder dem Sie eine Verbindung herstellen möchten.

      Dieser Befehl geht davon aus, dass Ihr Benutzername im Remotesystem der gleiche wie Ihr Benutzername in Ihrem lokalen System ist.

      Wenn Ihr Benutzername im Remotesystem anders ist, können Sie ihn durch Verwendung dieser Syntax angeben:

      • ssh remote_username@remote_host

      Sobald Sie mit dem Server verbunden sind, werden Sie möglicherweise aufgefordert, Ihre Identität durch Angabe eines Passworts zu verifizieren. Später werden wir auf die Erstellung von Schlüsseln zur Verwendung anstelle von Passwörtern eingehen.

      Um die SSH-Sitzung zu beenden und zu Ihrer lokalen Shell-Sitzung zurückzukehren, geben Sie Folgendes ein:

      Wie funktioniert SSH?

      SSH arbeitet, indem ein Clientprogramm mit einem SSH-Server namens sshd verbunden wird.

      Im vorherigen Abschnitt war ssh das Clientprogramm. Der SSH-Server wird bereits auf dem von uns angegebenen remote_host ausgeführt.

      Auf Ihrem Server sollte der sshd-Server bereits ausgeführt werden. Wenn dies nicht der Fall ist, müssen Sie möglicherweise über eine webbasierte Konsole oder eine lokale serielle Konsole auf Ihren Server zugreifen.

      Der Prozess, der zum Starten eines SHH-Servers erforderlich ist, hängt von der Linux-Distribution ab, die Sie verwenden.

      Unter Ubuntu können Sie den SSH-Server durch folgende Eingabe starten:

      Damit sollte der sshd-Server starten und Sie können sich remote anmelden.

      Konfigurieren von SSH

      Wenn Sie die Konfiguration von SSH ändern, ändern Sie die Einstellungen des sshd-Servers.

      In Ubuntu befindet sich die Hauptkonfigurationsdatei von sshd unter /etc/ssh/sshd_config.

      Sichern Sie vor der Bearbeitung die aktuelle Version dieser Datei:

      • sudo cp /etc/ssh/sshd_config{,.bak}

      Öffnen Sie sie mit einem Texteditor:

      • sudo nano /etc/ssh/sshd_config

      Die meisten Optionen in dieser Datei werden Sie nicht verändern wollen. Es gibt jedoch einige Optionen, auf die Sie möglicherweise einen Blick werfen möchten:

      /etc/ssh/sshd_config

      Port 22
      

      Die Portdeklaration gibt an, an welchem Port der sshd-Server nach Verbindungen lauschen wird. Standardmäßig ist dies Port 22. Sie sollten diese Einstellung wahrscheinlich unverändert lassen, es sei denn, Sie haben spezifische Gründe für ein anderes Vorgehen. Wenn Sie Ihren Port tatsächlich ändern, zeigen wir Ihnen später, wie Sie eine Verbindung mit dem neuen Port herstellen können.

      /etc/ssh/sshd_config

      HostKey /etc/ssh/ssh_host_rsa_key
      HostKey /etc/ssh/ssh_host_dsa_key
      HostKey /etc/ssh/ssh_host_ecdsa_key
      

      Die Hostschlüsseldeklarationen geben an, wo nach globalen Hostschlüsseln gesucht werden soll. Wir werden später erörtern, was ein Hostschlüssel ist.

      /etc/ssh/sshd_config

      SyslogFacility AUTH
      LogLevel INFO
      

      Diese beiden Elemente zeigen die Protokollierungsstufe an, die ausgeführt werden sollte.

      Wenn Sie Probleme mit SSH haben, ist die Erhöhung der Protokollierungsstufe ggf. eine gute Möglichkeit, um zu ermitteln, was das Problem ist.

      /etc/ssh/sshd_config

      LoginGraceTime 120
      PermitRootLogin yes
      StrictModes yes
      

      Diese Parameter geben einige der Anmeldedaten an.

      LoginGraceTime gibt an, wie viele Sekunden die Verbindung ohne eine erfolgreiche Anmeldung aufrechterhalten wird.

      Es ist ggf. eine gute Idee, diese Zeit nur etwas höher als die Zeit anzusetzen, die Sie normalerweise zum Anmelden benötigen.

      PermitRootLogin gibt an, ob sich der root-Benutzer anmelden darf.

      In den meisten Fällen sollte dies in no geändert werden, wenn Sie ein Benutzerkonto erstellt haben, das Zugriff auf erhöhte Berechtigungen hat (über su oder sudo) und sich über SSH anmelden kann.

      strictModes ist ein Sicherheitswächter, der Anmeldeversuche verweigert, wenn die Authentifizierungsdateien für alle lesbar sind.

      Dadurch werden Anmeldeversuche verhindert, wenn Konfigurationsdateien nicht sicher sind.

      /etc/ssh/sshd_config

      X11Forwarding yes
      X11DisplayOffset 10
      

      Diese Parameter konfigurieren eine Funktion namens X11 Forwarding. Dadurch können Sie die grafische Benutzeroberfläche (GUI) eines Remotesystems im lokalen System anzeigen.

      Diese Option muss auf dem Server aktiviert und mit dem SSH-Client während der Verbindung mit der Option -X übergeben werden.

      Speichern und schließen Sie nach dem Vornehmen Ihrer Änderungen die Datei durch Eingabe von STRG+X und Y gefolgt von ENTER.

      Wenn Sie Einstellungen in /etc/ssh/sshd_config geändert haben, stellen Sie sicher, dass Sie Ihren sshd-Server zur Implementierung der Änderungen neu laden:

      • sudo systemctl reload ssh

      Sie sollten Ihre Änderungen sorgfältig testen, um sicherzustellen, dass sie wie erwartet funktionieren.

      Es ist möglicherweise eine gute Idee, beim Vornehmen von Änderungen einige aktive Sitzungen zu haben. Dadurch können Sie die Konfiguration bei Bedarf zurücksetzen.

      Anmelden bei SSH mit Schlüsseln

      Es ist zwar nützlich, sich mit Passwörtern bei einem Remotesystem anmelden zu können, doch ist es eine wesentlich bessere Idee, schlüsselbasierte Authentifizierung einzurichten.

      Wie funktioniert schlüsselbasierte Authentifizierung?

      Schlüsselbasierte Authentifizierung funktioniert durch Erstellen eines Schlüsselpaars, bestehend aus einem privaten Schlüssel und einem öffentlichen Schlüssel.

      Der private Schlüssel befindet sich auf dem Clientrechner, ist gesichert und wird geheim gehalten.

      Der öffentliche Schlüssel kann an beliebige Personen weitergegeben oder auf jedem Server platziert werden, auf den Sie zugreifen möchten.

      Wenn Sie versuchen, eine Verbindung mit einem Schlüsselpaar herzustellen, verwendet der Server den öffentlichen Schlüssel zur Erstellung einer Nachricht für den Clientcomputer, die nur mit dem privaten Schlüssel gelesen werden kann.

      Der Clientcomputer sendet dann die entsprechende Antwort zurück an den Server und der Server weiß, dass der Client legitim ist.

      Das gesamte Verfahren erfolgt nach Einrichtung der Schlüssel automatisch.

      Erstellen von SSH-Schlüsseln

      SSH-Schlüssel sollten auf dem Computer erstellt werden, von dem aus Sie sich anmelden möchten. Dies ist normalerweise Ihr lokaler Rechner.

      Geben Sie Folgendes in die Befehlszeile ein:

      Drücken Sie die Eingabetaste zum Akzeptieren der Standardeinstellungen. Ihre Schlüssel werden unter ~/.ssh/id_rsa.pub und ~/.ssh/id_rsa erstellt.

      Wechseln Sie durch folgende Eingabe zum Verzeichnis .ssh:

      Sehen Sie sich die Berechtigungen der Dateien an:

      Output

      -rw-r--r-- 1 demo demo 807 Sep 9 22:15 authorized_keys -rw------- 1 demo demo 1679 Sep 9 23:13 id_rsa -rw-r--r-- 1 demo demo 396 Sep 9 23:13 id_rsa.pub

      Wie Sie sehen können, ist die Datei id_rsa nur für den Besitzer lesbar und beschreibbar. So sollte es sein, um sie geheim zu halten.

      Die Datei id_rsa.pub kann jedoch weitergegeben werden und verfügt über entsprechende Berechtigungen.

      Übertragen Ihres öffentlichen Schlüssels auf den Server

      Wenn Sie derzeit über passwortbasierten Zugriff auf einen Server verfügen, können Sie durch Eingabe des folgenden Befehls Ihren öffentlichen Schlüssel auf den Server kopieren:

      Dadurch wird eine SSH-Sitzung gestartet. Nach der Eingabe Ihres Passworts wird Ihr öffentlicher Schlüssel in die autorisierte Schlüsseldatei des Servers kopiert, sodass Sie sich beim nächsten Mal ohne das Passwort anmelden können.

      Optionen auf der Clientseite

      Es gibt eine Reihe von optionalen Flags, die Sie beim Verbinden über SSH wählen können.

      Einige davon könnten erforderlich sein, um mit den Einstellungen in der sshd-Konfiguration des Remote-Hosts übereinzustimmen.

      Wenn Sie beispielsweise die Portnummer in Ihrer sshd-Konfiguration geändert haben, müssen Sie durch folgende Angabe eine Anpassung an den Port auf der Clientseite vornehmen:

      • ssh -p port_number remote_host

      Wenn Sie nur einen einzigen Befehl in einem Remotesystem ausführen möchten, können Sie ihn nach dem Host wie folgt angeben:

      • ssh remote_host command_to_run

      Sie werden eine Verbindung mit dem Remoterechner herstellen und sich authentifizieren und der Befehl wird ausgeführt.

      Wie bereits gesagt: Wenn auf beiden Computern X11 Forwarding aktiviert ist, können Sie durch folgende Eingabe auf diese Funktion zugreifen:

      Wenn Sie über die entsprechenden Tools auf Ihrem Computer verfügen, öffnen die GUI-Programme, die Sie im Remotesystem verwenden, ihre Fenster nun auf Ihrem lokalen System.

      Deaktivieren der Passwortauthentifizierung

      Wenn Sie SSH-Schlüssel erstellt haben, können Sie durch Deaktivieren der ausschließlich passwortbasierten Authentifizierung die Sicherheit Ihres Servers erhöhen. Abgesehen von der Konsole ist die einzige Möglichkeit zur Anmeldung bei Ihrem Server der private Schlüssel, der zum öffentlichen Schlüssel passt, den Sie auf dem Server installiert haben.

      Warnung: Bevor Sie mit diesem Schritt fortfahren, stellen Sie sicher, dass Sie einen öffentlichen Schlüssel auf Ihrem Server installiert haben. Andernfalls werden Sie ausgesperrt!

      Öffnen Sie als root-Benutzer oder Benutzer mit sudo-Berechtigungen die sshd-Konfigurationsdatei:

      • sudo nano /etc/ssh/sshd_config

      Suchen Sie die Zeile, in der Password Authentication steht, und heben Sie die Kommentierung auf, indem Sie das führende #-Zeichen entfernen. Sie können dann den Wert in no ändern:

      /etc/ssh/sshd_config

      PasswordAuthentication no
      

      Zwei weitere Einstellungen, die nicht geändert werden sollten (sofern Sie diese Datei noch nicht geändert haben), sind PubkeyAuthentication und ChallengeResponseAuthentication. Sie werden standardmäßig gesetzt und sollten wie folgt aussehen:

      /etc/ssh/sshd_config

      PubkeyAuthentication yes
      ChallengeResponseAuthentication no
      

      Speichern und schließen Sie die Datei nach Vornahme Ihrer Änderungen.

      Sie können den SSH-Daemon nun neu laden:

      • sudo systemctl reload ssh

      Die Passwortauthentifizierung sollte nun deaktiviert und Ihr Server nur per SSH-Schlüsselauthentifizierung zugänglich sein.

      Zusammenfassung

      Sich mit SSH vertraut zu machen, ist eine lohnenswerte Aufgabe, schon weil sie so häufig erforderlich ist.

      Bei Verwendung der verschiedenen Optionen werden Sie erweiterte Funktionen entdecken, die Ihr Leben erleichtern können. SSH ist noch immer beliebt, da das Protokoll in verschiedenen Situationen sicher, leicht und hilfreich ist.



      Source link