Über den Author / Programme / SSH Authentifizierung mit PrivateKey

SSH Authentifizierung mit PrivateKey

~2 Min. Lesezeit

Wie alle PC haben auch Server ein User/Passwort zum verbinden und einloggen.

Unter Linux heisst der höchst privilegierteste User root.
Ist man im Besitz eines eigenen Linux Servers (Root Server) hat man Zwangsweise Bruteforce Attacken auf den SSH Dienst.
Eine Schutzmassnahme ist den Port von 22 auf ein anderen Port zu verlegen, um die Skriptkiddies abzuhalten. Leider ist dies aber keine richtige Schutzmassnahme.

Ein sicheres Passwort ist daher die Schutzmassnahme Nr2. Was ist sicherer als ein Passwort?
Nennen wir es mal ein Passwort mit 2000 Zeichen? Ein Key zum authentifizieren.

Diesen können wir zum Beispiel mit erstellen.


Als erstes kann man die Einstellungen vornehmen, das ein 2048bit Schlüssel generiert wird, wobei ich das DSA Verfahren bevorzuge.

Anschliessend kann man auf „Generate“ drücken. Sobald man dies gemacht hat, werden die Mausbewegungen (bis der Balken voll ist) im Key Feld aufgezeichnet und damit ein zufälliger Wert generiert, welcher Einmalig ist und damit wie ein Fingerabdruck auf dich passt und am Ende dein Schlüssel gibt.

Der Schlüssel kann man entweder mit einer Passphrase schützen oder diesen ungeschützt z.B in einem TrueCrypt abspeichern.

Sobald der Kommentar geändert und gegebenenfalls ein Passwort gewählt wurde, kann nun der Private Key gespeichert werden.

Diese Datei ist euer Fingerabdruck, zum euch auf den Server zu verbinden. Diese Datei darf NIEMALS weitergegeben oder irgendwo veröffentlicht werden. Schützt diesen gut.

Anschliessend kümmern wir uns darum, dass der Server unseren Fingerabdruck kennt, dazu kopieren wir den kompletten Inhalt aus dem Public Key Feld:

Auf dem Root Server muss man nun folgende Befehle durchführen:

cd $HOME
mkdir .ssh
touch .ssh/authorized_keys
chmod –R 644 .ssh

Nun kann der zuvor kopierte Public Key in das File authorized_keys im Folder .ssh kopiert werden (alles ist 1 Zeile).

Nun muss man noch dem SSH Server mitteilen, dass er die Authentifizierung akzeptiert. Dazu editieren wir die Datei /etc/ssh/sshd_config:

PermitRootLogin yes
RSAAuthentication yes
PubkeyAuthentication yes

Startet man nun den SSH Dienst neu, kann man testen obs funktioniert hat. dies macht man mit:

/etc/init.d/ssh restart

Um dies zu testen, startet man Putty und gibt das Keyfile im dazugehörigen Feld an:

Funktioniert das Anmelden ohne Passwort, kann man ein weiteres Mal in die Datei /etc/ssh/sshd_config wechseln und folgende Zeile anpassen:

PasswordAuthentication no

Nachdem man ein 2tes Mal den SSH Dienst reloaded hat, ist die Passwortauthentifizierung abgeschaltet.
Versucht nun Jemand auf den SSH Port zu connecten ohne Key File, bekommt er vollautomatisch die Meldung „No supported authentication method available“ und die Verbindung wird gleich geschlossen.

Bruteforce Bots haben so keine Chance mehr.

About Stefan

avatar
Ein männlicher IT Nerd, durchstöbert das Web nach speziellen Gadgets, unentbehrlicher Software und Alles was man im IT Sektor nicht verpassen darf.Immer hilfsbereit wenn Probleme zu lösen sind oder das Unmögliche umgesetzt werden sollte.

Weitere interessante Artikel

Outlook Darstellungsprobleme bei USB Dockingstation

~0 Min. LesezeitBei Outlook können Darstellungsprobleme auftreten. Nach intensiver Suche habe ich die Gründe dazu …

Windows 10 Tracking abschalten

~0 Min. LesezeitWindows 10 steht in den Startlöchern. Scheinbar finanziert die NSA kräftig mit bei …

