Mit Tailscale verbindest du dich per SSH mit einem Server, der weder eine öffentliche IP noch offene Router-Ports hat. Du führst tailscale up auf dem Server aus, meldest dich in der Tailscale-App auf deinem Smartphone mit demselben Konto an und verbindest dich dann mit der 100.x-Adresse des Rechners oder seinem MagicDNS-Namen. ACLs legen fest, wer hineinkommt und als welcher Benutzer.

So installierst du Tailscale und führst tailscale up auf einem Linux-Server aus

tailscale up nimmt den Rechner in dein Tailnet auf und gibt eine Login-URL aus. Sobald du dich authentifiziert hast, erhält der Rechner eine 100.x-Adresse. Unter Linux installiert das offizielle Skript sowohl das Paket als auch den Dienst:

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4
tailscale status

tailscale ip -4 gibt die IPv4-Adresse des Rechners im Tailnet aus, und tailscale status listet die anderen Geräte mit ihren Namen und ihrem Status auf. Der Datenverkehr zwischen den Knoten wird über WireGuard verschlüsselt. Jeder Knoten baut seine Verbindung ausgehend auf, daher musst du weder TCP-Port 22 im Router weiterleiten noch eine öffentliche IP haben.

Unter macOS, iOS und Android tippst du kein tailscale up. Du installierst die Tailscale-App und meldest dich über ihre Oberfläche an.

Tailscale-100.x-Adressen und MagicDNS: Welchen Host dein SSH-Client ansteuert

Jeder Tailscale-Knoten erhält eine Adresse aus dem Bereich 100.64.0.0/10, die nur innerhalb deines Tailnets erreichbar ist. MagicDNS gibt ihm außerdem einen Namen, der dem Rechnernamen entspricht. Jeder SSH-Client akzeptiert alle drei Formen:

ssh [email protected]
ssh deploy@servidor
ssh [email protected]

Der Kurzname ist am bequemsten. Wird er auf einem bestimmten Gerät nicht aufgelöst, verwende stattdessen den vollständigen .ts.net-Namen. Speichere die Verbindung unter ihrem MagicDNS-Namen statt unter der IP. So zeigt der Name weiterhin auf den richtigen Rechner, falls sich der Knoten neu registriert und seine Adresse sich ändert.

Wenn du nicht von Tailscale abhängig sein möchtest, löst das private Mesh-Netzwerk Prialo dasselbe Problem: Rechner erreichen, ohne Ports zu öffnen.

Tailscale SSH vs. OpenSSH mit Schlüsseln: Vergleichstabelle

sudo tailscale set --ssh aktiviert Tailscale SSH auf dem Server. Tailscale beantwortet dann Verbindungen zu Port 22, die über das Tailnet eintreffen, und authentifiziert sie mit deiner Kontoidentität, sodass keine Schlüssel in authorized_keys nötig sind. Die Alternative ist, OpenSSH mit Schlüsseln beizubehalten und Tailscale ausschließlich als Netzwerk zu nutzen.

Was verglichen wirdOpenSSH mit Schlüsseln über TailscaleTailscale SSH
AuthentifizierungEd25519- oder RSA-Schlüssel in authorized_keysIdentität des Tailscale-Kontos
Wer Zugriff gewährtsshd und authorized_keys auf jedem ServerDer ssh-Abschnitt der ACL-Richtliniendatei
Erneute AuthentifizierungStandardmäßig nicht verfügbarDie Aktion check verlangt, den Login erneut zu bestätigen
Wenn Tailscale nicht verfügbar istDer Schlüssel funktioniert weiterhin aus dem lokalen NetzwerkKein Zugriff über diesen Weg
Client unter iOS/AndroidJeder SSH-Client mit geladenem SchlüsselJeder SSH-Client, der mit dem Tailnet verbunden ist

Wenn du bei Schlüsseln bleibst, verwende Ed25519. OpenSSH unterstützt es seit Version 6.5 (Januar 2014) und FIDO2-gestützte ed25519-sk-Schlüssel seit 8.2. In termi1 kannst du den Schlüssel direkt auf dem Smartphone erzeugen; er wird im sicheren Speicher des Systems abgelegt, und der private Schlüssel verlässt das Gerät nie.

Tailscale-ACLs für SSH: Einschränken, wer hineinkommt und als welcher Benutzer

Die Tailscale-Richtliniendatei hat zwei Ebenen. acls steuert, wer Port 22 erreichen kann, und ssh steuert, wer Tailscale SSH nutzen darf und als welcher lokale Benutzer. Dieses Beispiel lässt nur die Gruppe admins hinein, und zwar nur als deploy, auf Servern mit dem Tag für Produktion:

