Google Authenticator für mein VPS-Server

[francy_space]

Hallo,

ich versuche mit vier Schichten mein VPS-Server (Ubuntu 20.04) vor Hackerangriffen zu schützen, indem ich:

1. ... mich NUR mit einem Schlüssel (Puttygenerator) und OHNE den Passwort des Cloudproviders anmelden kann

2. ... die Passwortfunktion komplett abschalte und sich niemand mit dem Passwort des Cloudproviders anmelden kann

3. ... den SSH-Port ändere

4. ... eine Zwei-Faktor-Authentifizierung mit Google einrichte

Ich weiß, dass diese Maßnahmen alleine nicht ausreichend sind, aber sie sind Grundlage für einen sicheren VPS-Server.

Nun zur meiner Frage: Die ersten drei Punkte konnte ich bisher problemlos realisieren. Ich habe auch dazu eine Anleitung geschrieben. Nur im vierten Schritt mit der 2-Faktor-Authentifizierung scheitere ich immer. Sprich: Ich kann mich NICHT mit dem von Google bereitgestellten Code einloggen.

Ich möchte die einzelnen Schritte hier teilen. Vielleicht findet hier jemand den Bug:


- Logge dich via Putty in deinen VPS-Server ein

- Schaue nach, ob ein sshd-Dienst im Hintergrund läuft, der auf eine Verbindung wartet

• ps ax|grep ssh

Mit Schlüssel ohne Passwort auf dem Server anmelden

- Öffne Puttygen (Puttygenerator)-Programm

- Generiere einen Code.

- Kopiere den gesamten Key.

- Füge den Code in authorized_keys ein und speichern:

• sudo nano .ssh/authorized_keys

- Speichere den Public und Private Key des Generators auf deinem Desktop ab.

- Öffne PAGEANT. Add key → privkey.

- Öffne ein neues Putty-Fenster und deinen Server. Du wirst keinen Passwort mehr benötigen.

Passwortfunktion komplett abschalten. Key reicht vollkommen.

- Öffne deinen Server

• nano /etc/ssh/sshd_config

1.) "PasswordAuthentication" auf no stellen

2.) Kommentiere den Eintrag "PermitRootLogin yes" aus

3.) Startet den SSH-Client mit "service sshd restart" neu

4.) Schließe dein Putty-Programm und deinen Server und öffne ihn erneut. Nun wirst du ohne einen hinterlegten Key im Pageant zwar nach einem Passwort gefragt, aber dieser wird nicht angenommen. Sprich, dein Password vom Cloud-Anbieter ist nicht mehr gültig.


SSH-Port ändern

• nano /etc/ssh/sshd_config

1. Dokumentiere den Standardport 22 aus.
   
2. Schreibe drunter „Port 1024“ oder beliebige Zahl
   
3. Speichern und mit „service sshd restart“ neu starten
   
4. Vergesse nicht auf der Cloud-Firewall den Port davor nach außen hin zu öffnen

Zwei-Faktor-Authentifizierung

• apt-cache search google-authenticator
  
• apt-get install libpam-google-authenticator

• nano /etc/ssh/sshd_config

1. ChallengeResponseAuthentication yes
   
2. UsePAM yes
   
3. Händisch hinzufügen: AuthenticationMethods publickey,keyboard-interactive
   
4. speichern

• nano /etc/pam.d/sshd

1. neue Zeile:
   
   # Google Authenticator
   
   auth required pam_google_authenticator.so
   
2. Speichern und mit „service sshd restart“ neu starten

• google-authenticator

1. Nehme einen zeitbasierten Token
   
2. Es erscheint ein QR-Code
   
3. Öffne die App „Google Authenticator“. Klicke auf das Plussymbol. Scanne den QR-Code ein.
   
4. Schreibe die Notfall-Codes auf.
   

• nano /etc/pam.d/sshd

1. Kommentiere „include common auth“ aus.
   
2. Speichern und mit „service sshd restart“ neu starten.

 

[madmax2010]

