Private/Public-Key Authentifizierung

**This is an old revision of the document!**

Private/Public-Key Authentifizierung

tl;dr

 # Erzeugen des private-public-key Paares auf dem Client ssh-keygen -t rsa


  # Übertragen des public(!)-key auf den Server in den .ssh Ordner
  
  # Variante 1: Linux
  # Hier Transport und Übertragung nach authorized_keys in einem Rutsch
  ssh-copy-id user@server
  
  # Variante 2: Windows
  # Hier erst Transport und händisches Übertragung nach authorized_keys
  scp public_key.pub user@server:~/.ssh
  cat id_rsa.pub >> authorized_keys
  

Um ein public-private-key Schlüsselpaar zu erzeugen und richtig zu konfigurieren, müssen wir uns sowohl auf dem Client als auch auf dem Server bewegen.

In der folgenden Anleitung sind die Befehle, die hierfür notwendig sind, aufgelistet.

Bitte beachten: Um zu wissen, ob wir uns gerade auf dem Client oder dem Server befinden, sind den Befehlen jeweils ein user@client(Client) bzw. ein user@server (Server/Host) vorangestellt.

Client

Standort: user@client:~/.ssh

Generieren des Schlüsselpaares (public key und private key)

 user@client: ssh-keygen -t rsa 

Wenn du die folgenden Abfragen nach Dateinamen nur durch Enter überspringst, entstehen standardmäßig zwei Dateien:

  • Der private key: id_rsa
  • Der public key: id_rsa.pub (.pub wie public ;)

Verteilt wird ausschließlich der public key! Der private key wird gehütet, wie der eigenen Augapfel

Natürlich kommt man mit nur einem Schlüsselpaar als Administrator nicht besonders weit. Da man ja nicht für jeden Job bzw. für jeden Server, auf dem man sich anmelden möchte, einen eigenen Rechner hat, können im oben genannten Prozess auch individuelle Namen für die Schlüssel erzeugt werden.

Schlüssel-Transfer

Variante 1: Der public key muss zum Server transferiert werden

Hierfür wird folgender Befehl genutzt:

 user@client: ssh-copy-id user@server 

Solltest du einen individuellen Namen für die Schlüssel erstellt haben, nutzt du

 user@client: ssh-copy-id -i ~/.ssh/mykey user@server 

Dabei wird der public key auf den Server transferiert und dort im Order\ user@server: <del>/.ssh der Datei user@server:</del>/.ssh/authorized_keys\ hinzugefügt.

Variante 2: Sorgenkind Windows

Sollte der Befehl ssh-copy bei dir nicht installiert sein (Windows), musst du den Schlüssel per scp auf den Server in den Ordner .ssh transferieren:

 user@client: scp id_rsa.pub user@server:~/.ssh 

Anschließend muss der Schlüssel manuell der Datei authorized_keys auf dem Server hinzugefügt werden:

 user@server:~/.ssh cat id_rsa.pub >> authorized_keys 

Einloggen

Fall 1: Du hast keinen individuellen Namen gewählt.

 ssh user@server 

Ab jetzt reicht es, einfach, diesen Befehl zu verwenden - eine Passwort-Abfrage erfolgt nicht mehr.\ Dabei verwendest du also den Befehl ssh ergänzt um das Argumentpaar user@server, also dem User, der am Host server angemeldet werden soll.

Fall 2: Du hast einen individuellen Schlüsselnamen gewählt:

 ssh -i ~/.ssh/id_rsa user@server 

Einloggen über Alias

Falls dir der Befehl ssh user@server noch zu lang ist, ist es möglich, sich über einen Alias einzuloggen.

 Host vmx HostName hostadresse User user IdentityFile private_key 

Ab dann reicht ein Aufruf des Befehls

 ssh vmx 

(vmx ist natürlich nur ein Platzhalter - den Namen kannst du frei wählen)

Möglichkeit zum Log-In per Passwort deaktivieren

 PasswordAuthentication no PubkeyAuthentication yes 

Anschließend noch sshd neu starten:

 sudo systemctl restart sshd 

Falls es je nach Linux kein sshd gibt, verwende systemctl

 sudo systemctl restart ssh 

oder

 sudo systemctl restart ssh.service 

SSH-Banner-Warnungen sind notwendig, wenn Unternehmen oder Organisationen eine Warnung anzeigen möchten, um unbefugte Parteien davon abzuhalten, auf einen Server zuzugreifen.

Diese Warnungen werden direkt vor der Passwortabfrage angezeigt, damit unbefugte Benutzer, die sich gerade einloggen wollen, auf die Konsequenzen ihres Handelns aufmerksam gemacht werden. Typischerweise beinhalten diese Warnungen rechtliche Konsequenzen, die unbefugte Benutzer erleiden können, sollten sie sich entscheiden, auf den Server zuzugreifen.

Beachte, dass eine Banner-Warnung keineswegs eine Methode ist, um unbefugte Benutzer vom Einloggen abzuhalten. Die Warnung dient lediglich dazu, unbefugte Parteien vom Einloggen abzuschrecken.

Wenn Du unbefugte Benutzer vom Einloggen abhalten möchten, sind zusätzliche SSH-Konfigurationen erforderlich.

How to

Gehe wieder in die bekannte ssh-Konfigurationsdatei /etc/ssh/sshd_config und suche dort nach folgender Zeile:

====== no default banner path ======
====== Banner none ======

Ändere den Inhalt dieser Zeilen so, dass statt # Banner none nun der Pfad zu einer Datei steht, in der du die Informationen eingibst, die du magst. Die Zeilen könnten also folgendermaßen aussehen:

====== no default banner path ======
Banner /etc/mybanner 

Mit einem Editor deiner Wahl, zum Beispiel nano erzeugst du nun diese Datei mybanner und schreibst den Inhalt hinein:


----
** Willkommen. Aber nur mit Erlaubnis!   **


----