bugzilla-daemon at mindrot.org
2015-Feb-21 08:10 UTC
[Bug 2357] New: please add "vhosting" features respectively per-LocalAdress HostKeys/etc.
https://bugzilla.mindrot.org/show_bug.cgi?id=2357 Bug ID: 2357 Summary: please add "vhosting" features respectively per-LocalAdress HostKeys/etc. Product: Portable OpenSSH Version: 6.7p1 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: calestyo at scientia.net 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. -- You are receiving this mail because: You are watching the assignee of the bug.
bugzilla-daemon at mindrot.org
2015-Feb-21 15:58 UTC
[Bug 2357] please add "vhosting" features respectively per-LocalAdress HostKeys/etc.
https://bugzilla.mindrot.org/show_bug.cgi?id=2357 --- Comment #1 from Christoph Anton Mitterer <calestyo at scientia.net> --- See also bug #2358, which is kinda related to vhosting functionalities. :) -- You are receiving this mail because: You are watching the assignee of the bug.
Seemingly Similar Threads
- [Bug 2358] New: allow sshd to "redirect" to another local user
- [Bug 1279] Address- and/or port-specific HostKeys support
- Matching username in ssh_config
- [PATCH] hostfile: list known names (if any) for new hostkeys
- [PATCH 0/2] Specify signature algorithm during server hostkeys prove