Bug 2357

Hi.

Given that SSH is such a nice protocol and that the FLOSS community has such a great implementation with OpenSSH, the protocol is used in many places far beyond the traditional "remote shell".


For many of these it would be interesting to have vhosting like capabilities, i.e. that multiple "addresses" point to one physical node (where the sshd runs) and one can set options/change behaviour depending on the "address" that the clients actually chose.

Unlike e.g. http where there is a "Host:" header or TLS where there is SNI, we (AFAIK) only know about the IP address/port that a client uses to connect.
But for vhosting many cases this would already be enough, and especially with the rise of IPv6, everyone will have "unlimited" addresses.


Right now, one can already set quite a number of options based on the address a client connects to, e.g. via
Match LocalAddress ....
unfortunately though this isn't possible yet, for some options that would be crucial for vhosting, most notably:
HostKey


Example (why this would be so useful):
A server, which runs ssh to provide admins the remote shell.
It also runs via-ssh services, like git.

At first this isn't much of a problem: Even if I want my git users to use another domainname (e.g. git.example.org) than what the admins use to connect to the node (e.g. host123.example.org)... this works out, because nothing forbids the same host key to be used for multiple addresses.

But when one starts to do more advanced things like the following, one runs into the limitation:
Consider I do not only wish one host behind git.example.org, but rather a round-robin-DNS set (for availability or whatever).
So I'd have distinct servers like:
a.git.example.org
b.git.example.org
and so on and git.example.org points to all of them.

Then consequence, for authentication to work with "git.example.org" is that all hosts needed to use the same keys... which is a bad idea.
If one host is compromised, all could be attacked... for the "git" user, which is anyway just via some restricted system (git-shell or gitolite) reachable... this wouldn't be that big problem.
But for the other use case of these SSH's i.e. access to the systems for admins... this would be quite bad.


Right now, the only way to solve this is by running multiple sshd with different config files and so on.
I guess that works, but if it would be easy to make HostKeys configurable per LocalAddress, that would simply things quite a bit for the admins :)


Of course it would also be nice if further options like the Alogs, Compression, UsePam, uselogin,... etc. could be set on a per user / per localaddress basis.
But I'm not sure how easy that would be.


Best wishes,
Chris.