{
  "groups": { "group:admins": ["[email protected]"] },
  "tagOwners": { "tag:prod": ["group:admins"] },
  "acls": [
    { "action": "accept", "src": ["group:admins"], "dst": ["tag:prod:22"] }
  ],
  "ssh": [
    { "action": "check", "src": ["group:admins"], "dst": ["tag:prod"], "users": ["deploy"] }
  ]
}

Den Tag weist du dem Server mit der Option --advertise-tags=tag:prod von tailscale up zu. Mit "action": "accept" erfolgt der Zugriff sofort; mit "check" bittet Tailscale dich, deine Identität zu bestätigen, bevor die Sitzung geöffnet wird. Jedes Feld wird in der offiziellen Tailscale-SSH-Dokumentation erklärt.

Mosh, tmux und SFTP über Tailscale vom Smartphone mit termi1

Mosh startet mosh-server über eine anfängliche SSH-Verbindung und wechselt dann zu UDP, standardmäßig auf den Ports 60000-61000. Innerhalb des Tailnets müssen auch diese Ports nicht im Router geöffnet werden:

mosh deploy@servidor
tmux new -A -s main

termi1 hält die Sitzung mit Mosh aufrecht, wenn du von WLAN zu mobilen Daten wechselst, und tmux bewahrt alles, was du laufen gelassen hast, bis du zurückkommst. Mosh bietet weder Port-Forwarding noch X11-Forwarding; öffne also eine separate SSH-Sitzung, wenn du einen Tunnel brauchst. Die termi1-Tastatur hat Esc, Ctrl, Tab und Pfeiltasten zur Steuerung von tmux. Mit dem integrierten SFTP kannst du Dateien über denselben MagicDNS-Namen hoch- oder herunterladen, ohne die Sitzung zu verlassen.

Wenn du deine Verbindungen zu tag:prod-Servern in termi1 als Produktion markierst, verhindert Production Guard, dass die KI dort Enter drückt. Außerdem hält er alles zurück, was etwas löscht, stoppt oder ändert, bevor es den Prompt erreicht. Die App gibt es im App Store für iPhone und bei Google Play.

4 Fehler bei SSH-Verbindungen über Tailscale

  1. Die Tailscale-App auf dem Smartphone ist getrennt. Ist das Tailscale-VPN nicht aktiv, werden weder 100.x-Adressen noch MagicDNS-Namen aufgelöst, und beim SSH-Client kommt es zu einem Timeout.
  2. tailscale up mit anderen Optionen erneut ausführen. tailscale up erwartet, dass du jede zuvor gesetzte, vom Standard abweichende Option wiederholst. Um eine einzelne Einstellung zu ändern, verwende tailscale set.
  3. Port 22 auf der öffentlichen Schnittstelle offen lassen. Erlaube mit ufw zuerst die Tailnet-Schnittstelle und entferne dann die allgemeine Regel: sudo ufw allow in on tailscale0 und sudo ufw delete allow 22/tcp. Prüfe, dass du über Tailscale hineinkommst, bevor du sie entfernst.
  4. Falsche Berechtigungen bei OpenSSH. sshd lehnt den Schlüssel ab, wenn ~/.ssh nicht auf 700 oder authorized_keys nicht auf 600 gesetzt ist.

Häufig gestellte Fragen

Braucht Tailscale offene Router-Ports für SSH?

Tailscale benötigt für SSH keine offenen Router-Ports. Jeder Knoten baut seine Verbindung ausgehend auf, und der Datenverkehr wird innerhalb des Tailnets über WireGuard verschlüsselt. Du musst lediglich Server und Smartphone mit demselben Konto anmelden und ACLs haben, die Port 22 erlauben.

Was ist der Unterschied zwischen Tailscale SSH und SSH mit Schlüsseln?

Tailscale SSH authentifiziert mit der Identität deines Tailscale-Kontos und setzt den ssh-Abschnitt deiner ACLs durch, sodass keine Schlüssel in authorized_keys nötig sind. SSH mit Schlüsseln nutzt reguläres OpenSSH über das Tailnet und funktioniert aus dem lokalen Netzwerk weiter, auch wenn Tailscale nicht verfügbar ist.

Funktioniert Mosh über Tailscale?

Mosh funktioniert über Tailscale. Es startet mosh-server über eine anfängliche SSH-Verbindung und nutzt dann UDP innerhalb des Tailnets, standardmäßig auf den Ports 60000-61000. Du musst diese Ports nicht im Router öffnen, aber die lokale Firewall des Servers muss sie auf der Tailscale-Schnittstelle erlauben.

Kann ich MagicDNS statt der 100.x-Adresse verwenden?

MagicDNS gibt jedem Rechner im Tailnet einen Namen, der seinem Hostnamen entspricht, sodass du ssh deploy@servidor statt der 100.x-Adresse eingeben kannst. Wird der Kurzname nicht aufgelöst, verwende den vollständigen Namen mit der Endung .ts.net, der in der Tailscale-Admin-Konsole angezeigt wird.