# 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 user@server
 
# Variante 2: Windows zu Linux
# Hier erst Transport und händisches Übertragung nach authorized_keys
# Client
scp public_key.pub user@server:~/.ssh
# Server
cat id_rsa.pub >> authorized_keys

Standort: user@client:~/.ssh

# client
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 ;))

Auf einem Windows-Rechner sollte es dann so aussehen:

Verteilt wird ausschließlich der public key! Der private key wird gehütet, wie der eigene 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:

# client
ssh-keygen -t rsa  -f id_rsa_meinserver

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

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

# client
user@client: ssh-copy-id -i ~/.ssh/mykey user@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:

user@server:~/.ssh/authorized_keys

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
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:

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

# client
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.

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

Falls dir der Befehl ssh user@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 user
    IdentityFile 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)

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

Vorsicht: In Ubuntu wird ein Alias namens ssh verwendet, um sshd anzusprechen. Muss man wissen.

# server
sudo systemctl restart ssh

Falls es je nach Linux kein ssh gibt, verwende sshd

# server
sudo systemctl restart ssh

oder

# server
sudo systemctl restart ssh.service

# server
sudo systemctl stop ssh.socket
sudo systemctl stop ssh.service

• systemctl ist ein Kommandozeilenwerkzeug zur Verwaltung von systemd, dem standardmäßigen Init-System vieler moderner Linux-Distributionen.
• systemd ermöglicht Steuerung von Diensten (Services), Units, Systemzuständen und Konfigurationen

Häufige Befehle

• Ubuntu und Debian verwenden ssh für den Client und ssh auch für den Dienst
• CentOS, Fedora, Arch Linux, und OpenSUSE verwenden sshd für den Dienst

Der ssh-Client-Befehl bleibt in allen Distributionen gleich, aber der Dienstname kann entweder ssh oder sshd sein.

# 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"

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!   **
********************************************