Grundlage für eine sichere sshd_config

Meine grundlegende Konfigurationsdatei für OpenSSH, getestet mit Version 7.2.

Ich nutze als Werkzeug für das Überprüfen der Konfigurationen von openSSH das Werkzeug  ssh-audit von Github.

Das Pythonscript ist im Gegensatz zu der Wikiseite der Mozilla Foundation, auf dem letzten Stand der Technik für die Konfigurationen. Ich überprüfe mit diesem Script die Konfiguration monatlich die Konfiguration. Neben den einschlägigen Mailinglisten ist dies für mich eine Möglichkeit um auf dem sichersten Stand zu bleiben. Einen Besuch des Projektes auf Git und das Eingliedern in die Administrationswerkzeuge empfehle ich auf jeden Fall.

Ich habe meine sshd_config auf ein Gist gelegt, von welcher sie geforkt,  heruntergeladen und/oder bearbeitet werden kann.
Bei der Konfiguration habe ich die Einträge für das Bereitstellen des Servers auf verschiedenen IP-Adressen ignoriert und somit hört der Daemon auf jede IP des Servers, welches vielleicht nicht gewünscht ist. Hier kann/muss/sollte man die Konfiguration erweitern. Ich sehe diese Konfigurationsdatei nur als Grundlage an. Natürlich kann es sein, dass die Konfiguration für manche alte Clients und Endgeräte nicht funktioniert. Ich empfehle zu Überdenken, ob man wirklich die Verbindung so weit schwächen möchte um diesen Clients Zugang zu verschaffen.

Wie man Titel entnehmen kann ist sie eine Momentaufnahmen, denn schon Morgen kann sie veraltet sein und wie ich im ersten Absatz erwähne, sie muss turnusmäßig überprüft werden. Ich schließe jede Haftung meinerseits aus und diese Konfiguration könnte zu unmöglichen Problemen führen und es ist zu empfehlen sich einmal mit einer Reperaturkonsole zu befassen.

sshd_config

[gist id=“f5321cba415e8c95552f3f86478965f6″]

Step by Step SSH

Bitte einmal komplett durchlesen und Schritte nachvollziehen.

  1. Schlüssel generieren
  2. Schlüssel auf den Server kopieren
  3. Die Konfiguration des lokalen Clients anpassen
  4. Backup der originalen Konfiguration des Daemons
  5. Herunterladen und aktivieren der neuen Konfiguration
  6. Testweise einloggen mit dem lokalen Client

1. Schlüssel generieren und auf den Server kopieren

Für den Schlüssel muss ein geeignetes Passwort gewählt werden.

ssh-keygen -b 4096 -f .ssh/SERVERNAME
ssh-copy-id -i ~/.ssh/SERVERNAME NUTZERNAME@IPADRESSE

3. Die Konfiguration des lokalen Clients anpassen um Faul sein zu dürfen

vim .ssh/config
Host SERVERNAME
HostName SERVERIP
Port 22
User NUTZERNAME
IdentityFile ~/.ssh/SERVERNAMEDESERSTENAUFRUFS von ssh-keygen

4 und 5 Backup der originalen Konfiguration des Daemons und Herunterladen und aktivieren der neuen Konfiguration

Auf dem Server mit dem laufen SSHdaemon

[cmg@got-tty:~] $ sudo -s
[cmg@got-tty:~] # cd /etc/ssh/
[cmg@got-tty:/etc/ssh] # mv sshd_config sshd_configORIG
[cmg@got-tty:/etc/ssh] # wget https://gist.githubusercontent.com/seraphyn/f5321cba415e8c95552f3f86478965f6/raw/4de45336f5bdd8e4b6b67c4003701c3c42bb5602/sshd_config
[cmg@got-tty:/etc/ssh] # vim sshd_config
In AllowUsers deinen Benutzernamen einsetzen
[cmg@got-tty:/etc/ssh] # systemctl restart ssh.service
!!! Bitte nicht abmelden, da bei einem Fehler ein Anmelden nicht möglich ist !!!

6 Testweise einloggen mit dem lokalen Client

ssh SERVERNAME

Nun in einem neuen Terminal auf dem Client sich via ssh SERVERNAME anmelden.
Als SERVERNAME bitte jenen welcher in der Datei .ssh/config unter HOST definiert wurde.

 

6.1 Wenn dies nicht funktioniert, ausführlichen Login aktivieren

Redselig wird der Zugang via ssh mit der Option -v

ssh -v SERVERNAME

Noch Redseliger wird der Zugang mit der Option -vv

ssh – vv SERVERNAME

Am redseligsten wird der Zugang dann via -vvv ;)

ssh -vvv SERVERNAME

Normalerweise fallen hier schon die Fehler auf und können behoben werden

Grundlage für eine sichere sshd_config
Markiert in:             

7 Gedanken zu „Grundlage für eine sichere sshd_config

  • 2016-10-21 um 16:08
    Permalink

    Ich hab meine SSHD-Config auch mal zu meinen anderen Config-File-Gists hochgeladen $LINKFEHLERHAFT
    Die entspricht weitgehend deiner, aber ist etwas verschlankt, da ein paar alte SSH1-Optionen draußen sind. Außerdem hab ich noch die HostKeyAlgorithms den ssh-audit-Empfehlungen entsprechend angepasst. Da entsprechen die Defaults nämlich auch nicht immer dem, was man haben will.

    Antworten
  • 2016-10-21 um 19:25
    Permalink

    X11Forwarding no
    X11DisplayOffset 10

    Wenn X11Forwarding deaktiviert ist, macht da X11DisplayOffset überhaupt noch Sinn?

    Antworten
    • 2016-10-21 um 20:38
      Permalink

      Nein, ist durch gerutscht.
      Danke dir für das Feedback.

      Antworten
  • 2016-10-22 um 11:05
    Permalink

    Warum soll man pro Server jeweils einen eigenen Key auf Clientseite erzeugen? Wenn ein Angreifer Zugriff auf einen private Key aus .ssh/ hat, dann hat er auch Zugriff auf alle. Ich erkenne den Vorteil noch nicht.

    Antworten
    • 2016-10-22 um 18:29
      Permalink

      Weil ich einen Key pro Kundenserver erstelle, somit habe ich Ordnung.
      Und wenn ich den Kunden nicht mehr habe, dann lösche ich auch den Schlüssel.
      Und Nein, ein Angreifer hat keinen Zugriff auf alle Keys, da sie verschlüsselt auf einem USB-Stick liegen, bzw nochmal verschlüsselt auf einem Share als Backup

      Antworten

Schreibe einen Kommentar

You have to agree to the comment policy.