One place for hosting & domains

      Konfigurieren

      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

      Konfigurieren des Remotezugriffs für MongoDB unter Ubuntu 20.04


      Eine frühere Version dieses Tutorials wurde von Melissa Anderson verfasst.

      Einführung

      MongoDB, auch als Mongo bekannt, ist eine Open-Source-Dokumentendatenbank, die für gewöhnlich in modernen Webanwendungen verwendet wird. Standardmäßig erlaubt sie nur Verbindungen, die von demselben Server stammen, auf dem sie installiert ist. Wenn Sie MongoDB aus der Ferne verwalten oder die Datenbank mit einem separaten Anwendungsserver verbinden möchten, müssen Sie einige Änderungen an der Standardkonfiguration vornehmen.

      In diesem Tutorial konfigurieren Sie eine MongoDB-Installation so, dass der Zugriff von einem vertrauenswürdigen Remotecomputer aus sicher möglich ist. Dazu aktualisieren Sie Ihre Firewall-Regeln, um dem Remotecomputer Zugriff auf den Port zu gewähren, auf dem MongoDB auf Verbindungen lauscht, und aktualisieren dann ihre Konfigurationsdatei, um ihre IP-Bindungseinstellung zu ändern. Als letzten Schritt testen Sie dann, dass Ihr Remotecomputer die Verbindung zu Ihrer Datenbank erfolgreich herstellen kann.

      Voraussetzungen

      Um dieses Tutorial zu absolvieren, benötigen Sie:

      • Einen Server, auf dem Ubuntu 20.04 ausgeführt wird. Dieser Server sollte über einen administrativen non-root user und eine mit UFW konfigurierte Firewall verfügen. Sie können dies einrichten, indem Sie unserem Leitfaden zur Ersteinrichtung des Servers mit Ubuntu 20.04 folgen.
      • MongoDB, das auf Ihrem Server installiert ist. Dieses Tutorial geht davon aus, dass Sie MongoDB 4.4 oder eine neuere Version installiert haben. Sie können diese Version installieren, indem Sie unserem Leitfaden zum Installieren von MongoDB unter Ubuntu 20.04 folgen.
      • Einen zweiten Computer, von dem Sie auf Ihre MongoDB-Instanz zugreifen. Aus Gründen der Einfachheit geht dieses Tutorial davon aus, dass es sich bei diesem Computer um einen weiteren Ubuntu 20.04-Server handelt, der mit einem administrativen non-root user und einer UFW-Firewall gemäß unserem Leitfaden zur Ersteinrichtung des Servers mit Ubuntu 20.04 konfiguriert ist. Schritt 1 und 2, die das eigentliche Verfahren zur Aktivierung des Remote-Zugriffs auf den Datenbankserver beschreiben, funktionieren jedoch unabhängig davon, unter welchem Betriebssystem der Remotecomputer ausgeführt wird.

      Auch wenn es zum Abschließen dieses Tutorials nicht erforderlich ist, empfehlen wir außerdem dringend, dass Sie Ihre MongoDB-Installation sichern, indem Sie ein administratives Benutzerkonto für die Datenbank erstellen und die Authentifizierung aktivieren. Folgen Sie dazu unserem Leitfaden Sichern von MongoDB unter Ubuntu 20.04.

      Schritt 1 — Anpassen der Firewall

      Unter der Annahme, dass Sie dem Leitfaden zur Ersteinrichtung des Servers aus den Voraussetzungen gefolgt sind und eine UFW-Firewall auf Ihrem Server aktiviert haben, ist Ihre MongoDB-Installation vom Internet nicht zugänglich. Wenn Sie MongoDB nur lokal mit Anwendungen verwenden möchten, die auf dem gleichen Server ausgeführt werden, ist dies die empfohlene und sichere Einstellung. Wenn Sie jedoch eine Verbindung mit Ihrem MongoDB-Server von einem entfernten Ort herstellen möchten, müssen Sie eingehende Verbindungen zu dem Port zulassen, auf dem die Datenbank lauscht, indem Sie eine neue UFW-Regel hinzufügen.

      Überprüfen Sie zunächst mit dem Befehl lsof, auf welchem Port Ihre MongoDB-Installation lauscht. Dieser Befehl gibt normalerweise eine Liste mit jeder offenen Datei in einem System aus. Wenn er jedoch mit der Option -i kombiniert wird, listet er nur netzwerkbezogene Dateien oder Datenströme auf.

      Der folgende Befehl leitet die von lsof -i erstellte Ausgabe an einen grep-Befehl weiter, der nach einer Zeichenfolge namens mongo sucht:

      • sudo lsof -i | grep mongo

      Diese Beispielausgabe zeigt, dass MongoDB den Verbindungen auf ihrem Standard-Port 27017 lauscht:

      Output

      mongod 82221 mongodb 11u IPv4 913411 0t0 TCP localhost:27017 (LISTEN)

      In den meisten Fällen sollte nur von bestimmten vertrauenswürdigen Orten auf MongoDB zugegriffen werden, wie z. B. von einem anderen Server, der eine Anwendung hostet. Um dies zu konfigurieren, besteht unter anderem die Möglichkeit, den folgenden Befehl auf Ihrem MongoDB-Server auszuführen. Dieser erlaubt den Zugriff auf den Standardport von MongoDB, lässt dabei jedoch nur die IP-Adresse des anderen vertrauenswürdigen Servers zu.

      Führen Sie den folgenden Befehl aus und ersetzen Sie hierbei trusted_server_ip mit der IP-Adresse des vertrauenswürdigen Remotecomputers, den Sie für den Zugriff auf Ihre MongoDB-Instanz nutzen möchten:

      Anmerkung: Wenn die Ausgabe des vorherigen Befehls gezeigt hat, dass Ihre Installation von MongoDB auf einem nicht standardmäßigen Port lauscht, verwenden Sie in diesem Befehl diese Portnummer anstelle von 27017.

      • sudo ufw allow from trusted_server_ip to any port 27017

      Wenn Sie in Zukunft von einem anderen Computer auf MongoDB zugreifen möchten, führen Sie diesen Befehl erneut mit der IP-Adresse des neuen Computers anstelle von trusted_server_ip aus.

      Sie können die Änderung der Firewall-Einstellungen mit ufw überprüfen:

      Die Ausgabe zeigt an, dass der Datenverkehr zum Port 27017 vom Remoteserver nun zugelassen wird:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 27017 ALLOW trusted_server_ip OpenSSH (v6) ALLOW Anywhere (v6)

      Weitere erweiterte Firewall-Einstellungen zum Einschränken des Zugriffs auf Dienste finden Sie in UFW-Grundlagen: gebräuchliche Firewall-Regeln und -Befehle.

      Als Nächstes binden Sie MongoDB an die öffentliche IP-Adresse des Servers, damit Sie von Ihrem Remotecomputer darauf zugreifen können.

      Schritt 2 — Konfigurieren einer öffentlichen bindIP

      Obwohl der Port geöffnet ist, ist MongoDB derzeit an 127.0.0.1 gebunden, die lokale Loopback-Netzwerkschnittstelle. Das bedeutet, dass MongoDB nur Verbindungen akzeptieren kann, die von dem Server stammen, auf dem die Datenbank installiert ist.

      Um Remoteverbindungen zu ermöglichen, müssen Sie die Konfigurationsdatei von MongoDB — /etc/mongod.conf — bearbeiten, um MongoDB zusätzlich an die öffentlich routbare IP-Adresse Ihres Servers zu binden. Auf diese Weise kann Ihre MongoDB-Installation auf Verbindungen zu Ihrem MongoDB-Server von Remotecomputern lauschen.

      Öffnen Sie die MongoDB-Konfigurationsdatei in Ihrem bevorzugten Editor. Das folgende Beispiel verwendet nano:

      • sudo nano /etc/mongod.conf

      Finden Sie den Abschnitt network interfaces und dann den bindIp-Wert:

      /etc/mongod.conf

      . . .
      # network interfaces
      net:
        port: 27017
        bindIp: 127.0.0.1
      
      . . .
      

      Hängen Sie dieser Zeile ein Komma an, gefolgt von der öffentlichen IP-Adresse Ihres MongoDB-Servers:

      /etc/mongod.conf

      . . .
      # network interfaces
      net:
        port: 27017
        bindIp: 127.0.0.1,mongodb_server_ip
      
      . . .
      

      Speichern und schließen Sie die Datei. Wenn Sie nano verwendet haben, drücken Sie STRG+X, Y, dann die EINGABETASTE.

      Starten Sie dann MongoDB neu, um diese Änderung umzusetzen:

      • sudo systemctl restart mongod

      Danach kann Ihre MongoDB-Installation Remoteverbindungen von allen Computern akzeptieren, denen Sie Zugriff auf Port 27017 gewährt haben. Als abschließenden Schritt können Sie testen, ob der vertrauenswürdige Remoteserver, den Sie in Schritt 1 über die Firewall erlauben, die MongoDB-Instanz auf Ihrem Server erreichen kann.

      Schritt 3 — Testen der Remotekonnektivität

      Nachdem Sie Ihre MongoDB-Installation so konfiguriert haben, dass sie auf Verbindungen lauscht, die von ihrer öffentlich routbaren IP-Adresse stammen, und Ihrem Remotecomputer Zugriff über die Firewall Ihres Servers auf den Standardport von Mongo gewährt haben, können Sie testen, ob der Remotecomputer in der Lage ist, sich zu verbinden.

      Anmerkung: Wie im Abschnitt Voraussetzungen erwähnt, geht dieses Tutorial davon aus, dass Ihr Remotecomputer ein anderer Server ist, auf dem Ubuntu 20.04 ausgeführt wird. Das in den Schritten 1 und 2 beschriebene Verfahren zur Aktivierung von Remoteverbindungen sollte unabhängig davon funktionieren, welches Betriebssystem auf Ihrem Remotecomputer ausgeführt wird. Die in diesem Schritt beschriebenen Testmethoden funktionieren jedoch nicht universell bei allen Betriebssystemen.

      Eine Möglichkeit, zu testen, dass Ihr vertrauenswürdiger Remoteserver eine Verbindung mit der MongoDB-Instanz herstellen kann, besteht in der Verwendung des nc-Befehls. nc, kurz für netcat, ist ein Dienstprogramm, das zum Erstellen von Netzwerkverbindungen mit TCP oder UDP verwendet wird. Er ist für Tests in Fällen wie diesen nützlich, da Sie sowohl eine IP-Adresse als auch eine Portnummer angeben können.

      Melden Sie sich zunächst mit SSH bei Ihrem vertrauenswürdigen Server an:

      • ssh sammy@trusted_server_ip

      Führen Sie dann den folgenden nc-Befehl aus, der die Option -z enthält. Dadurch wird nc darauf beschränkt, nur nach einem lauschenden Daemon auf dem Zielserver zu suchen, ohne diesem Daten zu senden. Erinnern Sie sich aus der Installationsanleitung in den Voraussetzungen, dass MongoDB als Dienst-Daemon ausgeführt wird. Daher ist diese Option nützlich zum Testen der Konnektivität. Außerdem enthält er die Option v, der die Ausführlichkeit des Befehls erhöht und bewirkt, dass netcat eine Ausgabe ausgibt, was sonst nicht geschehen würde.

      Führen Sie den folgenden nc-Befehl von Ihrem vertrauenswürdigen Remoteserver aus und stellen Sie sicher, mongodb_server_ip durch die IP-Adresse des Servers, auf dem Sie MongoDB installiert haben, zu ersetzen:

      • nc -zv mongodb_server_ip 27017

      Wenn der vertrauenswürdige Server auf den MongoDB-Daemon zugreifen kann, wird seine Ausgabe angeben, dass die Verbindung erfolgreich war:

      Output

      Connection to mongodb_server_ip 27017 port [tcp/*] succeeded!

      Wenn Sie eine kompatible Version der mongo-Shell auf Ihrem Remoteserver installiert haben, können Sie sich nun direkt mit der auf dem Hostserver installierten MongoDB-Instanz verbinden.

      Eine Möglichkeit zur Verbindung bietet eine URI-Verbindungszeichenfolge wie diese:

      • mongo "mongodb://mongo_server_ip:27017"

      Anmerkung: Wenn Sie dem empfohlenen Leitfaden Sichern von MongoDB unter Ubuntu 20.04 gefolgt sind, haben Sie den Zugriff auf Ihre Datenbank für nicht authentifizierte Benutzer geschlossen. In diesem Fall müssen Sie eine URI verwenden, die so wie die folgende einen gültigen Benutzernamen angibt:

      • mongo "mongodb://username@mongo_server_ip:27017"

      Die Shell wird Sie automatisch dazu auffordern, das Passwort des Benutzers einzugeben.

      Damit haben Sie bestätigt, dass Ihr MongoDB-Server Verbindungen vom vertrauenswürdigen Server akzeptieren kann.

      Zusammenfassung

      Sie können nun von einem Remoteserver auf Ihre MongoDB-Installation zugreifen. Jetzt können Sie Ihre Mongo-Datenbank von dem vertrauenswürdigen Server aus der Ferne verwalten. Alternativ können Sie eine Anwendung so konfigurieren, dass sie auf dem vertrauenswürdigen Server ausgeführt wird und die Datenbank aus der Ferne verwendet.

      Wenn Sie keinen administrativen Benutzer konfiguriert und die Authentifizierung nicht aktiviert haben, kann jeder, der Zugriff auf Ihren Remoteserver hat, auch auf Ihre MongoDB-Installation zugreifen. Sollten Sie es bisher nicht getan haben, empfehlen wir Ihnen dringend, unserem Leitfaden Sichern von MongoDB unter Ubuntu 20.04 zu folgen, und für eine erhöhte Absicherung einen administrativen Benutzer hinzuzufügen.



      Source link

      Installieren und Konfigurieren von Postfix als Send-Only-SMTP-Server unter Ubuntu 20.04


      Der Autor wählte den Free and Open Source Fund, um eine Spende im Rahmen des Programms Write for DOnations zu erhalten.

      Einführung

      Postfix ist ein Mail Transfer Agent (MTA), eine Anwendung zum Senden und Empfangen von E-Mail. Er kann so konfiguriert werden, dass er sich nur zum Senden von E-Mails durch lokale Anwendungen verwenden lässt. Das ist in Fällen nützlich, in denen Sie regelmäßig E-Mail-Benachrichtigungen von Ihren Anwendungen senden oder über viel ausgehenden Datenverkehr verfügen, den E-Mail-Drittanbieter nicht zulassen. Außerdem handelt es sich dabei um eine schlankere Alternative zur Ausführung eines kompletten SMTP-Servers, die dennoch die erforderliche Funktionalität bietet.

      In diesem Tutorial installieren und konfigurieren Sie Postfix als Send-Only-SMTP-Server. Außerdem werden Sie für Ihre Domäne kostenlose TLS-Zertifikate von Let’s Encrypt anfordern und ausgehende E-Mails damit verschlüsseln.

      Voraussetzungen

      • Ein Ubuntu 20.04-Server, der gemäß Ersteinrichtung eines Servers unter Ubuntu 20.04 eingerichtet wurde, einschließlich eines non-root user mit sudo-Berechtigungen.
      • Einen vollständig registrierten Domänennamen. Dieses Tutorial verwendet in allen Bereichen your_domain. Sie können einen Domänennamen unter Namecheap günstig erwerben oder einen kostenlosen von Freenom herunterladen,. oder einfach die Domänenregistrierngsstelle Ihrer Wahl verwenden.
      • Ein A-DNS-Eintrag mit your-domain, der auf die öffentliche IP-Adresse Ihres Servers verweist. Sie finden in dieser Einführung in DigitalOcean DNS Details dazu, wie Sie sie hinzufügen können.

      Anmerkung: Der Hostname Ihres Servers und der Name Ihres Droplets müssen your_domain entsprechen, da DigitalOcean anhand des Namens automatisch PTR-Einträge für die IP-Adresse des Droplets festlegt.

      Sie können den Hostnamen des Servers überprüfen, indem Sie hostname in der Eingabeaufforderung eingeben. Die Ausgabe sollte mit dem Namen übereinstimmen, den Sie dem Droplet bei der Erstellung gegeben haben.

      Schritt 1 — Installieren von Postfix

      In diesem Schritt installieren Sie Postfix. Die schnellste Methode besteht aus der Installation des Pakets mailutils, in dem Postfix mit einigen zusätzlichen Programmen gebündelt ist, die Sie zum Testversand von E-Mails verwenden werden.

      Aktualisieren Sie zuerst die Paketdatenbank:

      Installieren Sie dann Postfix, indem Sie den folgenden Befehl ausführen:

      • sudo apt install mailutils

      Kurz vor Ende der Installation wird Ihnen das Postfix-Konfigurationsfenster angezeigt:

      Wählen Sie „Internet Site“ (Internetsite) aus dem Menü; drücken Sie zum Auswählen TAB<Ok>und dann ENTER.

      Die Standardoption lautet Internet Site (Internetseite). Das ist die empfohlene Option für Ihren Anwendungsfall. Drücken Sie also TAB und dann ENTER. Wenn Sie nur den Beschreibungstext sehen, drücken Sie TAB, um OK zu wählen, und dann ENTER.

      Wenn die Anzeige nicht automatisch erfolgt, führen Sie zum Starten den folgenden Befehl aus:

      • sudo dpkg-reconfigure postfix

      Danach erhalten Sie eine weitere Konfigurationsaufforderung in Bezug auf den System-E-Mail-Namen:

      Geben Sie Ihren Domänenamen ein und drücken Sie zum Auswählen TAB sowie<Ok>ENTER.

      Der System-E-Mail-Name muss gleich sein wie der Name, den Sie bei der Erstellung Ihres Servers zugewiesen haben. Wenn Sie damit fertig sind, drücken Sie TAB, gefolgt von ENTER.

      Sie haben Postfix jetzt installiert und können mit der Konfiguration beginnen.

      Schritt 2 — Konfigurieren von Postfix

      In diesem Schritt konfigurieren Sie Postfix so, dass E-Mails nur von dem Server gesendet und empfangen werden, auf dem Postfix ausgeführt wird – d. h. von localhost.

      Dazu muss Postfix so konfiguriert werden, dass nur an der Loopback-Schnittstelle gelauscht wird; das ist die virtuelle Netzwerkschnittstelle, die der Server zur internen Kommunikation verwendet. Um die Änderungen vorzunehmen, müssen Sie die Hauptkonfigurationsdatei von Postfix namens main.cf bearbeiten, die unter etc/postfix gespeichert ist.

      Öffnen Sie sie zum Bearbeiten in Ihrem bevorzugten Texteditor:

      • sudo nano /etc/postfix/main.cf

      Suchen Sie nach den folgenden Zeilen:

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = all
      . . .
      

      Setzen Sie den Wert von inet_interfaces auf loopback-only:

      /etc/postfix/main.cf

      . . .
      mailbox_size_limit = 0
      recipient_delimiter = +
      inet_interfaces = loopback-only
      . . .
      

      Eine weitere Anweisung, die Sie ändern müssen, ist mydestination; sie gibt die Liste der Domänen an, die über den Mail Delivery Transport local_transport bereitgestellt werden. Standardmäßig sehen die Werte etwa wie folgt aus:

      /etc/postfix/main.cf

      . . .
      mydestination = $myhostname, your_domain, localhost.com, , localhost
      . . .
      

      Ändern Sie die Zeile, damit sie wie folgt aussieht:

      /etc/postfix/main.cf

      . . .
      mydestination = localhost.$mydomain, localhost, $myhostname
      . . .
      

      Wenn Ihre Domäne in Wahrheit eine Subdomäne ist und Sie möchten, dass E-Mail-Nachrichten aussehen, als wären sie von der Hauptdomäne gesendet worden, können Sie am Ende von main.cf die folgende Zeile hinzufügen:

      /etc/postfix/main.cf

      ...
      masquerade_domains = your_main_domain
      

      Die optionale Einstellung masquerade_domains gibt an, bei welchen Domänen der Subdomänenteil in der E-Mail-Adresse entfernt wird.

      Wenn Sie fertig sind, speichern und schließen Sie die Datei.

      Anmerkung: Wenn Sie mehrere Domänen auf einem Server hosten, können die anderen Domänen mit der Anweisung mydestination ebenfalls an Postfix übergeben werden.

      Starten Sie dann Postfix neu, indem Sie den folgenden Befehl ausführen:

      • sudo systemctl restart postfix

      Sie haben Postfix so konfiguriert, dass von Ihrem Server nur E-Mails gesendet werden. Sie werden dies nun testen, indem Sie eine Beispielnachricht an eine E-Mail-Adresse senden.

      Schritt 3 — Testen des SMTP-Servers

      Im diesem Schritt testen Sie, ob Postfix E-Mails mit dem Befehl mail an ein externes E-Mail-Konto senden kann. Dieser Befehl ist Teil des Pakets mailutils, das Sie im ersten Schritt installiert haben.

      Um eine Test-E-Mail zu senden, führen Sie den folgenden Befehl aus:

      • echo "This is the body of the email" | mail -s "This is the subject line" your_email_address

      Sie können den Text und den Betreff der E-Mail nach Ihren Wünschen ändern. Denken Sie daran, your_email_address durch eine gültige E-Mail-Adresse zu ersetzen, auf die Sie zugreifen können.

      Überprüfen Sie nun die E-Mail-Adresse, an die Sie diese Nachricht gesendet haben. Sie sollten die Nachricht in Ihrem Posteingang sehen. Wenn Sie sie dort nicht finden können, sehen Sie in Ihrem Spam-Ordner nach. Bislang sind alle von Ihnen gesendeten E-Mails unverschlüsselt, weswegen Dienstanbieter denken, dass es wahrscheinlich Spam-Nachrichten sind. Im Schritt 5 richten Sie die Verschlüsselung ein.

      Wenn Sie einen Fehler vom Befehl mail erhalten oder auch nach längerer Zeit keine Nachricht empfangen haben, dann vergewissern Sie sich, dass die von Ihnen bearbeitete Postfix-Konfiguration gültig ist und der Name sowie Hostname Ihres Servers auf Ihre Domäne festgelegt sind.

      Achten Sie darauf, dass bei dieser Konfiguration die Adresse im Feld From für die von Ihnen gesendeten Test-E-Mails in Format your_user_name@your_domain vorliegt, wobei your_user_name der Benutzername des Serverbenutzers ist, als der Sie den Befehl ausgeführt haben.

      Sie haben nun eine E-Mail von Ihrem Server gesendet und überprüft, ob sie erfolgreich empfangen wurde. Im nächsten Schritt richten Sie die E-Mail-Weiterleitung für root ein.

      Schritt 4 — Weiterleitung von System-E-Mail

      Im diesem Schritt richten Sie eine E-Mail-Weiterleitung für den Benutzer root ein, damit systemgenerierte Nachrichten, die auf Ihrem Server an ihn gesendet werden, an eine externe E-Mail-Adresse weitergeleitet werden.

      Die Datei /etc/aliases enthält eine Liste von alternativen Namen für E-Mail-Empfänger. Öffnen Sie sie zum Bearbeiten:

      Im Standardzustand sieht sie wie folgt aus:

      /etc/aliases

      # See man 5 aliases for format
      postmaster:    root
      

      Die einzige vorhandene Anweisung gibt an, dass systemgenerierte E-Mails an root gesendet werden.

      Fügen Sie am Ende der Datei die folgende Zeile hinzu:

      /etc/aliases

      ...
      root:          your_email_address
      

      Mit dieser Zeile geben Sie an, dass an root gesendete E-Mails an eine E-Mail-Adresse weitergeleitet werden. Denken Sie daran, your_email_address durch Ihre persönliche E-Mail-Adresse zu ersetzen. Wenn Sie fertig sind, speichern und schließen Sie die Datei.

      Um die Änderung anzuwenden, führen Sie den folgenden Befehl aus:

      Durch Ausführung von newaliases wird eine Datenbank mit Aliassen erstellt, die der Befehl mail verwendet. Die Aliasse werden aus der Konfigurationsdatei übernommen, die Sie gerade bearbeitet haben.

      Testen Sie, ob E-Mails an root gesendet werden, indem Sie Folgendes ausführen:

      • echo "This is the body of the email" | mail -s "This is the subject line" root

      Sie sollten die E-Mail unter Ihrer E-Mail-Adresse erhalten. Wenn Sie sie dort nicht finden können, sehen Sie in Ihrem Spam-Ordner nach.

      In diesem Schritt haben Sie eine Weiterleitung systemgenerierter Nachrichten an Ihre E-Mail-Adresse eingerichtet. Sie aktivieren jetzt die Nachrichtenverschlüsselung, damit alle E-Mails, die Ihr Server versendet, sicher vor Manipulation bei der Übertragung sind und als legitimer betrachtet werden.

      Schritt 5 — Aktivieren von SMTP-Verschlüsselung

      Sie aktivieren jetzt SMTP-Verschlüsselung, indem Sie für Ihre Domäne ein kostenloses TLS-Zertifikat von Let’s Encrypt anfordern (mit Certbot) und Postfix so konfigurieren, dass das Zertifikat zum Senden von Nachrichten verwendet wird.

      Ubuntu enthält Certbot in seinen standardmäßigen Paket-Repositorys, sodass Sie für dessen Installation den folgenden Befehl ausführen können:

      Wenn Sie zur Bestätigung aufgefordert werden, geben Sie J ein und drücken Sie die Eingabetaste.

      Im Rahmen der Ersteinrichtung des Servers in den Voraussetzungen haben Sie ufw, die unkomplizierte Firewall, installiert. Sie müssen sie so konfigurieren, dass der HTTP-Port 80 zugelassen wird, damit die Verifizierung der Domäne abgeschlossen werden kann. Führen Sie den folgenden Befehl aus, um ihn zu aktivieren:

      Die Ausgabe sieht in etwa folgendermaßen aus:

      Output

      Rule added Rule added (v6)

      Nachdem der Port nun geöffnet ist, führen Sie Certbot aus, um ein Zertifikat zu erhalten:

      • sudo certbot certonly --standalone --rsa-key-size 4096 --agree-tos --preferred-challenges http -d your_domain

      Dieser Befehl weist Certbot dazu an, Zertifikate mit einer RSA-Schlüsselgröße von 4096 Bits auszugeben, einen temporären Standalone-Webserver (--standalone) zur Verifizierung auszuführen und die Prüfung über Port 80 (--preferred-challenges http) vorzunehmen. Denken Sie daran, your_domain durch Ihre Domäne zu ersetzen, bevor Sie den Befehl ausführen, und geben Sie bei Aufforderung Ihre E-Mail-Adresse ein.

      Die Ausgabe sieht ungefähr wie folgt aus:

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator standalone, Installer None Obtaining a new certificate Performing the following challenges: http-01 challenge for `your_domain` Waiting for verification... Cleaning up challenges IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/your_domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/your_domain/privkey.pem Your cert will expire on 2020-07-11. To obtain a new or tweaked version of this certificate in the future, simply run certbot again. To non-interactively renew *all* of your certificates, run "certbot renew" - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      Wie in den Anmerkungen erwähnt, wurden Ihr Zertifikat und Ihre private Schlüsseldatei unter /etc/letsencrypt/live/your_domain gespeichert.

      Nachdem Sie über das Zertifikat verfügen, öffnen Sie nun main.cf zum Bearbeiten:

      • sudo nano /etc/postfix/main.cf

      Suchen Sie nach dem folgenden Abschnitt:

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
      smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Ändern Sie ihn, damit er wie folgt aussieht, wobei Sie your_domain ggf. durch Ihre Domäne ersetzen. Dadurch werden Ihre TLS-Einstellungen für Postfix aktualisiert:

      /etc/postfix/main.cf

      # TLS parameters
      smtpd_tls_cert_file=/etc/letsencrypt/live/your_domain/fullchain.pem
      smtpd_tls_key_file=/etc/letsencrypt/live/your_domain/privkey.pem
      smtpd_tls_security_level=may
      
      smtp_tls_CApath=/etc/ssl/certs
      smtp_tls_security_level=may
      smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
      

      Wenn Sie damit fertig sind, speichern und schließen Sie die Datei.

      Wenden Sie die Änderungen durch Neustart von Postfix an:

      • sudo systemctl restart postfix

      Versuchen Sie nun, erneut eine E-Mail zu senden:

      • echo "This is the body of an encrypted email" | mail -s "This is the subject line" your_email_address

      Überprüfen Sie dann die von Ihnen angegebene E-Mail-Adresse. Es ist möglich, dass Sie die Nachricht sofort in Ihrem Posteingang sehen, da E-Mail-Anbieter verschlüsselte Nachrichten deutlich seltener als Spam markieren.

      Sie können die technischen Informationen über die E-Mail-Nachricht in Ihrem Client prüfen, um zu sehen, ob die Nachricht tatsächlich verschlüsselt wurde.

      Zusammenfassung

      Sie verfügen nun über einen Send-Only-E-Mail-Server, der von Postfix bereitgestellt wird. Das Verschlüsseln aller ausgehenden Nachrichten ist ein guter erster Schritt, damit E-Mail-Anbieter Ihre Nachrichten nicht von vornherein als Spam markieren. Wenn Sie das in einem Entwicklungsszenario tun, sollte diese Maßnahme ausreichen.

      Wenn Ihr Anwendungsfall jedoch darin besteht, E-Mails an potenzielle Websitebenutzer zu senden (wie Bestätigungs-E-Mails für die Anmeldung bei einem Nachrichtenforum), sollten Sie sich mit der Einrichtung von SPF-Einträgen befassen, damit E-Mails Ihres Servers mit noch höherer Wahrscheinlichkeit als legitim gelten.



      Source link