"Virtual hosts" for ssh

[Nico Kadel-Garcia]

On Jun 8, 2013, at 11:14, Dan Kaminsky <dan at doxpara.com> wrote:

> 
> 
> Sent from my iPhone
> 
> On Jun 8, 2013, at 7:58 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
> 
>> On Fri, Jun 7, 2013 at 8:02 PM, Johannes Ernst <johannes.ernst at gmail.com> wrote:
>>> It'd be very cool if ssh supported something like Apache "virtual hosts". This would make it much more viable to host multiple installs of git on the same server, for example.
>> 
>> You've stepped into one of my fun areas, mixing technologies to attain
>> a desired result, especially SSH and source control.
>> 
>> As long as you can gracefully use a different IP address for each
>> environment, it's workable.
> 
> Because nothing says graceful or workable like large scale IP management.

Indeed, it does scale stably and well for small projects. For large sets of projects, such as several hundred, IPv6 becomes critical to support this approach.

Doesn't work well behind NAT or proxies without a lot if extra work.


>> If you do it hostname based, you can get
>> in deep confusion with all the different valid versions of the same
>> hostname, such as WWW.eXaMplE.CoM versus www.example.com versus www
>> (with a local domain set of example.com), and trying to match them
>> all. That's an old problem with "VirtualHosts" from web servers, as
>> well.
> 
> Yes, it's an old, pretty much entirely solved problem. It's also not *our* problem; with this environment trick, it's the consuming shell's thing to deal with.

Yes, and it's very often done wrong. UTF8 hostnames, anyone?

> Arguably we could canonicalize the DNS name.

I'd advocate that.

>> 
>> Alternatively, don't use the "same user" for different projects on the
>> same server. Use a different git shared username for each project
>> environment. Since your git environments are normally defined by the
>> home directory of the actual shared git username, this may be much
>> faster and easier to set up and require no root managed manipulation
>> of your sshd_config.
> 
> That's one way to do it, but overloading username instead of host has its own pile of issues.

True, but it scales to thousands if projects and keeps source control   configurations away from DNS or network resource management.