10 Kommentare

  1. avatar

    Ich bekomme es irgendwie nicht mehr hin, habe es schonmal gemacht, aber dann lange nicht mehr darauf geachtet.

    Na jedenfalls hab ich meiner Meinung nach alles so gemacht wie du beschrieben hast, doch es kommt „Server refused our key“.

    Irgendeine Idee?

  2. avatar

    Vorweg, ein sehr schönes How To IT Blögg, hat mir doch sehr weitergeholfen ohne mich groß durch wildeste Anleitungen zu wühlen.
    Leider hatte ich anfangs Probleme mich mittels KeyFile zu authentifizieren.
    „Server refused our key“ und die normale Passwortabfrage waren das einzige was ich beim Login bekam.

    Nachdem ich dann doch ein wenig gegoogelt hatte und mir das auth.log in /var/log angesah, war mir fast klar was ich erledigen musste damit es klappt.
    Bei meinen login Versuchen wurde nämlich folgendes protokolliert:
    Could not open authorized keys ‚/home/user/.ssh/authorized_keys‘: Permission denied

    Dieser Kommentar den ich gefunden hatte war dann die letze Information die ich gebraucht habe.
    „The most common gotcha I find is the rights on ~/.ssh, which should be 600 (or 700), but often 640 by default.“

    Es handelte sich also um ein klaren Fall von falschen Rechten.
    Folgende Befehle haben bei mir abhilfe geschaffen und seitdem funktioniert es einwandfrei.
    chmod 700 ~/.ssh
    chmod 600 ~/.ssh/authorized_keys

  3. avatar

    Beim ersten Versuch hat es bei mir leider nicht geklappt, mal schauen, ob ich es auf einer anderen Linux Maschine hinbekommen.

  4. avatar

    Pflicht als IT Admin 😉 Einfach und tot sicher.

  5. avatar

    …. sicher und etwas bequem, wenn man eine Menge der Linux Server überwacht 🙂

  6. avatar

    Endlich geklappt, der Fehler lag anscheinend an den falschen Einstellungen in /etc/ssh/sshd_config. Danke für HowTo. Warum bevorzugst du DSA Verfahren?

  7. avatar

    Hallo Stefan

    Um diese Aktion unter einem Linux Server durchzuführen, reichen nur 2 einfache Befehle:

    1) root@linux:~ > ssh-keygen -b 2048 -t rsa

    2) ssh-copy-id -i .ssh/id_rsa.pub root@remote-linux-server.de

    Wahrscheinlich würde es nicht schaden, wenn du diese Befehle in dein HOWTO aufnimmst. A la „SSH Zugriff per Key unter 2 Linux Maschinen “

    Linux: sicher, einfach, cool 🙂

  8. avatar

    Unter einem Linux Client empfehlenswert. Von Server zu Server fragwürdig. Ich nutze es auch und es hat mir fast mal viel gekostet.
    Ein neues Update auf dem Remote Console eingespielt und das Update hat den anonymous User wieder aktuiviert (wurde von Microsystems gleich behoben zum Glück).
    einer hat die console gefunden, Server in Recovery gebootet und wollte so gleich auf den Server. Hätte ich kein Monitoring gehabt, hätte er so schnell auf ein weiteren Server Zugriff gehabt.
    Daher Serverhopping meist nie mit root zulassen, sondern einem niedrigen User, dann nach dem Hopping mit „sudo -s“ und Passwort auf Root wechseln, oder halt Key verschlüsseln.

    Naja, ich habe dann die Console zugemacht und Server neu aufgesetzt und alle Server2Server Keys ausgetauscht.
    Server zu Server immer aufpassen 😉

  9. avatar

    Ja, du hast natürlich Recht, das mit root habe ich einfach als Beispiel geschrieben. Habe mir keine weitere Gedanken gemacht.
    Cool, hast du den Angriff mit Nagios festgestellt? Mit welchem Check kann man so ein Angriff überwachen?

    Sowas wie „check_user_anonymous“ ?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

eMail-Benachrichtigung bei weiteren Kommentaren.
Auch möglich: Abo ohne Kommentar.

This Blog will give regular Commentators DoFollow Status. Implemented from IT Blögg