Grundsatz und Installation #
SSH - Keys dienen der einfacheren und schnelleren Authentifizierung auf Servern. Gleichzeitig sichern diese das System zusätzlich. Zunächst hat man die Wahl zwischen openssh und dropbear. Dropbear ist Ressourcenschonender, dafür bietet aber openssh die Möglichkeit per SFTP auf den Server zuzugreifen.
Die Installation erfolgt bei Apt-Distros über:
sudo apt install opensshoder
sudo apt install dropbearparallel beides lässt sich nicht gleichzeitig einsetzen.
Zugang von Extern #
Prinzipell benötigt man für den SSH - Zugriff die Programme auf beiden Seiten (Server und Client).
Standardmäßig wird dies über folgende Schreibweise erreicht:
Wichtig:ssh user@domainipHier zwei Beispiele:
ssh root@192.168.1.1
ssh user1@domain.comDanach erfolgt eine Passwortabfrage. Dieses Passwort sollte sicher gewählt sein und mindestens 12 Zeichen lang. Keine Wörter und am besten noch mit Sonderzeichen versehen.
Da man sich solche Passwörter aber kaum merken kann, empfiehlt sich ein Passwortmanager wie Bitwarden oder KeePass.
SFTP - Zugriff mit openssh #
Der Zugriff per SFTP ist denkbar einfach und gleicht den Protokollen WebDav, SMB (Samba) sowie FTP. Ein Dateimanager, welcher diese Protokolle beherrscht, sollte in der Lage sein mit dieser Zugangssyntax umzugehen:
sftp://user1@domain.comSSH-Schlüssel - Praktisch und Sicher #
Eine weitere Lösung wäre der Schlüsselaustausch durch SSH-Keys, dabei werden Schlüsselpaare ausgetauscht, was zum einen den Anmeldevorgang verkürzt, da das Passwort obsolet ist und zum Anderen erhöht sich die Sicherheit, da ein Schlüssel aus wesentlich mehr Zeichen besteht als ein Passwort. Auf dem Client-Rechner starten wir folgenden Befehl:
ssh-keygenNun wird ein Schlüsselpaar eigens für diesen Client erstellt. Um diesen Schlüssel dann mit unseren Server(n) abzugleichen, genügt folgender Befehl:
ssh-copy-id user@domainipEs erfolgt aus Sicherheitsgründen eine letztmalige Abfrage des Passworts und nach Eingabe des Passworts folgt eine Bestätigung des kopierten Schlüssels. Nun hat unser Client ein passendes Schlüsselpaar zum Server und darf sich ohne Passwortabfrage damit verbinden.
Neue Installation, gleicher Server? #
Es mag vorkommen, dass sich die Dinge ändern, ein neuer Client hier, aber auch das aufsetzen des Servers ist kein seltener Zustand. Sollte allerdings die IP oder die Domain gleich geblieben sein, kommt es zu einem Authentifizierungsfehler. SSH versucht Passwort oder SSH-Key mit einem Server auszutauschen der geänderte Zustände und auch andere Schlüssel verwendet. Um hier vor Betrug abgesichert zu sein muss also zunächt der bisherige Schlüssel aus den “(SSH-) bekannten Servern” entfernt werden. Dazu ruft man folgende Datei mit einem Editor auf seinem Clientrechner auf (dies sollte vom Nutzerverzeichnis aus geöffnet werden /home/user)
nano .ssh/known_hostsIn dem neu geöffnetem Dokument findet sich eine Struktur aus domainip + Schlüssel (häufig auch mehr als nur eine Zeile) Die Zeilen des betroffenen Servers können mit STRG+K entfernt werden. Danach ist die erneute Einwahl per SSH oder SSH-Key wieder möglich und man folgt einfach dieser Anleitung erneut.
SSH - Härtung (Hardening) #
Hier gibt es viele “Glaubenssätze” und auch Mythen was wirklich hilft, sinnvoll ist, oder fast schon an paranoide Angstzustände erinnern kann, sei jedem selbst überlassen. Fest steht nur, je mehr Härtung umso schwieriger wird auch der eigene Zugriff auf den Server. Hier einige sinnvolle Änderungsvorschläge für die bessere Absicherung von SSH. Alle Änderungen werden in folgender Datei vorgenommen:
sudo nano /etc/ssh/sshd_configIdR. muss man lediglich die Raute # vor dem jeweiligen Eintrag entfernen oder gar die Variablen von yes zu no umstellen.
Nicht Port 22 nutzen (evtl. unsinnig) #
Da ssh bekanntlich Standardmäßig auf Port 22 läuft, ist dieser auch leichter auffindbar und somit ein schnell gefundenes Ziel für Angreifer (wichtig wäre es :
Port 3334 Zu beachten ist aber, dass nun bei jeder Anmeldung der spezielle Port mit angegeben werden muss:
ssh user1@domainip -p 3334Wichtig: Dem dahinter liegenden Router muss eine spezielle Portfreigabe gewährt werden auf diesen Port, die 22 ist Standardmäßig frei aber selbstgewählte Ports müssen extra gesetzt werden. Zu beachten gilt außerdem, sollten sich mehrere Server innerhalb eines Netzwerks befinden ist es nicht möglich immer den selben eigenen Port zu wählen dem Beispiel folgend wäre die 3334 für Server A belegt. Server B würde dann einen anderen Port benötigen.
Root Login verbieten #
Die Nutzung von root sollte allg. wenig bis gar nicht vorkommen, dafür gibt es sudo, und sollte tatsächlich auch mal root genutzt werden müssen, lässt sich dies per su auch auf der Befehlszeile nach dem userlogin bewerkstelligen. Die direkte Anmeldung per root ist eine Schwachstelle die unnötig aktiv geschaltet ist.
PermitRootLogin noMaximale Anzahl an Login-Versuchen reduzieren #
Da Bots bekanntlich mit unzähligen Passworteingaben versuchen das Richtige zu generieren ist es ratsam die Maximale Anzahl an Login-Versuchen zu reduzieren. Wie oft kann man sich denn selbst vertippen in Zeiten von Passwortmanagern?
MaxAuthTries 3Outro #
Mehr ist immer möglich, diese drei Härtungen/Absicherungen sind aber essenziell und dürften es Angreifern deutlich erschweren. Ein ordentliches Passwort ist ebenfalls immer zu Empfehlen. Man kann sich auch dazu entscheiden, die Passworteingabe komplett zu deaktivieren. Hierfür ist es aber notwendig die Schlüssel sicher zu verwahren, denn ansonsten sperrt man sich selbst komplett aus seinem eigenen System aus.