cmd/tailcat, README.md: warn when a DNS-named SSH destination is wide open - #101
Merged
Conversation
… open A tailcat address published in a DNS TXT record is public, so the server behind it must authenticate clients by something other than possession of the address (--allow or --ssh-authorized-keys). People were missing that connection and publishing no-auth-ssh servers in DNS, handing a shell to anyone who reads the record. Make the README say this explicitly in every section that touches DNS TXT records or auth-free SSH, and make "tailcat ssh" catch the misconfiguration: before connecting to a DNS-named destination, probe the server the way a stranger would, with a freshly generated node key and no SSH credentials, only the "none" auth method that the no-auth-ssh service accepts. The probe authenticates only, with no command or PTY request. If the server accepts the stranger, refuse to connect and explain how to lock it down, unless the new --skip-dns-safety-check flag is set (which also saves the probe's round trips). Probe failures are not fatal: a --allow-protected server ignores strangers entirely, so the probe just times out and the real connection proceeds. This can't catch someone who publishes an open server and never connects to it, but the common path is to test your own server right after setting it up, and the first such test now sounds the alarm. Fixes #100 Signed-off-by: Brad Fitzpatrick <bradfitz@tailscale.com> Change-Id: I3f8b2c9a1d6e4075b8a2c4d9e6f1a3b5c7d9e0f2
Member
fwiw, I don't think we've seen anyone actually do this? |
Member
Author
Yeah, I guess the "could've potentially been" was too implicit there. I think the intersection of:
... it zero. Many of those factors alone are basically zero. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A tailcat address published in a DNS TXT record is public, so the
server behind it must authenticate clients by something other than
possession of the address (--allow or --ssh-authorized-keys). People
were missing that connection and publishing no-auth-ssh servers in
DNS, handing a shell to anyone who reads the record.
Make the README say this explicitly in every section that touches
DNS TXT records or auth-free SSH, and make "tailcat ssh" catch the
misconfiguration: before connecting to a DNS-named destination, probe
the server the way a stranger would, with a freshly generated node
key and no SSH credentials, only the "none" auth method that the
no-auth-ssh service accepts. The probe authenticates only, with no
command or PTY request. If the server accepts the stranger, refuse
to connect and explain how to lock it down, unless the new
--skip-dns-safety-check flag is set (which also saves the probe's
round trips). Probe failures are not fatal: a --allow-protected
server ignores strangers entirely, so the probe just times out and
the real connection proceeds.
This can't catch someone who publishes an open server and never
connects to it, but the common path is to test your own server right
after setting it up, and the first such test now sounds the alarm.
Fixes #100