![\"Project](\"https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed\")
Last validated: Jan 12, 2026
\nThe secure shell protocol, or SSH, has been around now for over 25 years. It was designed to securely connect to a\r\nserver for remote access, directly running commands, or file transfers (using the scp or sftp applications). SSH is a\r\nreplacement for telnet, rlogin, rcp, rsh and ftp, which were used to perform similar tasks. Those protocols\r\nare rarely used today even though some of them eventually added extensions for encryption. There are several open source\r\nSSH clients available today for virtually every operating system.
Today, it's well known that unprotected data transfers over the public internet or open Wi-Fi networks are dangerous;\r\ntransmissions can be intercepted or modified. The SSH protocol is a useful tool for addressing this problem by creating\r\na secure remote access connection using encryption, but comes with some caveats.
\nIf you need to remotely access a server or transfer files, SSH encrypts what you need to send over a public network.\r\nIt's based on a rigorously tested protocol, while being easy to use and highly configurable.
\nAn SSH client is a local application that is used to connect to a remote computer, typically for secure logins as well\r\nas secure file transfers. This functionality is provided by the secure shell protocol, which is a cryptographic network\r\nprotocol.
\nSSH also has VPN-like capabilities built into it: SSH supports port forwarding (the client can ask the remote SSH server\r\nto forward an outgoing connection), reverse port forwarding (the client can request that the remote SSH server forward\r\nan incoming connection), dynamic port forwarding (the client creates port forwarding connections on-demand using the\r\nSOCKS protocol) and tunnel device forwarding (the client and server can relay packets to each other, which when combined\r\nwith additional configuration can act as a VPN).
\nSSH has some less frequently used features that are sometimes disabled as they can be security concerns: it can forward\r\nX11 connections (showing remote graphical applications on your client machine) and forward its authentication agent\r\n(which permits connecting to other SSH servers using the saved credentials from your client machine).
\nAll the SSH features can be used simultaneously, enabling the use of multiple sessions over one connection. If a new\r\nsession is desired (and the SSH client supports that feature), then it can attach to an existing connection without\r\nneeding to re-authenticate, which can be very convenient.
\nTo use SSH securely, users first need to verify the host key of the server they're trying to reach. If the host key is\r\nnot checked, there is no proof that the user is connecting to the server that they expected. The SSH server then needs\r\nto verify either the user's password or authentication key. If the SSH server only accepts connections from a private\r\nnetwork (either because the server is behind a NAT router or to improve security), the user also needs to connect\r\nthrough another server connected to both the public internet and the private network, usually known as an SSH bastion but\r\nsometimes called an SSH jump host, or SSH jump box.
\nUsed alone, following SSH best practices can be difficult: host keys are often left unchecked, user keys and passwords\r\nare rarely rotated, and connecting through an SSH bastion can be inconvenient. Tailscale can help mitigate the first two\r\nissues and avoid the last issue entirely.
\nAlthough you can permit SSH connections from the public internet, any public SSH server will be subject to automated and\r\npossibly targeted attacks. The automated login attempts often begin within minutes: there are many compromised servers\r\nthat are constantly scanning the public internet for SSH servers with easily guessed usernames and passwords. The\r\ngreatest risk comes from weak passwords, which is why the modern best practice is to disable passwords entirely.
\nThere is also a smaller risk of compromise through bugs in the SSH server software. Known bugs in older versions of SSH\r\nserver software may allow unauthorized access, and there is always the risk of new bugs being discovered in up-to-date\r\nsoftware. An administrator must ensure that the server is kept up-to-date.
\nWhile authentication keys are a stronger alternative to passwords, SSH doesn't force users to ever rotate\r\nkeys. In practice, almost no one does. Worse, SSH authentication private keys are often stored as normal\r\nfiles, making them easy to copy. This puts many SSH servers at risk, as the possibility of an authentication key being\r\nstolen increases over time as the server accumulates infrequently or never rotated authentication keys.
\nAuthentication keys stored on a hardware token (such as those sold by Yubikey, Touch ID, smart cards, and other FIDO2\r\ntokens) cannot be copied, which significantly reduces the risk of the authentication key being stolen: the token must be\r\nphysically taken (making purely remote attacks difficult or impossible). Hardware tokens are an excellent choice when\r\navailable, but it can be expensive to supply them to all employees and provisioning them is extra administrative\r\noverhead: each token generates its own authentication key and the tokens themselves can be misplaced, lost or stolen.\r\nThe price of these tokens has dropped over time but their use is still unfortunately not ubiquitous.
\nSome SSH servers can authenticate sessions using certificates from a trusted private certificate authority. Certificates\r\ncombine normal authentication keys with a signature from the certificate authority and an expiration time. The main\r\ndifference from normal authentication keys is that the server only needs to store the certificate authority's public key\r\nand trusts that users' authentication keys are acceptable if the certificate authority has issued a certificate. This\r\nsolves the biggest usability issue of key rotation: updating the servers is no longer required. Additional security\r\ncomes from automatically enforced key rotation because the certificates expire. A certificate authority can also sign\r\nSSH host keys, which addresses the problem of verifying the host key when a user connects, as long as the SSH client\r\ntrusts the certificate authority.
\nSetting up the certificate authority infrastructure required to grant, revoke and manage certificates is quite complex\r\nand the certificate authority's private key must be very well protected. Today, certificates for SSH are not commonly\r\nused outside of large enterprises.
\nAn SSH bastion (sometimes called an SSH jump host or SSH jump box) is used by some organizations or users as a gateway to\r\na protected internal network. Users must connect to this bastion first before they can access the protected servers. The\r\nbastion typically has extra monitoring in place to detect intrusions. Unfortunately, bastions are often inconvenient,\r\nhigh-latency and cannot get at the root of the key rotation problem without additional administrative controls.
\nTailscale works well with SSH clients and SSH servers, improving security and offering a better user experience.
\nIf you have a global footprint, your traffic might have to traverse a long distance to pass through the bastion before\r\nreaching the SSH server, adding significant latency and sometimes limiting throughput as well. Alternatively, you can\r\noperate multiple bastions, which adds complexity.
\nTailscale removes the need for a bastion entirely by keeping SSH servers on a private mesh network that has\r\npeer-to-peer connections and end-to-end encryption. Not only is SSH more secure this way, it's also typically faster\r\nthan using a bastion.
\nWhile Tailscale does not manage your SSH authentication keys, it does manage access to the private network that permits\r\naccess to the SSH servers. The Tailscale client rotates its keys according to a\r\nconfigurable time interval.
\nIf a client device is lost or stolen, the device can be immediately deleted from the admin console. If not deleted from\r\nthe admin console, then when the device's key expires, it can no longer access the Tailscale network. In either case, the\r\ndevice loses access until an authorized user successfully logs back into the Tailscale client. Multifactor\r\nauthentication is required during login if enabled in your SSO configuration, providing additional security.
\nNormally upon first connection to an SSH server you are shown the SSH host key and you are expected to verify that the\r\nkey is correct (most SSH clients save the host key after the first connection). If the key is not correct, that is an\r\nindication that your connection was intercepted by some other server.
\nTailscale's server distributes public Tailscale key information to all the Tailscale clients and ensures that if you\r\nsuccessfully connect to a Tailscale IP address, you are connected to the correct device, not an imposter. Therefore\r\nalthough it is still best practice to verify the SSH host key, you can be assured that the connection is not being\r\nintercepted.
\nTailscale also helps the SSH server verify the identity of the user connecting to it. When a Tailscale IP address\r\nappears in the server's logs, an administrator can later look up which user that IP address belongs to. For maximum\r\nsecurity, the SSH server can be configured to restrict which IP addresses a username can connect from. Since the\r\nTailscale IP address of a user's device remains fixed unless it is deleted from the Tailscale network, this can be used\r\nas additional proof of the user's identity.
\nNormally when using SSH, anyone on a public or private network can try to connect to the SSH server. Using SSH with\r\nTailscale, only people who are part of your network and authorized by your network's access control policies can connect to the SSH server.\r\nBy removing SSH access from the public internet, the risk posed by automated scanning attacks (or\r\nrandom users trying to connect to your SSH server) is eliminated because there is nothing for them to connect to.
\nTailscale access control policies ensure that only authorized users have access to connect to the SSH server. By explicitly stating\r\nwhich users are allowed to access the SSH server, it is significantly more difficult to be compromised by a stolen\r\nauthentication key or weak password (however this is not a substitute for managing authentication keys and passwords).
\nThe Tailscale client is able to detect network changes and can switch which network connection it uses to reach other\r\nTailscale clients without affecting the applications using the Tailscale network. In other words, if you switch between\r\nEthernet and Wi-Fi, between Wi-Fi networks, or between Wi-Fi and a cellular network, then if your SSH client is\r\nconnected through Tailscale, it may pause briefly but will stay connected (assuming that the network switch occurs\r\nreasonably quickly).
\nTailscale SSH lets Tailscale manage the authentication and authorization of SSH connections in\r\nyour tailnet.
\nWith Tailscale SSH, you can:
\nroot), to re-authenticate before connecting. This lets the user access these high-risk applications for the next 12 hours or for a specified check period before re-authenticating again.If you want to use Tailscale SSH for your SSH needs, follow the instructions at Configure Tailscale SSH. Otherwise, continue to the\r\nnext section.
\nThese steps are an alternative to using Tailscale SSH.
\nTo get started:
\nTailscale is available for essentially any modern Linux distribution, though the installation instructions may vary slightly.
\n\nFor more sophisticated access controls, consider using ACLs or grants. If desired,\r\nconfigure the SSH server with an tag.
\nOn the SSH server, look up its Tailscale IP using tailscale ip. Assuming that your account name is username and the\r\nIP address is 100.100.123.123:
ssh username@100.100.123.123\nIf MagicDNS is enabled on your Tailscale network, simply connect to the SSH\r\nserver's hostname. For example, for a server named myserver: ssh username@myserver
Ask AI
\nreCAPTCHA
\nRecaptcha requires verification.
\nprotected by reCAPTCHA
\n"}