openssh bugs - Mar 2014 - [Bug 2217] New: allow using _ssh._tcp SRV records

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.

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

Andr?s Korn <korn-mindrot.org at elan.rulez.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |korn-mindrot.org at elan.rulez
                   |                            |.org

--- Comment #1 from Andr?s Korn <korn-mindrot.org at elan.rulez.org> ---
FWIW, wrapsrv already offers a way of implementing this idea outside
ssh.

It would be even better to support something like SNI inside OpenSSH,
though: show the client the host key that matches the host it expects
to see.

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

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

Sorin Sbarnea <sorin.sbarnea at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sorin.sbarnea at gmail.com

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

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

Jeremy Saklad <stadium-cyclops.0i at icloud.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |stadium-cyclops.0i at icloud.c
                   |                            |om

--- Comment #2 from Jeremy Saklad <stadium-cyclops.0i at icloud.com> ---
This would be invaluable, particularly for services like Git.

I try to maintain strict separation between machines and the services
they provide, such that I can move the service to a different machine
without disrupting access. I also want to provide multiple methods of
access, such as through an onion service. I currently use these records
to convey that:

```
_ssh._tcp.git.saklad5.com. 604800 IN    SRV     0 0 22
yqxxaadd7hhmjzyier2jftbnzxw3ddvbm4ggz5y7yuxzmcxlpcmwdcyd.onion.
_ssh._tcp.git.saklad5.com. 604800 IN    SRV     1 0 22
baza.saklad5.com.
```

The principles of RFC 7673 and similar specs apply here: when using
DANE, OpenSSH must validate the delegation with DNSSEC then query SSHFP
records for the ultimate target. If any link in the chain of resolution
isn't secured, validation fails.

Assuming DNSSEC is used correctly, the records above should mean that
`ssh git at git.saklad5.com` is equivalent to `ssh git@
yqxxaadd7hhmjzyier2jftbnzxw3ddvbm4ggz5y7yuxzmcxlpcmwdcyd.onion:22`,
falling back to `ssh git at baza.saklad5.com:22`. In keeping with RFC
7686, OpenSSH would immediately skip the onion address unless
configured with Tor support.

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

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

Celeste Liu <CoelacanthusHex at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |CoelacanthusHex at gmail.com

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

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

chrysn at fsfe.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|allow using _ssh._tcp SRV   |Allow using _ssh SVCB
                   |records                     |records

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

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

--- Comment #3 from chrysn at fsfe.org ---
With the advent of RFC9460, I've updated the title (sorry for the
double edit) to using SVCB records instead of SRV.

While the essence stays the same, SVCB records are described better,
especially with respect to their security properties, and provide more
flexible metadata, so I think they are the way to go.

How it would work (2023 edition)
===============================
* When connecting to a hostname host.example.com, SSH sends in parallel
(as it does A and AAAA records) a request for `SVCB
_ssh.host.example.com`. If the recursive resolver didn't already follow
the chain of alias records and eventually A(AAA) records, it follows
them on its own through the mechanism described in RFC9460.

* SSH selects any of the lowest priority results (usually just "the"
result, and IIRC from the RFC it's fine to just try one; failover can
still be added later). If specified it picks the port from it, and
connects to that address and port.

Complications
============
IIUC there should be a spec for using SSH with SVCB before using it --
at least there needs to be an entry in "Underscored and Globally Scoped
DNS Node Names"
<https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names>.
I'm happy to help out with the paperwork there (even if it means
writing an internet draft), but I won't take any action unless there is
at least a friendly snort from the SSH community indicating that it
would be taken up.

Side benefits
============
I've mentioned the convenience of server-configured ports in the
original report already. With the state of the IPv6 migration, SVCB
records (or anything that allows server configured ports) bring
additional benefits: Some users' ISPs offer only either static IPv4
addresses and no IPv6, or regular IPv6 but CGNAT. This forces users who
need to reach their home servers (eg. from a work environment that has
no IPv6 yet) into a no-IPv6 situation. If they can use PCP, they can
open ports locally, and PCP will tell them a public IP address and port
(generally not 22, and generally neither stable) to use. Using dynamic
DNS and SVCB records, they can publish their home address including the
port on a stable location.

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

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

--- Comment #4 from Jeremy Saklad <stadium-cyclops.0i at icloud.com> ---
I agree that SVCB is the way to go in the future. One nuance: in
keeping with
<https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-dane/>, I think
SSHFP records should be requested for the target server, and only used
if the SVCB records are also secured with DNSSEC.

SSHFP records could also be designated for automatic retrieval similar
to A/AAAA records, with the support of resolvers.

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