Nur im vierten Schritt mit der 2-Faktor-Authentifizierung scheitere ich immer. Sprich: Ich kann mich NICHT mit dem von Google bereitgestellten Code einloggen.

logs?

Wie dem auch sei:

2 faktor authentifizierung hilft nur bedingt einen server gegen angriffe zu schuetzen.
Das hilft, wenn jemand deinen Private key und / oder dein Passwort hat.

Das ist schonmal das wichtigste:"

1.) "PasswordAuthentication" auf no stellen

2.) Kommentiere den Eintrag "PermitRootLogin yes" aus

Weitere gute methoden sind port knocking und fail2ban

wie immer bei aenderungen an der ssh config, bitte mehrere Sessions auf haben, so dass du noch eine lifeline hast, wenn was schief geht


Was mehr sicherheit angeht, empfiehlt es sich auch KEIN Putty zu benutzen.. Das ist ein laufendes Sicherheitsrisiko.

 

[francy_space]

Vielen Dank. Ich werde die Sicherheitsfunktionen in den nächsten Tagen mit Port Knocking und fail2ban erweitern.

Eine Frage vorweg: Welchen Key-Generator empfiehlst du? Und besonders welchen Typ? Bei RSA etc. sollen ja NSA und so verwickelt sein...

 

[0x8100]

google-authenticator

hast du das auch mit dem user ausgeführt, mit dem du dich später einloggen willst? deine anleitung suggeriert, dass du es nur als root gemacht hast.

das google authenticator pam modul hat übrigens den vorteil, dass es ein eingebautes rate-limiting hat. selbst ohne fail2ban wird ein angreifer schon mal gut ausgebremst. fail2ban ist natürlich trotzdem dringend zu empfehlen.

 

[snaxilian]

Sprich, dein Password vom Cloud-Anbieter ist nicht mehr gültig.

Nein, diese Aussage ist so schlicht falsch.
Das Password ist weiterhin korrekt, lediglich die Anmeldung per SSH mit Kennwort ist deaktiviert. Du hast ja in der SSHD Config PasswordAuthentication auf NO gesetzt. Lokal an der VM, z.B. per Konsole, kann man sich weiterhin mit dem Kennwort anmelden.

Ich vermisse in der Anleitung den Teil wo man die google-authenticator Config speichert...

Der Aufwand mit TOTP ist zwar nett aber du könntest bei der Erzeugung des SSH Schlüsselpaares ein ausreichend langes Kennwort auf den private key setzen. Dann hast du ebenfalls 2FA. Den privaten Schlüssel und das Kennwort zum verwenden des privaten Schlüssels.
Ja, TOTP ist nochmal ne Ecke sicherer weil eben diese nur kurze Zeit gültig sind.

Welchen Key-Generator empfiehlst du?

Ganz normal ssh-keygen unter Linux.

Und besonders welchen Typ? Bei RSA etc. sollen ja NSA und so verwickelt sein...

RSA und ECDSA basieren auf Standards und Empfehlungen des NIST, daher kommt die Vermutung/Theorie der Richtung NSA. Daher ed25519 meiner Meinung nach.
Schöner Vergleich: https://nbeguier.medium.com/a-real-world-comparison-of-the-ssh-key-algorithms-b26b0b31bfd9

fail2ban wurde ja schon gesagt. Ansonsten kommt es natürlich bei solchen Maßnahmen darauf an, wovor bzw. vor wem du dich schützen willst.
Gemäß deiner Beschreibungen hast du ein fertiges Image vom VPS Hoster genommen. In der Regel wird damit cloud-init verwendet und der Hoster bietet "recovery" Funktionalitäten an, hat also theoretisch Zugriff. Aber gut, selbst mit eigenem Installationsmedium und Full Disk Encryption könnte ein böser Hoster die Keys dazu aus dem RAM auslesen. Dagegen gibt's auch Mitigations und das kann man immer weiter spinnen.

Bleiben wir also beim Szenario "Angreifer aus dem Internet".

SSH abzusichern ist sinnvoll aber vermutlich sollen auf dem Server noch andere öffentlich erreichbare Dienste laufen, hast du auch daran gedacht diese zu härten?