When HostKeyAlias is specified, it is not used for the hostname in the configuration file or for the default login prompt. This behavior is especially problematic when local port forwarding of an SSH connection is being done. In that case, "localhost" must be used as the hostname so it is impossible to distinguish one host from another.
Created attachment 911 [details] patch to use HostKeyAlias for the hostname patch to use HostKeyAlias for the hostname when reading the configuration files and logging into a remote host (modifies the default prompt).
I'm not sure that this is a problem. You can already do: Host something HostName localhost HostKeyAlias something if you want to create "virtual" hosts that refer to the same hostname. This works for localhost too: Host something1 HostName localhost Port 2222 HostKeyAlias something1 Host something2 HostName localhost Port 2223 HostKeyAlias something2
That seems to work for the config file (thanks!) but there is still problem with the prompt.
Created attachment 915 [details] use HostKeyAlias as password prompt if set This patch will do what you're looking for. I'm not sure whether or not it's needed, though. $ ./ssh -o hostkeyalias=foo localhost dtucker@foo's password:
It is arguable as to whether it is better to show the real hostname or the hostkeyalias hostname. I tend to think that the real hostname is more valuable because: a) HostKeyAlias may be a name that doesn't exist anywhere else, so it doesn't give you any more information. After all, you already know the alias name. b) A real host name might provide information valuable in deciding whether to accept host keys, etc. E.g. connecting over an aliased localhost SSH forwarding. So, I think it is better to display the real hostname.
In case b (and the SSH forwarding example), without the change, the "real" host name is "localhost". HostKeyAlias is used for looking up the key in the HostKey database (aka the known_hosts file) and thus should also be used for the prompt. In case b, HostKeyAlias provides not only more information than the "real" hostname but the correct information. Please reconsider your decision.
I don't understand: you know the alias hostname, because it is there on the commandline, so the prompt is providing you more, real information. Can you give me a real-life scenario where showing the alias hostname would be important?
(In reply to comment #7) > I don't understand: you know the alias hostname, because it is there on the > commandline, so the prompt is providing you more, real information. > > Can you give me a real-life scenario where showing the alias hostname would be > important? You don't always see the command line that gets passed to ssh, for example if you're using cvs-over-ssh, or rsync-over-ssh, or ....
retarget to openssh-5.2 release
only changes to portable OpenSSH are being considered for 5.3 at this stage.
The patch has been applied and will be in 5.4. Thanks.
With the release of 5.4p1, this bug is now considered closed.
My apologies for re-opening a long-closed bug, but this feature seems like a bad idea. The description of HostKeyAlias in ssh_config(5) only refers to using the alias for the purpose of looking up or storing keys. Thus, having it also affect the password prompt is quite unexpected. While the current behaviour addresses one issue, it creates others: In our environment, we use a proxy command to implement load-balancing between a number of front-ends for a cluster. Users ssh to a special hostname, which is not in DNS, to invoke the load-balancer and all of the front-end systems share the same host keys. The ssh_config entry looks something like this: Host balancer HostKeyAlias frontend1 ProxyCommand /usr/local/bin/ssh-balance %h The HostKeyAlias option is needed because there is not an actual host named balancer and no entry for that name in the ssh_known_hosts file. Consequently, the password prompt always indicates frontend1 regardless of what host the user is actually directed to by the proxy command. This is deceptive and has caused some confusion when debugging issues. Perhaps it would be better to use a separate option to allow manipulation of the password prompt. Alternatively, perhaps some logic could be added to limit the circumstances where the key alias rather than the hostname is used in the prompt. A potential fix (for our environment) might be: const char *host = (options.host_key_alias && !options.proxy_command) ? options.host_key_alias : authctxt->host;
I had incorrectly assumed that adding a comment would automatically re-open this bug. Please see Comment #13.