SSH

SSH – Grundlagen und Praxis für Admins

SSH (Secure Shell) ist der Standardweg, um sich sicher auf entfernte Server einzuloggen, Dateien zu übertragen und Kommandos auszuführen. Diese Seite erklärt:

• Was SSH ist
• Wie SSH-Schlüsselpaare funktionieren
• Wie man SSH auf dem Client einrichtet
• Wie man einen Server für SSH-Login per Schlüssel vorbereitet
• SSH-Config (Komfort)
• Spezialanwendung: GitHub über SSH

1. Was ist SSH?

SSH (Secure Shell)

Netzwerkprotokoll, mit dem man verschlüsselt auf entfernte Maschinen zugreift:

 * interaktive Shell (Terminal),
 * Dateiübertragung (scp / sftp),
 * Port-Forwarding (Tunnels),
 * automatisierte Skripte ohne Passwort.

SSH ersetzt unsichere Klassiker wie Telnet oder rsh.

2. Authentifizierung: Passwort vs. Schlüsselpaar

Es gibt zwei Hauptvarianten, sich per SSH anzumelden:

• **Passwort-Login**

 – bei jeder Verbindung wird ein Passwort abgefragt.

• **Schlüsselbasierter Login (Public-Key-Auth)**

 – man hat ein Schlüsselpaar:
   * **Privater Schlüssel** (secret, bleibt beim Benutzer)
   * **Öffentlicher Schlüssel** (public, wird zum Server kopiert)  
 – der Server erkennt den Schlüssel und lässt den Benutzer ohne Passwort rein.

Vorteile von Schlüsseln:

• Keine Passwörter im Klartext über die Leitung.
• Man kann Passwörter für SSH-Accounts sogar komplett deaktivieren.
• Skripte/Automatisierung werden einfacher und sicherer.

3. Schlüsselpaar auf dem Client erzeugen

Auf dem eigenen Rechner (Linux/Mac, im Terminal):

ssh-keygen -t ed25519 -C "dein-name@tuxi"

Erläuterungen:

• -t ed25519 → moderner Schlüsseltyp, kurz und sicher.
• -C → Kommentar, z. B. Email oder Rechnername (nur zur Orientierung).

SSH fragt dann:

• Pfad für den Schlüssel (Standard: ~/.ssh/id_ed25519)
• Optional eine **Passphrase** (empfohlen!) – schützt den Schlüssel bei Diebstahl.

Am Ende liegen typischerweise zwei Dateien im Verzeichnis ~/.ssh:

• id_ed25519 → privater Schlüssel (GEHEIM, nicht herumkopieren)
• id_ed25519.pub → öffentlicher Schlüssel (darf auf Server und Dienste)

Rechte kontrollieren:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

4. Öffentlichen Schlüssel auf den Server kopieren

Ziel: Auf dem Server (z. B. Tuxi) soll der öffentliche Schlüssel in der Datei ~/.ssh/authorized_keys des Ziel-Users stehen.

4.1 Bequemer Weg: ssh-copy-id

Wenn man noch Passwortzugang hat:

ssh-copy-id -i ~/.ssh/id_ed25519.pub benutzername@server.example.org

Das Script:

• loggt sich einmal mit Passwort ein,
• hängt den Inhalt der .pub-Datei ans Ende von ~/.ssh/authorized_keys.

4.2 Manueller Weg

1. Auf dem Client:

   cat ~/.ssh/id_ed25519.pub
   

  → Zeile kopieren.

2. Auf dem Server als Ziel-User einloggen und:

   mkdir -p ~/.ssh
   chmod 700 ~/.ssh
   nano ~/.ssh/authorized_keys
   

3. Den kopierten Schlüssel als **eine Zeile** einfügen, speichern.

4. Rechte setzen:

   chmod 600 ~/.ssh/authorized_keys
   

5. Login testen

Auf dem Client:

ssh benutzername@server.example.org

Wenn alles passt:

• SSH fragt nach der Schlüssel-Passphrase (falls gesetzt),
• man landet ohne Accountpasswort auf der Shell.

Später (optional) kann man im SSH-Server das Passwort-Login komplett abschalten (z. B. PasswordAuthentication no in /etc/ssh/sshd_config und Dienst neu starten) – das gehört dann zur „Hardening“-Runde.

6. SSH-Config: Komfort-Aliase für Verbindungen

Datei ~/.ssh/config auf dem Client anlegen/bearbeiten:

Host tuxi
    HostName server.example.org
    User benutzername
    IdentityFile ~/.ssh/id_ed25519

Host github
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519

Ab jetzt reichen einfache Kommandos:

ssh tuxi

statt immer ssh benutzername@server.example.org.

7. Spezialanwendung: GitHub über SSH

SSH ist nicht nur für Shell-Logins da – Git nutzt SSH ebenfalls, um mit GitHub zu sprechen.

7.1 SSH-Key bei GitHub hinterlegen

Voraussetzung: Schlüsselpaar existiert (siehe oben).

1. Öffentlichen Schlüssel auf dem Client anzeigen:

   cat ~/.ssh/id_ed25519.pub
   

2. Inhalt kopieren (komplette Zeile).

3. Bei GitHub im Browser einloggen:

  * Rechts oben auf den Avatar → „Settings“
  * Links im Menü: „SSH and GPG keys“
  * „New SSH key“:
    * Title: z. B. „Tuxi-Client“
    * Key type: „Authentication Key“
    * Key: kopierte Zeile einfügen
  * Speichern.

7.2 Verbindung testen

Auf dem Client:

ssh -T git@github.com

Beim ersten Mal fragt SSH, ob es github.com dem bekannten Hostschlüssel hinzufügen darf → mit yes bestätigen.

Wenn alles passt, zeigt GitHub einen Begrüßungstext in der Art:

Hi <username>! You've successfully authenticated, but GitHub does not provide shell access.

Das ist korrekt – Shell gibt es bei GitHub nicht, nur Git-Zugriff.

7.3 Git-Remote via SSH verwenden

In einem lokalen Git-Repo:

git remote add origin git@github.com:BENUTZERNAME/REPO.git

Ab dann:

• git push / git pull nutzen SSH + Schlüssel zur Authentifizierung.
• Git fragt ggf. nach der Schlüssel-Passphrase (oder nutzt einen SSH-Agenten).

8. Sicherheitshinweise in Kurzform

• Den **privaten Schlüssel** niemals weitergeben oder auf fremde Maschinen kopieren.
• Immer eine **Passphrase** setzen (außer bei reinen Test-Keys).
• Rechte auf ~/.ssh, private Keys und authorized_keys restriktiv halten:

 * ~/.ssh → 700
 * private Keys → 600
 * authorized_keys → 600

• Bei Servern mit Internetzugang:

 * nach Möglichkeit nur Schlüssel-Login erlauben,
 * Root-Login verbieten,
 * Fail2ban o.ä. gegen Brute-Force einsetzen.