¶ Private/Public-Key Authentifizierung
¶ tl;dr
# Installation von openssh-server auf dem server
sudo apt install openssh-server
sudo systemctl enable ssh
sudo systemctl start ssh
# 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 zu Linux
# Hier Transport und Übertragung nach authorized_keys in einem Rutsch
ssh-copy-id bob@server
# Variante 2: Windows zu Linux
# Hier erst Transport und händisches Übertragung nach authorized_keys
# Client
scp public_key.pub bob@server:~/.ssh
# Server
cat id_rsa.pub >> authorized_keys
¶ Voraussetzung auf dem Server herstellen
Voraussetzung für das Anbieten der ssh- Funktionalität ist die Installation von openssh-server.
Im Anschluss muss der Daeman noch mit systemctl gestartet werden.
# server
sudo apt install openssh-server
sudo systemctl enable ssh
sudo systemctl start ssh
¶ Generieren des Schlüsselpaares (public key und private key)
¶ Generieren mit Standardnamen
# client
bob@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
)
Auf einem Windows-Rechner sollte es dann so aussehen:
{{:linux:ssh_client.svg?600|}}
Bei erstmaliger Verwendung von ssh sind die Dateien config, known_hosts und known_hosts_old möglicherweise noch nicht vorhanden.
Verteilt wird ausschließlich der public key! Der private key wird gehütet, wie der eigene Augapfel!
¶ Generieren mit individuellem Namen
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:
# client
ssh-keygen -t rsa -f id_rsa_meinserver
¶ Schlüssel-Transfer: public key --> Server
¶ Variante 1: Linux zu Linux
# client
bob@client: ssh-copy-id bob@server
Solltest du einen individuellen Namen für die Schlüssel erstellt haben,
nutzt du
# client
bob@client: ssh-copy-id -i ~/.ssh/my_key bob@server
-i ~/.ssh/mykey macht hier den Unterschied.
Dabei wird der public key auf den Server transferiert und dort der Datei authorized_keys hizugefügt:
bob@server:~/.ssh/authorized_keys
¶ 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:
# client
bob@client: scp id_rsa.pub bob@server:~/.ssh
¶ Hinzufügen zu authorized_keys auf dem Server
Anschließend muss der Schlüssel manuell der Datei authorized_keys auf dem Server hinzugefügt werden:
# server
bob@server:~/.ssh cat id_rsa.pub >> authorized_keys
{{:linux:ssh_host.svg?600|}}
¶ Einloggen nach dem Schlüssel-Transfer
¶ Fall 1: Du hast keinen individuellen Namen gewählt.
# client
ssh bob@server
Ab jetzt reicht es, einfach, diesen Befehl zu verwenden - eine
Passwort-Abfrage erfolgt nicht mehr.
Dabei verwendest du also den Befehl ssh ergän
zt um das Argumentpaar
bob@server, also dem bob, der am Host server angemeldet
werden soll.
¶ Fall 2: Du hast einen individuellen Schlüsselnamen gewählt:
# client
ssh -i ~/.ssh/my_key bob@server
¶ Einloggen über Alias
Falls dir der Befehl ssh bob@server noch zu lang ist, ist es möglich,
sich über einen Alias einzuloggen.
Schreibe
eine Konfiguration in die Datei ~/.ssh/config auf dem Client.
# client
Host vmx
HostName hostadresse
User bob
IdentityFile path/to/private_key
Ab dann reicht ein Aufruf des Befehls
# client
ssh vmx
(vmx ist natürlich nur ein Platzhalter - den Namen kannst du frei
wählen)
¶ Log-In per Passwort deaktivieren
Datei: /etc/ssh/sshd_config
Selbst wenn du ein Passwort nach allen Sicherheitsregeln erstellt hast, ist es immer noch sicherer gar keine Anmeldung per Passwort zuzulassen.
Konfiguriere hierfür die Datei /etc/ssh/sshd_config
# server
# file: /etc/ssh/sshd_config
PasswordAuthentication no
PubkeyAuthentication yes
Dienst sshd neu starten
Vorsicht: In Ubuntu wird ein Alias namens ssh verwendet, um sshd anzusprechen. Muss man wissen.
# server (Ubuntu)
sudo systemctl restart ssh
Falls es je nach Linux kein ssh gibt, verwende sshd
# server
sudo systemctl restart sshd
oder
# server
sudo systemctl restart ssh.service
ssh stoppen
# server
sudo systemctl stop ssh.socket
sudo systemctl stop ssh.service
¶ Exkurs ssh vs sshd sowie systemctl
¶ systemctl
systemctlist ein Kommandozeilenwerkzeug zur Verwaltung vonsystemd, dem standardmäßigen Init-System vieler moderner Linux-Distributionen.systemdermöglicht Steuerung von Diensten (Services), Units, Systemzuständen und Konfigurationen
Häufige Befehle
| Befehl | Aktion |
|---|---|
systemctl start <dienst> |
Startet einen Dienst |
systemctl stop <dienst> |
Stoppt einen Dienst |
systemctl restart <dienst> |
Startet einen Dienst neu |
systemctl status <dienst> |
Zeigt den Status eines Dienstes an |
systemctl enable <dienst> |
Aktiviert einen Dienst für den automatischen Start beim Booten |
systemctl disable <dienst> |
Deaktiviert einen Dienst |
¶ ssh vs sshd
- Ubuntu und Debian verwenden
sshfür den Client undsshauch für den Dienst - CentOS, Fedora, Arch Linux, und OpenSUSE verwenden
sshdfür den Dienst
Der ssh-Client-Befehl bleibt in allen Distributionen gleich, aber der Dienstname kann entweder ssh oder sshd sein.
¶ Infos über ssh
# server
sudo journalctl -u ssh
Missglückte Anmeldeversuche per SSH werden in den Logdateien des Systems gespeichert. In den meisten Linux-Distributionen findest du diese Informationen in der Datei:
/var/log/auth.log – Diese Datei wird auf Debian-basierten Systemen wie Ubuntu verwendet und enthält Authentifizierungsereignisse, einschließlich fehlgeschlagener SSH-Anmeldeversuche.
Du kannst die fehlgeschlagenen Anmeldeversuche mit folgendem Befehl anzeigen:
# server
grep "Failed password" /var/log/auth.log
Geht auch mit journalctl verwendet:
# server
journalctl -u ssh --grep "Failed password"
¶ Banner Nachricht beim Login anzeigen
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! **
********************************************