<<TableOfContents: execution failed „] (siehe auch das Protokoll)>>
OpenSSH (oder Secure SHell) ist zu einem De-facto-Standard für den Fernzugriff geworden und hat das Telnet-Protokoll ersetzt. SSH hat Protokolle wie Telnet überflüssig gemacht, was vor allem daran liegt, dass die Verbindung verschlüsselt ist und Passwörter nicht mehr im Klartext für alle sichtbar gesendet werden.
Allerdings ist eine Standardinstallation von ssh nicht perfekt, und beim Betrieb eines ssh-Servers gibt es ein paar einfache Schritte, die eine Installation drastisch abhärten können.
Verwenden Sie starke Passwörter/Benutzernamen
Eines der ersten Dinge, die Sie bemerken werden, wenn Sie ssh laufen lassen und der Außenwelt ausgesetzt sind, ist, dass Sie wahrscheinlich Versuche von Hackern protokollieren werden, Ihren Benutzernamen/Passwort zu erraten. Normalerweise sucht ein Hacker nach Port 22 (dem Standardport, an dem ssh abgehört wird), um Rechner zu finden, auf denen ssh läuft, und versucht dann, einen Brute-Force-Angriff darauf durchzuführen. Mit starken Passwörtern wird hoffentlich jeder Angriff protokolliert und bemerkt, bevor er erfolgreich sein kann.
Hoffentlich verwenden Sie bereits sichere Passwörter, aber wenn nicht, dann versuchen Sie, Passwörter zu wählen, die das enthalten:
- Mindestens 8 Zeichen
- Mischung aus Groß- und Kleinbuchstaben
- Mischung aus Buchstaben und Zahlen
- Nicht alphanumerische Zeichen (z. B. Sonderzeichen wie ! “ £ $ % ^ usw.)
Die Vorteile starker Passwörter sind nicht spezifisch für ssh, sondern haben Auswirkungen auf alle Aspekte der Systemsicherheit. Weitere Informationen zu Passwörtern sind in der CentOS-Dokumentation zu finden:
http://www.centos.org/docs/4/html/rhel-sg-en-4/s1-wstation-pass.html
Wenn Sie absolut nicht verhindern können, dass Ihre Benutzer schwache Passwörter wählen, dann erwägen Sie die Verwendung von zufällig generierten oder schwer zu erratenden Benutzernamen für Ihre Benutzerkonten. Wenn die Bösewichte den Benutzernamen nicht erraten können, können sie auch das Kennwort nicht erzwingen. Dies ist jedoch immer noch Sicherheit durch Unklarheit, und Sie sollten sich der Gefahr bewusst sein, dass Informationen über Benutzernamen durch Dinge wie E-Mails, die von Benutzerkonten aus gesendet werden, nach außen dringen.
Root-Logins deaktivieren
SSH-Server-Einstellungen werden in der Datei /etc/ssh/sshd_config gespeichert. Um Root-Logins zu deaktivieren, stellen Sie sicher, dass Sie den folgenden Eintrag haben:
# Prevent root logins:PermitRootLogin no
und starten Sie den sshd-Dienst neu:
service sshd restart
Wenn Sie Root-Zugriff benötigen, melden Sie sich als normaler Benutzer an und verwenden Sie den Befehl su.
Benutzeranmeldungen beschränken
SSH-Anmeldungen können auf bestimmte Benutzer beschränkt werden, die Fernzugriff benötigen. Wenn Sie viele Benutzerkonten auf dem System haben, ist es sinnvoll, den Fernzugriff nur auf diejenigen zu beschränken, die ihn wirklich benötigen, um die Auswirkungen eines gelegentlichen Benutzers mit einem schwachen Kennwort zu begrenzen. Fügen Sie eine AllowUsers-Zeile gefolgt von einer durch Leerzeichen getrennten Liste von Benutzernamen in /etc/ssh/sshd_config ein:
AllowUsers alice bob
und starten Sie den sshd-Dienst neu.
Protokoll 1 deaktivieren
SSH hat zwei Protokolle, die es verwenden kann, Protokoll 1 und Protokoll 2. Das ältere Protokoll 1 ist weniger sicher und sollte deaktiviert werden, es sei denn, Sie wissen, dass Sie es ausdrücklich benötigen. Suchen Sie die folgende Zeile in der Datei /etc/ssh/sshd_config, heben Sie die Kommentare auf und ändern Sie sie wie gezeigt:
# Protocol 2,1Protocol 2
und starten Sie den sshd-Dienst neu.
Verwenden Sie einen Nicht-Standard-Port
Standardmäßig lauscht ssh auf eingehende Verbindungen an Port 22. Wenn ein Hacker feststellen will, dass ssh auf Ihrem Rechner läuft, wird er höchstwahrscheinlich Port 22 scannen, um dies festzustellen. Eine effektive Methode besteht darin, ssh auf einem Nicht-Standard-Port laufen zu lassen. Jeder ungenutzte Port ist geeignet, obwohl ein Port über 1024 vorzuziehen ist. Viele Leute wählen 2222 als alternativen Port (da er leicht zu merken ist), so wie 8080 oft als alternativer HTTP-Port bekannt ist. Genau aus diesem Grund ist es wahrscheinlich nicht die beste Wahl, da jeder Hacker, der Port 22 scannt, wahrscheinlich auch Port 2222 scannt, nur um sicherzugehen. Es ist besser, einen zufälligen hohen Port zu wählen, der nicht für bekannte Dienste verwendet wird. Um die Änderung vorzunehmen, fügen Sie eine Zeile wie diese in Ihre /etc/ssh/sshd_config-Datei ein:
# Run ssh on a non-standard port:Port 2345 #Change me
und starten Sie den sshd-Dienst neu. Vergessen Sie nicht, anschließend alle notwendigen Änderungen an der Portweiterleitung in Ihrem Router und an den entsprechenden Firewall-Regeln vorzunehmen. Unter CentOS 7 (und höher) können Sie zum Beispiel den ssh-Dienst von firewalld ändern, indem Sie ein Duplikat der Servicedatei in /etc/firewalld/ anlegen und die Port-Zeile ändern:
$ cp /usr/lib/firewalld/services/ssh.xml /etc/firewalld/services/ssh-custom.xml
Dann ändern Sie die Port-Zeile in /etc/firewalld/services/ssh-custom.xml so, dass der Port der gleiche ist wie in der ssh-Konfigurationsdatei:
<port protocol="tcp" port="2345"/>
Letzen Endes entfernen Sie den ssh-Dienst, fügen Sie den ssh-custom-Dienst hinzu und laden Sie Firewalld neu, damit die Änderung wirksam wird:
$ firewall-cmd --permanent --remove-service='ssh'$ firewall-cmd --permanent --add-service='ssh-custom'$ firewall-cmd --reload
Oder fügen Sie unter CentOS 6 eine iptable-Regel hinzu, um den neuen ssh-Port zu öffnen:
$ iptables -I INPUT -p tcp --dport 2345 -j ACCEPT
Vergessen Sie nicht, auch den alten Port zu schließen.
Auf CentOS 6 und höher sollten Sie auch selinux aktualisieren und den gewählten Port korrekt beschriften, da sshd sonst nicht auf ihn zugreifen kann. Zum Beispiel:
$ semanage port -a -t ssh_port_t -p tcp 2345 #Change me
Da ssh nicht mehr auf dem Standardport auf Verbindungen wartet, müssen Sie Ihrem Client mitteilen, auf welchem Port er sich verbinden soll. Wenn Sie den ssh-Client über die Befehlszeile verwenden, können Sie den Port mit dem Schalter -p angeben:
$ ssh -p 2345 myserver
oder, wenn Sie das Fish-Protokoll in Konqueror verwenden, zum Beispiel:
fish://myserver:2345/remote/dir
Wenn Sie denken, dass es lästig ist, den Port jedes Mal anzugeben, wenn Sie sich verbinden, fügen Sie einfach einen Eintrag mit dem Port in Ihre lokale ~/.ssh/config-Datei ein:
# Client ~/.ssh/configHost myserverHostName 72.232.194.162 User bob Port 2345
Und die Datei: ~/.ssh/config muss die folgenden Berechtigungen haben:
$ chmod 600 ~/.ssh/config
SSSH an der Firewall filtern
Wenn Sie nur von einer IP-Adresse aus Fernzugriff benötigen (z. B. von der Arbeit aus auf Ihren Heimserver), sollten Sie in Erwägung ziehen, die Verbindungen an Ihrer Firewall zu filtern, indem Sie entweder eine Firewall-Regel auf Ihrem Router oder in iptables hinzufügen, um den Zugriff auf Port 22 auf diese bestimmte IP-Adresse zu beschränken. In iptables könnte dies beispielsweise mit der folgenden Art von Regel für iptables (CentOS 6) erreicht werden:
$ iptables -A INPUT -p tcp -s 72.232.194.162 --dport 22 -j ACCEPT
oder mit firwalld (CentOS 7) mit rich-rules, um ssh nur auf einem bestimmten Port zu erlauben. Die Quelladresse kann eine einzelne Adresse oder eine Basisadresse mit einer Bitmaske sein:
SSH unterstützt von Haus aus auch TCP-Wrapper und der Zugriff auf den ssh-Dienst kann auf ähnliche Weise mit hosts.allow und hosts.deny kontrolliert werden.
Wenn Sie nicht in der Lage sind, die Quell-IP-Adressen einzuschränken, und den ssh-Port global öffnen müssen, dann kann iptables immer noch helfen, Brute-Force-Angriffe zu verhindern, indem es wiederholte Anmeldeversuche von derselben IP-Adresse protokolliert und blockiert. Zum Beispiel mit iptables
Die erste Regel zeichnet die IP-Adresse jedes neuen Zugriffsversuchs auf Port 22 mit dem jüngsten Modul auf. Die zweite Regel prüft, ob diese IP-Adresse innerhalb der letzten 60 Sekunden 4 oder mehr Verbindungsversuche unternommen hat, und wenn nicht, wird das Paket akzeptiert. Beachten Sie, dass diese Regel eine Standardrichtlinie von DROP für die Eingabekette erfordern würde.
Vergessen Sie nicht, den Port entsprechend zu ändern, wenn Sie ssh auf einem Nicht-Standard-Port ausführen. Wenn möglich, ist die Filterung an der Firewall eine äußerst effektive Methode, um den Zugang zu einem ssh-Server zu sichern.
Für Systeme, die den FirewallD-Dienst verwenden (CentOS 7 oder höher), verwenden Sie firewall-cmd:
Der erste Befehl entfernt die freizügigere Dienstregel, der zweite setzt eine Regel ein, die nur 4 Verbindungen in einer Minute zulässt und alle Verbindungen protokolliert.
Verwendung von öffentlichen/privaten Schlüsseln für die Authentifizierung
Die Verwendung verschlüsselter Schlüssel für die Authentifizierung bietet zwei wesentliche Vorteile. Erstens ist es bequem, da Sie kein Passwort mehr eingeben müssen (es sei denn, Sie verschlüsseln Ihre Schlüssel mit einem Passwortschutz), wenn Sie öffentliche/private Schlüssel verwenden. Zweitens können Sie, sobald die Authentifizierung mit öffentlichen/privaten Schlüsselpaaren auf dem Server eingerichtet ist, die Kennwortauthentifizierung vollständig deaktivieren, was bedeutet, dass Sie ohne einen autorisierten Schlüssel keinen Zugang erhalten können – also keine Versuche mehr, ein Kennwort zu knacken.
Es ist ein relativ einfacher Prozess, ein öffentliches/privates Schlüsselpaar zu erstellen und es für die Verwendung auf Ihrem ssh-Server zu installieren.
Erstellen Sie zunächst ein öffentliches/privates Schlüsselpaar auf dem Client, den Sie für die Verbindung mit dem Server verwenden werden (Sie müssen dies von jedem Client-Rechner aus tun, von dem aus Sie sich verbinden):
$ ssh-keygen -t rsa
Wenn Sie nicht bei jeder Verbindung nach einer Passphrase (im Grunde ein Kennwort zum Entsperren eines bestimmten öffentlichen Schlüssels) gefragt werden wollen, drücken Sie einfach die Eingabetaste, wenn Sie bei der Erstellung des Schlüsselpaars nach einer Passphrase gefragt werden. Es liegt an Ihnen zu entscheiden, ob Sie die Passphrase zum Schutz der Verschlüsselung zu Ihrem Schlüssel hinzufügen, wenn Sie ihn erstellen. Wenn Sie Ihren Schlüssel nicht mit einer Passphrase schützen, hat jeder, der sich Zugang zu Ihrem lokalen Rechner verschafft, automatisch ssh-Zugriff auf den entfernten Server. Außerdem hat root auf dem lokalen Rechner Zugriff auf Ihre Schlüssel, obwohl man davon ausgeht, dass Sie in echten Schwierigkeiten stecken, wenn Sie root nicht trauen können (oder root kompromittiert ist). Die Verschlüsselung des Schlüssels bringt zusätzliche Sicherheit auf Kosten des Wegfalls der Notwendigkeit, ein Passwort für den ssh-Server einzugeben, das dann durch die Eingabe einer Passphrase für die Verwendung des Schlüssels ersetzt wird. Dies kann durch die Verwendung des Programms ssh_agent weiter vereinfacht werden
Nun setzen Sie die Berechtigungen für Ihren privaten Schlüssel:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/id_rsa
Kopieren Sie den öffentlichen Schlüssel (id_rsa.pub) auf den Server und fügen Sie ihn in die Liste authorized_keys ein:
$ cat id_rsa.pub >> ~/.ssh/authorized_keys
Hinweis: Sobald Sie den öffentlichen Schlüssel importiert haben, können Sie ihn vom Server löschen.
und setzen Sie schließlich die Dateiberechtigungen auf dem Server:
$ chmod 700 ~/.ssh$ chmod 600 ~/.ssh/authorized_keys
Die obigen Berechtigungen sind erforderlich, wenn StrictModes in /etc/ssh/sshd_config auf yes gesetzt ist (die Vorgabe).
Stellen Sie sicher, dass die richtigen SELinux-Kontexte gesetzt sind:
$ restorecon -Rv ~/.ssh
Wenn Sie sich nun am Server anmelden, werden Sie nicht nach einem Passwort gefragt (es sei denn, Sie haben bei der Erstellung Ihres Schlüsselpaares eine Passphrase eingegeben). Standardmäßig versucht ssh zunächst, sich mit Schlüsseln zu authentifizieren. Wenn keine Schlüssel gefunden werden oder die Authentifizierung fehlschlägt, greift ssh auf die herkömmliche Passwortauthentifizierung zurück.
Wenn Sie überprüft haben, dass Sie sich mit Ihrem öffentlichen/privaten Schlüsselpaar erfolgreich am Server anmelden können, können Sie die Passwortauthentifizierung vollständig deaktivieren, indem Sie die folgende Einstellung in Ihre /etc/ssh/sshd_config-Datei aufnehmen:
# Disable password authentication forcing use of keysPasswordAuthentication no
Häufig gestellte Frage (FAQ)
Q: CentOS verwendet Version X von OpenSSH und die neueste Version ist Version Y. Version X enthielt eine schwerwiegende Sicherheitslücke, sollte ich aktualisieren?
A: Nein. Der Upstream-Anbieter hat die Politik, Sicherheitspatches aus den letzten Versionen in die aktuelle Distributionsversion zurückzuportieren. Solange Sie die neuesten Updates für Ihre CentOS-Distribution installiert haben, sind Sie vollständig gepatcht. Weitere Details zur Rückportierung von Sicherheitspatches finden Sie hier:
http://www.redhat.com/advice/speaks_backport.html
Q: Wie bringe ich ssh dazu, eine passwortlose, schlüsselbasierte Authentifizierung zwischen Rechnern zu ermöglichen, die die Home-Verzeichnisse der Benutzer über NFS gemeinsam nutzen?
A: SElinux blockiert standardmäßig den Root-Zugriff auf NFS-freigegebene Verzeichnisse und Dateien, die nicht für die ganze Welt lesbar sind, so dass sshd die Schlüsseldateien der Benutzer in ~/.ssh nicht lesen kann. Um den Zugriff zu ermöglichen, ändern Sie die Einstellung von use_nfs_home_dirs, indem Sie den folgenden Befehl als Superuser ausführen:
setsebool -P use_nfs_home_dirs 1
https://www.centos.org/forums/viewtopic.php?t=49194
Links
http://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-openssh.html
http://www.dragonresearchgroup.org/insight/sshpwauth-tac.html