Debian Bug report logs - #297173
Please support name-based virtualhosting (yes, I know it's "impossible")

Reply or subscribe to this bug.

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Andras Korn <korn-debbugs@chardonnay.math.bme.hu>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: Please support name-based virtualhosting (yes, I know it's "impossible")

Date: Sun, 27 Feb 2005 19:06:59 +0100

Package: openssh
Severity: wishlist

Hi,

it'd be useful if ssh did name-based virtualhosting, for example if you
provide services on top of ssh where it's irrelevant what physical box the
service resides on: e.g. subversion. If name-based virtualhosting were
supported, it would be possible to move a repository from one physical host
to the other, change DNS, and the clients would transparently begin using
the new server.

This is currently impossible without also changing the host key of the new
host to be the same as the old one (otherwise the clients report that the
host key changed). Changing the host key of the new server may, however,
have adverse side effects if the server isn't really "new", just the new
home of the repository.

What I propose is to have one host key per 'virtualhost', and possibly also
per-virtualhost config settings (e.g. command="svnserve -t" for an entire
virtualhost). Obviously the client would have to tell the server what
virtualhost it wanted to connect to before keys are exchanged.

I realize this is difficult to do and requires major changes to the code and
the protocol. Feel free to add a wontfix tag; I just wanted to publicize
this idea in the hope someone will like it enough to surmount the
difficulties.

Best regards,

Andras

-- 
                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/>	QOTD:
   If debugging is removing bugs, then programming must be putting them in.

Message #8 received at 297173-submitter@bugs.debian.org (full text, mbox, reply):

From: chrysn <chrysn@fsfe.org>

To: 297173-submitter@bugs.debian.org, 297173-subscribe@bugs.debian.org

Subject: possible solution: ssh srv records

Date: Mon, 24 Mar 2014 16:12:14 +0100

[Message part 1 (text/plain, inline)]

a possible solution to this problem that does not involve changing the
protocol would be using SRV dns records.

---------------

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.

a SRV record allows load balancing (when equal priorities are used),
fallback (with different priorities) and selecting the port. the latter
feature is what helps here: the server would have different daemons
running on different ports, and does name based dispatch in dns instead
of ssh.

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


both the original problem and this possible solution are things that
would have to be taken upstream.

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.


-----------------

andras, would this solve your problem?

best regards
chrysn

[1] https://gist.github.com/taylor/1372925

[signature.asc (application/pgp-signature, inline)]

Message #13 received at 297173@bugs.debian.org (full text, mbox, reply):

From: Andras Korn <korn-debbugs@elan.rulez.org>

To: chrysn <chrysn@fsfe.org>, 297173@bugs.debian.org

Subject: Re: Bug#297173: possible solution: ssh srv records

Date: Mon, 24 Mar 2014 16:40:04 +0100

On Mon, Mar 24, 2014 at 04:12:14PM +0100, chrysn wrote:

> [srv record based solution that puts different virtualhosts on different
> tcp ports] 
>
> andras, would this solve your problem?

While it looks like a good idea, it wouldn't solve my specific problem as I
can't depend on ports other than 22 being reachable by my clients.

Still, thanks for taking the time to think about it!

Andras

-- 
               A nation is just a society for hating foreigners.

Message #18 received at 297173@bugs.debian.org (full text, mbox, reply):

From: chrysn <chrysn@fsfe.org>

To: Andras Korn <korn-debbugs@elan.rulez.org>

Cc: 297173@bugs.debian.org

Subject: Re: Bug#297173: possible solution: ssh srv records

Date: Mon, 24 Mar 2014 18:26:52 +0100

[Message part 1 (text/plain, inline)]

On Mon, Mar 24, 2014 at 04:40:04PM +0100, Andras Korn wrote:
> While it looks like a good idea, it wouldn't solve my specific problem as I
> can't depend on ports other than 22 being reachable by my clients.

that sounds like a very exotic case, but yeah, in this case, you really
need in-protocol virtual hosts.

> Still, thanks for taking the time to think about it!

for the idea not to get lost, my last mail is now tracked as [1] in
openssh's bug tracker.

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

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.