[Bug 2217] New: allow using _ssh._tcp SRV records

bugzilla-daemon at mindrot.org bugzilla-daemon at mindrot.org
Tue Mar 25 04:23:27 EST 2014


https://bugzilla.mindrot.org/show_bug.cgi?id=2217

            Bug ID: 2217
           Summary: allow using _ssh._tcp SRV records
           Product: Portable OpenSSH
           Version: 6.5p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: chrysn at fsfe.org

i think it would be a good idea for ssh to look up _ssh._tcp records to
allow virtual services.

how it would work
=================

whenever an ssh connection is created, instead of looking up the A/AAAA
record of the hostname, _ssh._tcp.${hostname} is queried for SRV
records. if one exists, the request is resolved further by the usual
rules of SRV records; otherwise, an A/AAAA record is used.

an SRV record allows load balancing (when equal priorities are used),
fallback (with different priorities) and (which is what i'd use it for)
selecting the port.

how it (doesn't) affect security
================================

ssh is used to relying on insecure dns before creating a secured
connection. if an SRV record is used, the original hostname (without
the
_ssh._tcp part, ie. what the user requested) should be used as the
default HostKeyAlias. this allows migration to and from plain dns hosts
without disturbing existing known_hosts files.

basically, treat the dns resolver like a rogue dns server. if it
redirects us to a place where the server can present the correct
fingerprint, we're fine, if not, we detect it.

of course, if more than one SRV record exists, the same host key has to
be present on multiple servers. this is the same situation as with
migrating servers where admins copy the old ssh key to the new machine;
whether this is acceptable or not is up to the administrator's
discretion, and most likely depends on how he distributes his
known_hosts data.

i don't know how this would interact with ssh keys verified via
dns-sec,
if that is a thing.

existing implementations
========================

so far, i've only seen _ssh._tcp records in SRV record examples, for
discovering local services (when it's not ssh itself that uses it,
programs like nautilus that display connectable machines nearby), and
an
ssh wrapper at [1].

as a side effect, this would add SRV support to all other protocols
that
rely on ssh (eg rsync and git). they might want to override the prefix
(maybe _ssh+git._tcp), but then again, that prefix would have to be
stored in known_hosts.


(this text was originally written for https://bugs.debian.org/297173;
as it will not be followed furthere there for unrelated reasons,
reporting it here directly)

note on relationships with other bugs: SRV records were mentioned in
bug #1742, but afaict don't belong there, as getaddrinfo will not
resolve SRV records. that bug brings up the good point about ports,
though. i think that the port in an SRV record should never end up in a
known_hosts file, because what matters is the user's intention ("i want
to connect to the service i know as git.example.com (whereever it
currently resides)"), not the implementation. specifying an explicit
port should probably disable SRV lookups.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.


More information about the openssh-bugs mailing list