Background
A tailcat address is a secret bearer capability: it contains the tunnel's pre-shared key, so anyone who has the address can connect to the server. The README says this, and the DNS TXT record feature exists so that a protected server (one using --allow to restrict tunnel clients by node key, or tailcat serve ssh with --ssh-authorized-keys) can be given a memorable public name.
Problem
The pieces compose in a way that's easy to get wrong. If someone runs:
$ tailcat serve no-auth-ssh
and publishes the printed address in a public DNS TXT record, they have given a shell on that machine to anyone who queries the record. DNS TXT records are public and are actively scanned. Nothing in the tool or the docs stops this combination today: the "Protected SSH server over DNS" example in the README does use --allow, but the connection between "address in DNS" and "server must authenticate clients by something other than possession of the address" is implied rather than stated, and it's evidently easy to miss.
Proposed changes
-
README: add explicit, prominent warnings that a tailcat address published in DNS (or anywhere public) is no longer a
secret, so the server behind it must require client authentication: --allow at the tunnel layer, or --ssh-authorized-keys at the SSH layer. State plainly thatno-auth-ssh plus a public TXT record means anyone on the internet gets a shell.
-
Active check in tailcat ssh: when the destination is a DNS name (rather than a pasted address), before running the real SSH session, probe the server the way a stranger would: connect with a fresh ephemeral node key and attempt an SSH handshake with a fresh ephemeral SSH key, requesting no command and no PTY. If the server accepts that authentication, refuse to continue and print a warning explaining that anyone who reads the TXT record can log in, with pointers to --allow and --ssh-authorized-keys. A new --acknowledge-insecure-wide-open-dns flag or something scary like that skips the check for anyone who really means it.
The probe can't catch someone who publishes an open server in DNS and never connects to it themselves, but the common path is to test your own server right after setting it up, and that first test is the right moment to catch the misconfiguration.
Background
A tailcat address is a secret bearer capability: it contains the tunnel's pre-shared key, so anyone who has the address can connect to the server. The README says this, and the DNS TXT record feature exists so that a protected server (one using
--allowto restrict tunnel clients by node key, ortailcat serve sshwith--ssh-authorized-keys) can be given a memorable public name.Problem
The pieces compose in a way that's easy to get wrong. If someone runs:
and publishes the printed address in a public DNS TXT record, they have given a shell on that machine to anyone who queries the record. DNS TXT records are public and are actively scanned. Nothing in the tool or the docs stops this combination today: the "Protected SSH server over DNS" example in the README does use
--allow, but the connection between "address in DNS" and "server must authenticate clients by something other than possession of the address" is implied rather than stated, and it's evidently easy to miss.Proposed changes
README: add explicit, prominent warnings that a tailcat address published in DNS (or anywhere public) is no longer a
secret, so the server behind it must require client authentication:
--allowat the tunnel layer, or--ssh-authorized-keysat the SSH layer. State plainly thatno-auth-sshplus a public TXT record means anyone on the internet gets a shell.Active check in
tailcat ssh: when the destination is a DNS name (rather than a pasted address), before running the real SSH session, probe the server the way a stranger would: connect with a fresh ephemeral node key and attempt an SSH handshake with a fresh ephemeral SSH key, requesting no command and no PTY. If the server accepts that authentication, refuse to continue and print a warning explaining that anyone who reads the TXT record can log in, with pointers to--allowand--ssh-authorized-keys. A new--acknowledge-insecure-wide-open-dnsflag or something scary like that skips the check for anyone who really means it.The probe can't catch someone who publishes an open server in DNS and never connects to it themselves, but the common path is to test your own server right after setting it up, and that first test is the right moment to catch the misconfiguration.