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 statustailscale 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 wird | OpenSSH mit Schlüsseln über Tailscale | Tailscale SSH |
|---|---|---|
| Authentifizierung | Ed25519- oder RSA-Schlüssel in authorized_keys | Identität des Tailscale-Kontos |
| Wer Zugriff gewährt | sshd und authorized_keys auf jedem Server | Der ssh-Abschnitt der ACL-Richtliniendatei |
| Erneute Authentifizierung | Standardmäßig nicht verfügbar | Die Aktion check verlangt, den Login erneut zu bestätigen |
| Wenn Tailscale nicht verfügbar ist | Der Schlüssel funktioniert weiterhin aus dem lokalen Netzwerk | Kein Zugriff über diesen Weg |
| Client unter iOS/Android | Jeder SSH-Client mit geladenem Schlüssel | Jeder 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 maintermi1 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
- 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.
tailscale upmit anderen Optionen erneut ausführen.tailscale uperwartet, dass du jede zuvor gesetzte, vom Standard abweichende Option wiederholst. Um eine einzelne Einstellung zu ändern, verwendetailscale set.- 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 tailscale0undsudo ufw delete allow 22/tcp. Prüfe, dass du über Tailscale hineinkommst, bevor du sie entfernst. - Falsche Berechtigungen bei OpenSSH. sshd lehnt den Schlüssel ab, wenn
~/.sshnicht auf 700 oderauthorized_keysnicht 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.