Also zuerst würde ich mal ganz normal mit Benutzername/Passwort die Authentifizierung versuchen. Das macht jeder SSH Daemon per Default ohne irgendetwas einstellen zu müssen. Die Fehlermeldung deutet darauf hin, dass sich Client- und Host nicht verstehen. In der Regel muss da nichts konfiguriert werden. Ausnahmen gibt es, wenn es sich um einen sehr alten Client und aktuellen Host handelt. Dann unterstützt der Host aus Sicherheitsgründen gewisse alte Ciphers (Key Algorithms) nicht mehr und dann muss man den jeweiligen Algorithmus in der sshd_config manuell freischalten. Aber das ist nur sehr selten der Fall - vor allem im Zusammenhang mit irgendwelchen (älteren) Windows-Tools die auf SSH zugreifen.
Standardmässig ist PermitRootLogin no in der sshd_config gesetzt. Das heisst, root darf sich NICHT einloggen. Wenn Sie keine Benutzer mit SSH Loginrechten konfiguriert haben und das intern schon getestet wurde und funktioniert, dann würde ich mal zum test PermitRootLogin yes setzen und den Daemon mit systemctl restart ssh neu starten.
Achtung! Unbedingt im Produktivsystem wieder auf “no” setzen. Sicherheitskritisch!
Dann mal versuchen, ob es normal mit Passwort AUTH geht. Hierzu braucht es eigentlich nur diese Parameter in der sshd_config:
Port 2222 #Port nach Wahl
AllowUsers root #Weitere Benutzer mit Leerschlag hinzufügen
PasswordAuthentication yes
UsePAM yes
PermitRootLogin yes
Die restlichen Einstellungen passen eigentlich immer und müssen nicht geändert werden. Damit sollten Sie sich am Rechner auf Port 2222 z.B. so anmelden können:
ssh root@domain-oder-ip-des-rechners -p2222
Wenn das klappt, kann man die Verbindung absichern. Als erstes würde man hierfür die Zertfikate erstellen. Sichere und kompatible Zertifikate sind noch immer RSA mit 4096bit. Klar, es gibt heute noch bessere ECDSA aber in der Praxis machen die teilweise noch Probleme mit Clients.
Also auf dem Rechner, auf den Sie sich einwählen wollen (Host), loggen sie sich mit dem Benutzer ein, mit dem Sie via SSH zugreifen möchten. Zum Beispiel “root” und wechseln Sie ins ~/.ssh/ Verzeichnis mit cd ~/.ssh
Wenn es dieses directory nicht gibt, müssen Sie es mit mkdir -p ~/.ssh erstellen. In der Regel ist das aber schon da.
Dann erstellen Sie die Zertifikate mittels:
ssh-keygen -t rsa -b 4096
Einstellen müssen Sie nichts, einfach einige Male ENTER drücken. Wenn Sie noch mehr Sicherheit wünschen, können Sie die Zertifikate mit einem Passwortschutz versehen. Macht aber alles komplexer. Ich würd’s nicht machen und den privaten Schlüssel sicher aufbewahren.
Dies erzeugt 2 Dateien im ~/.ssh DIR:
1. id_rsa
2. id_rsa.pub
Das erste ist der private, das zweite der öffentliche Schlüssel.
Prüfen Sie, ob bereits eine ~/.ssh/authorized_keys Datei vorhanden ist. Wenn ja, müssen Sie den Inhalt von id_rsa.pub in diese Datei kopieren. Zum Beispiel so:
cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
Aber Sie können das natürlich auch mit einem Editor kopieren/einfügen. Wenn es noch keine authorized_keys Datei gibt, können Sie die Datei id_rsa.pub einfach in authorized_keys umbenennen:
mv id_rsa.pub authorized_keys
Setzen Sie die Permissions (zwingend erforderlich, sonst funktioniert es nicht):
chmod 600 ~/.ssh -R
Standardmässig sucht der SSHd die Datei ~/.ssh/authorized_keys. Es kann aber sein, dass das bei Ihrer Linuxversion nicht so ist. Dann müssten Sie den Pfad zu dieser Datei in der sshd_config setzen. Beispiel:
AuthorizedKeysFile /root/.ssh/authorized_keys
Die folgenden beiden Einstellungen sollten ebenfalls noch gesetzt werden:
PubkeyAuthentication yes
PubkeyAcceptedKeyTypes=+ssh-rsa
Das wär’s soweit auf der Host-Seite. Der Daemons muss nicht neu gestartet werden, weil der Daemon bei jeder Verbindung die Datei aufsucht. Aber wer auf nummer sicher gehen möchte, startet den SSHd neu mit systemctl restart ssh (auf einigen System systemctl restart sshd)
Die Datei 1. (id_rsa, der private Schlüssel) müssen Sie auf den anderen PC (Client) kopieren, mit welchem Sie auf den Host zugreifen möchten. Irgendwo, wo Sie möchten. Zum Beispiel nach ~/.ssh/myhostname-ssh-private.key
So, nun sollten Sie von Ihrem Client aus auf den Host verbinden können. Beispiel:
ssh -i ~/.ssh/myhostname-ssh-private.key xyz@abc.ch -p2222
Wenn sie das automatisieren möchten, dann können Sie später in der Datei ~/.ssh/config auf dem Client eine Konfiguration anlegen. Beispiel:
Host meinhost.tld
HostName meinhost.tld
User root
Port 2222
IdentityFile ~/.ssh/myhostname-ssh-private.key
Mit dieser Konfiguration sollten ein Login ohne Passworteingabe möglich sein. Wenn das klappt, müssen Sie nun schrittweise den SSHd absichern. Empfehlungen:
AllowUsers root #nur die Benutzer aufführen, die sich via SSH anmelden können sollten
PermitRootLogin prohibit-password #root kann nicht mehr mit Passwort anmelden
PermitEmptyPasswords no #schmeisst viele bots raus
StrictModes yes #stellt sicher, dass alle Rechte OK sind ehe Zugriff erlaubt wird
PasswordAuthentication no #deaktiviert Benutzername/Passwort AUTH komplett (braucht’s nicht wenn man mit Zertifikaten arbeitet)
LoginGraceTime 30
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 3
AddressFamily inet #nur IPv4
Weiter sollte dann SSH noch mittels GeoIP abgesperrt werden. Hierzu noch einmal die Referenz auf unseren Blog.
Das wären mal die Basics. Damit sollte es funktionieren und sicher sein. Ich drücke die Daumen! 😉
