Insights
How to disable Tailscale SSH without disconnecting Tailscale
Disable embedded Tailscale SSH on one device or across your tailnet, keep Tailscale connected, and verify ordinary SSH fallback access.
On this page
On the destination device, run tailscale set --ssh=false to turn off embedded Tailscale SSHOpens in a new tab. First, make sure you have another working way to access that device. This changes the SSH setting without disconnecting Tailscale.
In short:
- One device. Disable embedded SSH on the destination, not the connecting laptop.
- Keep ordinary SSH. It can remain available when its server and separate access controls permit it.
- Retire it everywhere. Opt out every host and remove the Tailscale SSH access rules.
Turn off the server on the destination device
The embedded server runs on Linux and macOS devices using the open-source tailscale plus tailscaled command-line variant. Other platforms can connect as clients without hosting that server.
1. Test an independent access path.
Only change a device you own or administer. Test another way to manage it before you disable Tailscale SSH, and keep console access available for recovery. Don't count on your current remote session surviving.
2. Disable embedded SSH on the destination.
On the Linux or supported open-source macOS destination, run this command with administrative privileges if required:
tailscale set --ssh=false
Running it on your connecting laptop doesn't disable the destination's server.
If you already have authorized access to the device web interfaceOpens in a new tab, you can use its toggle instead. Open Settings, select Tailscale SSH server, then turn the toggle off. Don't enable or expose a web interface just for this task.
What stays running after the change
Disabling embedded SSH does not install or start a replacement. The ordinary server must already exist, listen on the intended address and port, and permit the connection.
Secure Shell (SSH) lets you log in remotely and run commands. A tailnet is your private Tailscale network. The tailscale set command updates only the settings you specifyOpens in a new tab, leaving unrelated preferences alone.
Disabling embedded SSH doesn't disconnect Tailscale, install or start an ordinary OpenSSH server, or revoke separately authorized SSH keys. Tailscale SSH doesn't modify your ordinary SSH server configuration or authorized-key files.
When embedded SSH is enabled, Tailscale takes over port 22 on the device's Tailscale address. Traffic there reaches Tailscale's server instead of the ordinary SSH server, even when you use a normal ssh client. After host opt-out, ordinary SSH can use Tailscale as its network layer if the server's listening address, authentication, network policy and host firewall permit it.
Check the setting and test a fresh login
Use two separate checks: the local preference and a fresh ordinary SSH connection. Test only devices and accounts you're authorized to use, and keep your independent recovery path available until the fresh login works.
1. Check the destination's SSH preference.
On the Linux or supported open-source macOS destination, run:
tailscale get ssh
Confirm that the preference is false. This shows the local setting is off, not that every SSH access path is closed. The command shows preferences for the currently connected tailnet.
If your command-line client doesn't recognize get, that isn't a disabled result. Check the toggle through an already authorized device web interface.
2. Open a fresh ordinary SSH connection.
From an authorized Linux or macOS client with OpenSSH and network access to the destination, run:
ssh user@destination
Replace user with your account name and destination with the device's Tailscale address. A successful login shows that this client and account can connect through that path. It doesn't show that every user has access. Don't bypass host-key warnings. Ordinary SSH may present a different host key, which is the server identity your client checks. Verify it through your trusted console or another established access path before accepting it.
3. Check which server handled the login.
Check the ordinary SSH server's authentication records for the account and authentication method used. Together with the false preference, this helps confirm that your intended fallback works.
If login fails, use your recovery path to check the ordinary server, credentials, listening address, network policy and firewall. A failed connection alone doesn't prove embedded SSH is disabled.
Remove embedded SSH across your tailnet
Coordinate with device owners and use authorized administrative access. Save the current policy and confirm recovery access before you change hosts or rules.
1. Opt out every enabled host.
On each Linux or supported open-source macOS destination, run:
tailscale set --ssh=false
Changing one destination doesn't disable embedded SSH on the others.
2. Remove the Tailscale SSH access rules.
An Admin or Network admin should remove the Tailscale SSH rules through Access controls. Keep unrelated network rules if users should still reach those devices.
Policy removal stops authorization through embedded SSH. It doesn't replace host opt-out when you want ordinary SSH to handle port 22 again. Revoking SSH policy access stops affected existing SSH sessions.
3. Check each destination before closing recovery access.
Confirm the host's SSH preference is false. Then test the intended ordinary SSH access with a fresh login and check the server's authentication records.
Keep recovery access available until those checks succeed on each destination.
Choose what access you actually want to stop
These controls affect different parts of access, so choose the one that matches your goal.
| Your goal | Control used | Remaining access |
|---|---|---|
| Disable one embedded server | Host opt-out | Ordinary SSH if permitted |
| Remove embedded authorization | Remove SSH access rules | Unrelated network access |
| Block the SSH network path | Restrict SSH port access | Other ports and routes |
| Block incoming tailnet traffic | Block incoming connections | Other access routes |
| Remove tailnet reach | Disconnect Tailscale | Non-Tailscale access routes |
A network restriction blocks the SSH path only when no other matching allowance permits it. It can block either SSH server on that path, but it doesn't revoke credentials or close other routes. Blocking all incoming tailnet connections is broader and can affect services besides SSH.
If you want to revoke a person's access, also review independently authorized SSH keys and other routes. If you only want to disable embedded Tailscale SSH, keep Tailscale connected and confirm both the disabled setting and your fresh fallback login.