Admin am 24. November 2025 um 15:17 Uhr

2025-11-24T15:17:13Z

← Nächstältere Version		Version vom 24. November 2025, 15:17 Uhr
Zeile 138:		Zeile 138:
	Host tuxi		Host tuxi
	HostName server.example.org		HostName server.example.org
	User ~~enchiriadis~~		User benutzername
	IdentityFile ~/.ssh/id_ed25519		IdentityFile ~/.ssh/id_ed25519

Zeile 153:		Zeile 153:
	</pre>		</pre>

	statt immer <code>ssh ~~enchiriadis~~@server.example.org</code>.		statt immer <code>ssh benutzername@server.example.org</code>.

	== 7. Spezialanwendung: GitHub über SSH ==		== 7. Spezialanwendung: GitHub über SSH ==

Admin: SSH: Sichere Verbindungen zu entfernten Rechnern

2025-11-24T15:15:37Z

SSH: Sichere Verbindungen zu entfernten Rechnern

Neue Seite

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

<pre>
ssh-keygen -t ed25519 -C "dein-name@tuxi"
</pre>

Erläuterungen:

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

SSH fragt dann:

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

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

* <code>id_ed25519</code> → privater Schlüssel (GEHEIM, nicht herumkopieren)
* <code>id_ed25519.pub</code> → öffentlicher Schlüssel (darf auf Server und Dienste)

Rechte kontrollieren:

<pre>
chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub
</pre>

== 4. Öffentlichen Schlüssel auf den Server kopieren ==

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

=== 4.1 Bequemer Weg: ssh-copy-id ===

Wenn man noch Passwortzugang hat:

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

Das Script:

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

=== 4.2 Manueller Weg ===

1. Auf dem Client:

<pre>
cat ~/.ssh/id_ed25519.pub
</pre>

→ Zeile kopieren.

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

<pre>
mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
</pre>

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

4. Rechte setzen:

<pre>
chmod 600 ~/.ssh/authorized_keys
</pre>

== 5. Login testen ==

Auf dem Client:

<pre>
ssh benutzername@server.example.org
</pre>

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. <code>PasswordAuthentication no</code> in <code>/etc/ssh/sshd_config</code> und Dienst neu starten) – das gehört dann zur „Hardening“-Runde.

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

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

<pre>
Host tuxi
HostName server.example.org
User enchiriadis
IdentityFile ~/.ssh/id_ed25519

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

Ab jetzt reichen einfache Kommandos:

<pre>
ssh tuxi
</pre>

statt immer <code>ssh enchiriadis@server.example.org</code>.

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

<pre>
cat ~/.ssh/id_ed25519.pub
</pre>

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:

<pre>
ssh -T git@github.com
</pre>

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

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

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

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

=== 7.3 Git-Remote via SSH verwenden ===

In einem lokalen Git-Repo:

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

Ab dann:

* <code>git push</code> / <code>git pull</code> 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 <code>~/.ssh</code>, private Keys und <code>authorized_keys</code> restriktiv halten:
* <code>~/.ssh</code> → 700
* private Keys → 600
* <code>authorized_keys</code> → 600
* Bei Servern mit Internetzugang:
* nach Möglichkeit nur Schlüssel-Login erlauben,
* Root-Login verbieten,
* Fail2ban o.ä. gegen Brute-Force einsetzen.

SSH - Versionsgeschichte

Admin am 24. November 2025 um 15:17 Uhr

Admin: SSH: Sichere Verbindungen zu entfernten Rechnern