SRV lookup support (Bugzilla 2217)
Mara Sophie Grosch
I'm new on this list and on the contribution side to this project, so
please be gentle.
I want to tackle SRV lookup support in OpenSSH client, especially for
the use case of non-standard ports on the server - which is a part of
Bugzilla 2217 [1].
For that, I made a first implementation, hooking into `resolve_host` in
ssh.c, calling a new `resolve_srv` if no port is given on the command
line or config. Full patch is available as pull request on github[2]. I
figured, discussing this here is probably better, since it's not only a
change for non-OpenBSD OpenSSH.
I would love comments about my approach and about changes that would be
required for this to be merged - or discussion about how to better
approach this. Only invested an evening so far, so starting a new
wouldn't be a big problem if results are a lot better :)
Thanks and best regards
Mara Sophie Grosch
[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2217
[2] https://github.com/openssh/openssh-portable/pull/228
_______________________________________________
openssh-unix-dev mailing list
openssh-...@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Damien Miller
> Hi there,
>
> I'm new on this list and on the contribution side to this project, so
> please be gentle.
>
> I want to tackle SRV lookup support in OpenSSH client, especially for
> the use case of non-standard ports on the server - which is a part of
> Bugzilla 2217 [1].
>
> For that, I made a first implementation, hooking into `resolve_host` in
> ssh.c, calling a new `resolve_srv` if no port is given on the command
> line or config. Full patch is available as pull request on github[2]. I
> figured, discussing this here is probably better, since it's not only a
> change for non-OpenBSD OpenSSH.
>
> I would love comments about my approach and about changes that would be
> required for this to be merged - or discussion about how to better
> approach this. Only invested an evening so far, so starting a new
> wouldn't be a big problem if results are a lot better :)
Thanks for working on OpenSSH!
wrt the acceptability of this feature, I don't have a good sense of how
much demand there is for it and how that balances against adding more
complexity to the already pretty fiddly name resolution stuff that
happens before connect.
Secondly, if we do go ahead with it then we need to decide whether it
should be on by default. I don't think that allowing a DNS owner/attacker
to silently redirect traffic to a different port brings any new risk
(after all, they could already send it to an entirely different host)
but maybe I'm missing something...
As a practical matter, your changes need some stylistic tweaks to
match the formatting style we use (http://man.openbsd.org/style.9),
but that's very much a secondary consideration.
-d
Mara Sophie Grosch
>Secondly, if we do go ahead with it then we need to decide whether it
>should be on by default. I don't think that allowing a DNS
>owner/attacker
>to silently redirect traffic to a different port brings any new risk
>(after all, they could already send it to an entirely different host)
>but maybe I'm missing something...
I think if an attacker controls DNS, it's a lost game anyway. Current implementation uses the same SSH hostkey mechanism after all, adding a SRV record and moving SSH to another port still uses the hostkey already in the database. For new hosts, know the fingerprint or trust DNS on first connection - same as before. So, I think no added risk - but since it's another lookup, which might slow things down, having an option might be a good idea anyway. Thanks for that comment :)
RE demand, adding yet another feature: having a option, which is disabled by default at first to check demand, might help enough with runtime cost. Maintenance cost is another thing though. Hope there might be more comments from the list.
Thanks for the style guidelines, will look into it.
Best regards
Mara Sophie Grosch
> [Snipped]
>
>As a practical matter, your changes need some stylistic tweaks to
>match the formatting style we use (http://man.openbsd.org/style.9),
>but that's very much a secondary consideration.
>
>-d
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
Thorsten Glaser
> >(after all, they could already send it to an entirely different host)
> >but maybe I'm missing something...
>
> I think if an attacker controls DNS, it's a lost game anyway. Current
It’s still a level of indirection that isn’t traditionally used, and
which makes me a bit nervous, especially considering name resolution
is not just DNS (think /etc/hosts for example).
I’d prefer for this “feature” to be disabled by default and stay that
way.
bye,
//mirabilos
--
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database” (#nosec) ‣‣‣ Please let MySQL and MariaDB finally die!
James Bottomley
> On Thu, 18 Feb 2021, Mara Sophie Grosch wrote:
>
> > > (after all, they could already send it to an entirely different
> > > host) but maybe I'm missing something...
> >
> > I think if an attacker controls DNS, it's a lost game anyway.
> > Current
>
> It’s still a level of indirection that isn’t traditionally used, and
> which makes me a bit nervous,
The statement is a bit ambiguous, but I think you're saying SRV records
aren't traditionally used? That's simply not true. If you look at my
own host site, I have SRV records for a couple of protocols:
_matrix._tcp.hansenpartnership.com
_xmpp-client._tcp.hansenpartnership.com
_xmpp-server.._tcp.hansenpartnership.com
Whether you should have them for openssh is a different question, but
SRV is used as a requirement by several protocols today. Xmpp simply
won't work without them unless you happen to have a lucky domain setup
and matrix could use the .well-known/ URL instead, but having SRV
records is required for setups where WWW isn't run on the domain URL.
> especially considering name resolution is not just DNS (think
> /etc/hosts for example).
/etc/host only resolves A and AAAA records, so it would have no impact
on SRV records at all. It's actually annoying on one level because to
test out the functionality of SRV records you really do need a DNS
setup.
James
Thorsten Glaser
> > It’s still a level of indirection that isn’t traditionally used, and
^^^^^^^^^^^^
> SRV is used as a requirement by several protocols today. Xmpp simply
^^^^^
Do you see it?
> > especially considering name resolution is not just DNS (think
> > /etc/hosts for example).
>
> /etc/host only resolves A and AAAA records, so it would have no impact
> on SRV records at all.
That’s part of what makes me nervous. If foo.example.com has an SRV RR
and I add an entry for foo.example.com into /etc/hosts to temporarily
locally redirect it, does that mean the hosts entry will be ignored if
SRV RR usage is enabled?
I can’t see where this will end up in anything other than sysadmin
tears.
bye,
//mirabilos
--
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg
*************************************************
Mit unserem Consulting bieten wir Unternehmen maßgeschneiderte Angebote in
Form von Beratung, Trainings sowie Workshops in den Bereichen
Softwaretechnologie, IT Strategie und Architektur, Innovation und Umsetzung
sowie Agile Organisation.
Besuchen Sie uns auf https://www.tarent.de/consulting .
Wir freuen uns auf Ihren Kontakt.
*************************************************
John-Mark Gurney
> On Thu, 18 Feb 2021, James Bottomley wrote:
>
>
> > SRV is used as a requirement by several protocols today. Xmpp simply
> ^^^^^
>
> Do you see it?
SIP has been documented to use SRV records since June 2002:
https://tools.ietf.org/html/rfc3263
XMPP has perfered using SRV since 2011 (RFC6120):
https://tools.ietf.org/html/rfc6120#section-3.2.1
Just because **YOU** don't use it, doesn't mean that it isn't in wide
deployment and use.
I've been using SRV records for over 10 years now on my own domain:
date: 2010/11/12 04:12:47; author: jmg; state: Exp; lines: +2 -2
fix SRV record.. required to point to an A record...
and I've never had any issues with it either... It just works...
as you can tell my initial setup didn't work, but this was a fix
to a commit from 4 minutes earlier when I initially set it up..
> > > especially considering name resolution is not just DNS (think
> > > /etc/hosts for example).
> >
> > /etc/host only resolves A and AAAA records, so it would have no impact
> > on SRV records at all.
>
> locally redirect it, does that mean the hosts entry will be ignored if
> SRV RR usage is enabled?
>
> tears.
This is where ssh -v should be explicit and clear where it's getting
the IP address and where it's connecting. If you're system is poorly
configured, then yes, there will be issues w/ it, and option need to be
available to detect it, and fix them as well.
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
Ron Frederick
> On Thu, 18 Feb 2021, James Bottomley wrote:
>> /etc/host only resolves A and AAAA records, so it would have no impact
>> on SRV records at all.
>
> That’s part of what makes me nervous. If foo.example.com has an SRV RR
> and I add an entry for foo.example.com into /etc/hosts to temporarily
> locally redirect it, does that mean the hosts entry will be ignored if
> SRV RR usage is enabled?
>
> I can’t see where this will end up in anything other than sysadmin
> tears.
Keep in mind that SRV records typically point at hostnames, not directly at IP addresses. In fact, I’m not even sure they are allowed to point at IPs. So, there will still be a hostname lookup which occurs after the SRV record lookup, and that could potentially be resolved via /etc/hosts depending on the local system’s resolver configuration.
It’s also worth pointing out that one benefit of SRV records is that you can specify port information in them, if you want client to use a port other than the default one of 22, without the need to configure that on every client.
In my experience, SRV records are not set at the “host” level. They’re typically set at the domain level (e.g. example.com <http://example.com/>, not foo.example.com <http://foo.example.com/>), and they tell you which host(s) under that domain provide the service you are looking up, along with the port number to connect to on that host. You can also set a series of possible hosts, with weights for which ones to prefer.
--
Ron Frederick
ro...@timeheart.net
Jochen Bern
> SRV is used as a requirement by several protocols today. Xmpp simply
> won't work without them unless you happen to have a lucky domain setup
> and matrix could use the .well-known/ URL instead, but having SRV
> records is required for setups where WWW isn't run on the domain URL.
your domain name in the DNS *deserves* the eternal punishment of having
to support a personal fix for their hubris (a la SMTP and MX RRs), I do
*not* agree that SRVs are "required" to run a webserver today.
Through three different web design outfits and their favorite hosters
now, I have successfully upheld that binect.de points to an IP *we*
control and run a HTTP+HTTPS redirector to www.binect.de (and whatever
other stuff we want to be available as "binect.de") on. (Having your
content appear under a *single* FQDN is actually good for your SEO.)
Also, the range of "web browsers" is a tad too large - from FF, Edge and
the like to Konqueror to elinks and lynx to cURL and wget to debugging
with plain "telnet" or "openssl s_client" - to *consistently* obey SRV
RRs anytime soon.
Regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
James Bottomley
> On 18.02.21 20:22, James Bottomley wrote:
> > SRV is used as a requirement by several protocols today. Xmpp
> > simply won't work without them unless you happen to have a lucky
> > domain setup and matrix could use the .well-known/ URL instead, but
> > having SRV records is required for setups where WWW isn't run on
> > the domain URL.
>
> While I very much agree that any protocol/service that insists on
> pwning your domain name in the DNS *deserves* the eternal punishment
> of having to support a personal fix for their hubris (a la SMTP and
> MX RRs), I do *not* agree that SRVs are "required" to run a webserver
> today.
protocols. The general use case is where you have a multi-node domain
but you want to export the service at the domain level, so I want my
xmpp address to be 'je...@hansenpartnership.com' not
'je...@nodeX.hansenpartnership.com' and to do that, I need SRV records.
The same goes for matrix (except my id is @jejb:hansenpartnership.com)
> Through three different web design outfits and their favorite hosters
> now, I have successfully upheld that binect.de points to an IP *we*
> control and run a HTTP+HTTPS redirector to www.binect.de (and
> whatever other stuff we want to be available as "binect.de") on.
> (Having your content appear under a *single* FQDN is actually good
> for your SEO.)
obviates the need for SRV records usually (unless you're on non-
standard ports). However, once you want fault resiliency or load
balancing, you'll get forced to use them as well.
> Also, the range of "web browsers" is a tad too large - from FF, Edge
> and the like to Konqueror to elinks and lynx to cURL and wget to
> debugging with plain "telnet" or "openssl s_client" - to
> *consistently* obey SRV RRs anytime soon.
well behaved. The fact that most browsers aren't that well behaved is
sadly true but orthogonal.
Mara Sophie Grosch
On Feb 18, 2021, at 11:28 AM, Thorsten Glaser <t.gl...@tarent.de>
wrote:
> On Thu, 18 Feb 2021, James Bottomley wrote: I can’t see where this
> will end up in anything other than sysadmin tears.
Though the same argument applies to A vs AAAA records and any new
technology, having this as an option that defaults to off seems like a
good idea anyway and would help against this.
On Thu, Feb 18, 2021 at 11:56:48AM -0800, Ron Frederick wrote:
>Keep in mind that SRV records typically point at hostnames, not
>directly at IP addresses. In fact, I’m not even sure they are allowed
>to point at IPs. So, there will still be a hostname lookup which occurs
>after the SRV record lookup, and that could potentially be resolved via
>/etc/hosts depending on the local system’s resolver configuration.
>
>It’s also worth pointing out that one benefit of SRV records is that
>you can specify port information in them, if you want client to use a
>port other than the default one of 22, without the need to configure
>that on every client.
>
>In my experience, SRV records are not set at the “host” level. They’re
>typically set at the domain level (e.g. example.com
><http://example.com/>, not foo.example.com <http://foo.example.com/>),
>and they tell you which host(s) under that domain provide the service
>you are looking up, along with the port number to connect to on that
>host. You can also set a series of possible hosts, with weights for
>which ones to prefer.
Being able to specify custom ports (and not having users configure it)
is the reason I'm working on it, also the primary reason for the initial
feature request. I'm thinking of running Git+SSH without having to
dedicate an IP or have it fiddle with my systems configuration.
Also fits something like Github (or any large Git+SSH deployment) more
closely: SSH is a service provided by lots of hosts which may have
different priorities (the current patch only uses the highest-prio host
though).
I hope to get some more comments about SRV records with SSH and not
about if SRV records in general are useful?
-- Mara
Ron Frederick
I see the potential usefulness of this. Given how many other ways there already here to determine the hostname, though, and the extra delay which may be introduced to do the SRV record lookup, I think it should probably be disabled by default. Even with it enabled, it probably shouldn’t trigger the lookup in cases where the ‘Hostname’ option is already set in configuration. In cases where that’s specified, I think that value should be used directly if it is an IP address, and trigger only normal A/AAAA/CNAME resolution if it is a name.
Something else to consider is how this interacts with the various Canonicalize config options. Are those applied to the name before doing the SRV record lookup? If a short hostname is given, that might be needed, but that means you’d be potentially looking up multiple SRV entries. Also, there’s a question of what wins if one of the domains in CanonicalizeDomains has an SRV record but another one has a CNAME or A/AAAA record with no SRV. Do you try all the domains for SRV records before looping back around to look for CNAME/A/AAAA records? That’s getting pretty complicated.
Since SRV records return a port number, you’d also need to consider what happens when no hostname is specified in config but a port number is. Do you still look up the SRV record in that case and use the hostname and port from there, ignoring the port in config, use the hostname from the command line with the port from the config, or use the hostname from the SRV record but override the port and use the port from the config? I don’t really like mixing and matching hostname and port from two different places, so perhaps the presence of either a hostname or a port in config should be enough to disable SRV record lookups.
--
Ron Frederick
ro...@timeheart.net