≪ View Page

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
linux:ssh [2025/04/26 13:40] – swelinux:ssh [2025/12/20 14:53] (current) – external edit 127.0.0.1
Line 1: Line 1:
-### Variante 1: Der public key muss zum Server transferiert werden+# Private/Public-Key Authentifizierung 
  
-Hierfür wird folgender Befehl genutzt: +## 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 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 
 +```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 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. 
 + 
 +## Schlüssel-Transfer 
 +Der public key muss zum Server transferiert werden 
 + 
 +### Variante 1: Linux zu Linux
  
 ``` ```
Line 7: Line 66:
 ``` ```
  
-Solltest du einen individuellen Namen für die Schlüssel erstellt haben,+Solltest du einen **individuellen** Namen für die Schlüssel erstellt haben,
 nutzt du  nutzt du 
  
Line 13: Line 72:
 user@client: ssh-copy-id -i ~/.ssh/mykey user@server 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**:
  
-Dabei wird der public key auf den Server transferiert und dort im Order  
  
-``` 
-user@server: ~/.ssh 
-```  
-der Datei  
 ``` ```
 user@server:~/.ssh/authorized_keys user@server:~/.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 
 +``` 
 +Hier geht es um das `cat id_rsa.pub >> authorized_keys`. 
 + 
 +## Einloggen nach dem Schlüssel-Transfer 
 + 
 +### 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. 
 + 
 +Schreibe eine Konfiguration in die Datei `~/.ssh/config` auf dem **Client**. 
 + 
 +``` 
 +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 in /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` 
 + 
 +``` 
 +PasswordAuthentication no 
 +PubkeyAuthentication yes 
 +``` 
 + 
 +#### Anschließend noch sshd neu starten: 
 + 
 +Vorsicht: In Ubuntu wird ein Alias namens `ssh` verwendet, um `sshd` anzusprechen. Muss man wissen. 
 +``` 
 +sudo systemctl restart ssh 
 +``` 
 + 
 +Falls es je nach Linux kein `ssh` gibt, verwende `sshd` 
 + 
 +``` 
 +sudo systemctl restart ssh 
 +``` 
 + 
 + oder   
 + 
 +``` 
 +sudo systemctl restart ssh.service 
 +``` 
 +#### ssh stoppen 
 +``` 
 +sudo systemctl stop ssh.socket 
 +sudo systemctl stop ssh.service 
 +``` 
 + 
 +### Exkurs ssh vs sshd sowie systemctl 
 + 
 +#### systemctl 
 +- `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 
 +|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 `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. 
 + 
 +### Infos über ssh 
 +``` 
 +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: 
 + 
 +```bash 
 +grep "Failed password" /var/log/auth.log 
 +``` 
 + 
 +Geht auch mit `journalctl` verwendet: 
 + 
 +```bash 
 +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!   ** 
 +******************************************** 
 +```