![\"\"](\"https:\/\/u-labs.de\/portal\/wp-content\/uploads\/2022\/04\/grafik-22.png\")
<\/a><\/figure>\n<\/div>\nSSH auf anderen Linux-Systemen aktivieren<\/h3>\n
Mietest du einen virtuellen Server bei einem Hoster, ist SSH in der Regel bereits aktiviert. Bei selbst aufgesetzten VMs muss ggf. vorher ein SSH-Server installiert werden. Am verbreitesten ist OpenSSH. Unter Debian\/Ubuntu l\u00e4sst er sich wie folgt installieren und aktivieren:<\/p>\n
sudo apt install openssh-server\nsudo systemctl start sshd<\/code><\/pre>\nAbsichern des SSH-Servers<\/h2>\n
Die zentrale Konfigurationsdatei des OpenSSH-Servers ist \/etc\/ssh\/sshd_config<\/strong> – viele der folgenden Einstellungen werden wir darin vornehmen. Sie ist hier dokumentiert.<\/a> Du solltest die Konfigurationsdatei mit root-Rechten und einem Texteditor deiner Wahl (etwa nano oder vim) \u00f6ffnen<\/a>, um die Einstellungen zu pr\u00fcfen bzw. \u00c4nderungen vornehmen zu k\u00f6nnen.<\/p>\nViele der genannten Konfigurationseinstellungen sind bereits in der Datei enthalten, aber entweder nicht aktiviert oder sogar auskommentiert. Letzteres ist der Fall, wenn die Zeile mit einer Raute # beginnt. Hier kannst du einfach die Raute entfernen und die vorhandenen Zeilen ggf. anpassen, falls n\u00f6tig.<\/p>\n
#PermitEmptyPasswords no<\/code><\/pre>\nLeere Passw\u00f6rter verbieten<\/h3>\n
Linux erlaubt es theoretisch, Konten mit leeren Passw\u00f6rtern zu erstellen. Aus Sicherheitsgr\u00fcnden sollte man das nat\u00fcrlich nicht tun. Falls es aus irgend einem Grund dennoch geschieht, macht es Sinn, zumindest den Login per SSH damit zu verbieten. Dies erm\u00f6glicht die Einstellung PermitEmptyPasswords:<\/p>\n
PermitEmptyPasswords yes<\/code><\/pre>\nKeine direkte Anmeldung des „root“ Benutzers<\/h3>\n
Der „Administrator“ unter Linux hei\u00dft „root“ und kann sich auch per SSH anmelden. Grunds\u00e4tzlich ist es sicherheitstechnisch schlechte Praxis, sich direkt als root anzumelden. Zumal dies dazu verleitet, alle Befehle mit diesem Konto auszuf\u00fchren, auch wenn dies gar nicht immer notwendig ist. Am besten deaktiviert man den SSH-Login f\u00fcr root daher:<\/p>\n
PermitRootLogin no\n# Alternativ\nPermitRootLogin prohibit-password<\/code><\/pre>\nAber Achtung<\/strong>: In diesem Falle solltest du zuvor mindestens ein weiteres Konto erstellen, dass root-Rechte per sudo erlangen kann! Ansonsten lassen sich administrative Aufgaben nicht mehr per SSH ausf\u00fchren bzw. man sperrt sich sogar komplett aus, wenn \u00fcberhaupt kein weiteres Konto existiert. <\/p>\nFalls du den Login f\u00fcr root nicht g\u00e4nzlich deaktivieren m\u00f6chtest, kann prohibit-password<\/strong> ein Kompromiss darstellen. Dadurch ist die Anmeldung nur per SSH-Schl\u00fcssel notwendig. Dies ist \u00fcbrigens grunds\u00e4tzlich eine sinnvolle Idee, da ein privater Schl\u00fcssel schwieriger mit roher Gewalt zu knacken ist als ein Passwort. <\/p>\nWer bereits komplett auf SSH-Schl\u00fcssel setzt, kann die Anmeldung per Passwort ggf. auch komplett deaktivieren:<\/p>\n
PasswordAuthentication no<\/code><\/pre>\nMan sollte allerdings sicherstellen, dass die SSH-Schl\u00fcssel sicher aufbewahrt werden. Ansonsten besteht auch hier das Risiko, sich selbst auszusperren.<\/p>\n
SSH-Zugriff f\u00fcr bestimmte Benutzer erlauben\/verbieten<\/h3>\n
Auf einigen Systemen gibt es auch Systembenutzer, die nur auf dem selbst ben\u00f6tigt werden und sich nicht per SSH verbinden k\u00f6nnen sollen. Hierf\u00fcr gibt es AllowUsers\/DenyUsers<\/strong>. Ich w\u00fcrde grunds\u00e4tzlich Whitelisting bevorzugen, da es weniger fehleranf\u00e4llig ist. Mehrere Benutzer lassen sich mit einem Leerzeichen getrennt angeben:<\/p>\nAllowUsers daniel max<\/code><\/pre>\nHandelt es sich um eine gr\u00f6\u00dfere Anzahl Benutzer, kann man eine Gruppe verwenden und diese entsprechend mit AllowGroups\/DenyGroups<\/strong> angeben.<\/p>\nX11 Weiterleitung deaktivieren<\/h3>\n
Die X11-Weiterleitung erm\u00f6glicht es, ein grafisches Programm auf dem entfernten Server zu starten und dessen Oberfl\u00e4che (per X-Server dargestellt) auf unserem Client darzustellen. Der Server ben\u00f6tigt daf\u00fcr keine grafische Oberfl\u00e4che. Das kann praktisch sein, aber bietet theoretisch zus\u00e4tzliche Angriffsfl\u00e4che. Wer es nicht braucht, sollte es daher deaktivieren – sicherheitstechnisch ein guter Grundsatz. Unter Debian und dem Raspberry Pi OS ist es n\u00e4mlich standardm\u00e4\u00dfig aktiviert. Zur Deaktivierung setzt man folgende Eigenschaft auf no<\/strong>:<\/p>\nX11Forwarding no<\/code><\/pre>\nAlte Protokollversionen verbieten<\/h3>\n
Das SSH-Protokoll ist bereits seit etlichen Jahren in Version 2 verf\u00fcgbar, die Schwachstellen gegen\u00fcber V1 behebt. Standardm\u00e4\u00dfig wird aber auch die alte Version 1 akzeptiert. Besser ist es, explizit nur Version 2 zu erlauben:<\/p>\n
Protocol 2<\/code><\/pre>\nMaximale Authentifizierungsversuche begrenzen<\/h3>\n
\u00dcber MaxAuthTries kann angegeben werden, nach wie vielen (vergeblichen) Authentifizierungsversuchen die Verbindung getrennt wird. Unter Debian und dem Raspberry Pi OS ist diese Einstellung deaktiviert. Ein sinnvoller Wert ist z.B. 3:<\/p>\n
MaxAuthTries 5<\/code><\/pre>\nAllerdings ist dies kein Schutz vor Brute-Forcing (Roher Gewalt)<\/strong>. Erg\u00e4nzend macht es daher Sinn, Programme wie Fail2ban einzusetzen: Es \u00fcberwacht die Anzahl fehlgeschlagener Anmeldeversuche und sperrt IP-Adressen eine gewisse Zeit aus, wenn ein festgelegtes Limit erreicht ist. Entsprechend eingerichtet, wird Brute-Forcing dadurch massivst erschwert, sodass es bei einem sicheren Passwort alles andere als praxistauglich ist, damit erfolgreich anzugreifen.<\/p>\nReverse-DNS Aufl\u00f6sung abschalten<\/h3>\n
Standardm\u00e4\u00dfig pr\u00fcft SSH den Reverse-DNS Eintrag eines Clients. Das bringt in den meisten F\u00e4llen wenig – zumal typische DSL-Anschl\u00fcsse ohnehin in der Regel keinen (sinnvollen) Reverse-DNS Eintrag besitzen (wie etwa kunde19823761987283.isp.de). Auch wenn dies kein direktes Sicherheitsrisiko ist, erh\u00f6ht es theoretisch die Angriffsfl\u00e4che ohne Mehrwert. Au\u00dferdem kann die DNS-Anfrage ggf. das Anmelden verz\u00f6gern, daher w\u00fcrde ich es deaktivieren:<\/p>\n
UseDNS no<\/code><\/pre>\nTesten der \u00c4nderungen<\/h3>\n
Grunds\u00e4tzlich solltest du \u00c4nderungen am SSH-Daemon immer zuerst in einer weiteren Sitzung testen und die urspr\u00fcngliche Sitzung ge\u00f6ffnet lassen! Falls dabei Probleme festgestellt werden, kann man diese mit der noch offenen Sitzung reparieren. So verhindert man, sich bei fehlerhaften Konfigurations\u00e4nderungen selbst auszusperren.<\/p>\n
Damit diese wirksam werden, muss zun\u00e4chst der SSH-Server neu gestartet werden:<\/p>\n
sudo systemctl restart sshd<\/code><\/pre>\nDies hat keine Auswirkungen auf die Sitzung, in der man den Befehl ausf\u00fchrt. Daher sollte man diese Sitzung offen halten und zum Testen nun eine zweite \u00f6ffnen. Funktioniert alles, kann die offen gehaltene Sitzung geschlossen werden.<\/p>\n
Sollte ich den SSH-Port \u00e4ndern?<\/h2>\n
Manche Beitr\u00e4ge empfehlen, den Standardport 22 zu \u00e4ndern. Dies halte ich im Sinne der Sicherheit f\u00fcr wenig sinnvoll: Es gibt nur maximal 65.535 Ports. Mit einem Portscan sind die relativ einfach und schnell durchprobiert. Einen Angreifer hindert das eben so wenig wie eine angelehnte statt einer offenen T\u00fcr. Wesentlich mehr tr\u00e4gt man zur Sicherheit bei, wenn man die T\u00fcr schlie\u00dft und am besten verschlie\u00dft. Beim SSH-Server w\u00e4re das beispielsweise die Nutzung von starken Passw\u00f6rtern oder noch besser SSH-Schl\u00fcsseln.<\/p>\n
Gegen\u00fcber den minimalen Vorteilen bringt die \u00c4nderung der Standardports auch leichte Nachteile: Man muss den selbst gew\u00e4hlten Port bei einer Verbindung explizit angeben. Wer damit leben kann, der kann den Port nat\u00fcrlich \u00e4ndern – dar\u00fcber hinaus schadet es nicht. Aber man sollte sich im klaren sein, dass das keine wirksame Sicherheitsma\u00dfnahme ist. Wer sich um die Sicherheit seines Servers sorgt, erreicht mit wirkungsvollen Schutzma\u00dfnahmen statt dem verstecken<\/em> von Diensten mehr. Neben den bereits genannten Beispielen kann man die Sicherheit etwa durch 2-Faktor Authentifizierung zus\u00e4tzlich verbessern<\/a>. Das nutzt wesentlich mehr, da sich eine Multi-Faktor-Authentifizierung nicht so einfach mit einem Portscan umgehen<\/em> l\u00e4sst.<\/p>\nWeitere Schutzma\u00dfnahmen<\/h2>\n
An dieser Stelle sei auch noch darauf hingewiesen, dass dies nur Beispiele sind. Es gibt weitere sinnvolle Ma\u00dfnahmen, welche die Sicherheit erh\u00f6hen k\u00f6nnen. Dies betrifft nicht nur den SSH-Server. Das regelm\u00e4\u00dfige einspielen von Aktualisierungen ist beispielsweise eine Grundlage f\u00fcr sichere Systeme. Vor allem Sicherheitsaktualisierungen sollten so schnell wie m\u00f6glich eingespielt werden, am besten automatisch<\/a>. <\/p>\n„Sicherheit“ ist ein Prozess – kein Zustand, den man wie ein Projektziel erreicht und danach abhaken kann. Zumal man bei diesem Begriff nicht nur an Angriffe von au\u00dfen denken sollte. Auch z.B. Hardwaredefekte k\u00f6nnen die Sicherheit der gespeicherten Daten gef\u00e4hrden, weswegen man auch ein Backup-Konzept haben sollte. Diese Themen werden wir noch in einen Beitr\u00e4gen genauer anschauen.<\/p>\n","protected":false},"excerpt":{"rendered":"
SSH ist das Standard-Protokoll schlechthin, um Linux-Systeme zu administrieren. \u00dcber die Standardeinstellungen hinaus sollte man jedoch ein paar Sicherheitsvorkehrungen treffen – vor allem dann, wenn das System per Internet erreichbar ist. Vorbereitungen Falls noch nicht geschehen, installiere zuerst einen SSH-Server. Dies variiert etwas, je nach Plattform und Betriebssystem. SSH auf dem Raspberry Pi aktivieren Auf …<\/p>\n","protected":false},"author":5,"featured_media":8884,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[391,671,85],"tags":[56,781],"class_list":["post-8851","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux-server","category-raspberry-pi","category-sicherheit","tag-sicherheit","tag-ssh"],"_links":{"self":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8851","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/comments?post=8851"}],"version-history":[{"count":6,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8851\/revisions"}],"predecessor-version":[{"id":9867,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/posts\/8851\/revisions\/9867"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media\/8884"}],"wp:attachment":[{"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/media?parent=8851"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/categories?post=8851"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/u-labs.de\/portal\/wp-json\/wp\/v2\/tags?post=8851"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}