SRV lookup support (Bugzilla 2217)

Mara Sophie Grosch littlefox at
Thu Feb 18 11:00:41 AEDT 2021


>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
>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

Am 18. Februar 2021 00:52:40 MEZ schrieb Damien Miller <djm at>:
>On Mon, 15 Feb 2021, Mara Sophie Grosch wrote:
>> 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`
>> 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].
>> figured, discussing this here is probably better, since it's not only
>> change for non-OpenBSD OpenSSH.
>> I would love comments about my approach and about changes that would
>> 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.
> [Snipped]
>As a practical matter, your changes need some stylistic tweaks to
>match the formatting style we use (,
>but that's very much a secondary consideration.

Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

More information about the openssh-unix-dev mailing list