Hello! I'd like to be able to specify different HostKeys to be used depending on which [IP.ADD.RE.SS]:[port] the incoming connection is coming to... This would be helpful to all, who are trying to consolidate several servers into one smoothly... Something like: Port 22 HostKey /etc/ssh/ssh_host_key-xxx ListenAddress ip.add.re.ss1:22 HostKey /etc/ssh/ssh_host_key-yyy ListenAddress ip.add.re.ss2:24 HostKey /etc/ssh/ssh_host_key-zzz Thanks!
sshd does not support this, however you can run multiple sshds each with a different host key and bind each to a separate ListenAddress and/or Port.
I know, it does not support it. I think, it should -- hence this enhancement request. Server-consolidation is a common task, but running multiple sshd-processes is merely a work-around. It is not elegant -- sshd can do better :-)
(In reply to comment #2) > I know, it does not support it. I think, it should -- hence this > enhancement request. Sure, but I just wanted to mention that in case you need a solution now that does not involve changing client hostkeys. > Server-consolidation is a common task, but running multiple > sshd-processes is merely a work-around. It is not elegant -- sshd can > do better :-) I had previously considered whether or not the Match directive could be taught about the local address and port, which would give you syntax something like: Match LocalAddress 10.1.1.2 Port 22 HostKey ... but I'm not sure how hard it would be to implement. It would need to reprocess the config immediately after a connection is accepted and before any processing is done. This would conceivably control such things as Compression, Protocol and maybe Hostkey. The catch is you would have to disallow Match directives that look at, eg the username from trying to change hostkey because it makes no sense. I really need to get the stuff I've already written merged before looking at this, though...
WONTFIX => this is a niche feature which would take quite a bit of work to implement and can be achieved though other means (multiple sshd instances, which IMO is quite a clean solution).
Mass update RESOLVED->CLOSED after release of openssh-5.1