Part of the OpenSSH drop-in compatibility epic.
Problem
HostKeyAlias tells ssh(1) which name to use when looking a host key up in and recording it into known_hosts, decoupling trust from the address actually dialed. bssh's parser recognizes the keyword (hostkeyalias is in the accepted set) and the resolver stores it, but host_key_alias is never read outside src/ssh/ssh_config/, so verification keys on the connection target instead.
The regression suite depends on this. Its generated ssh_config contains HostKeyAlias localhost-with-alias, and the generated known_hosts is keyed on that alias:
localhost-with-alias,127.0.0.1,::1 ssh-ed25519 AAAAC3Nza...
Because the suite runs sshd on port 4242, a client without HostKeyAlias support looks up the bracketed [127.0.0.1]:4242 form, misses, and refuses under StrictHostKeyChecking yes.
The practical case outside the suite is the same shape: several hosts behind one address, a host reachable on a rotating port, or a tunnel endpoint whose identity should not follow the local forwarding port.
Scope
- Use
HostKeyAlias in place of the connection target for both known_hosts lookup and first-use recording.
- Apply the alias verbatim, without the
[host]:port bracketing that a non-default port would otherwise trigger. This bracketing rule is the reason the suite's configuration works with OpenSSH and fails with bssh today.
- Make the alias participate in the same resolution order as the rest of the effective host config, so a
Host block and a -o HostKeyAlias= both apply.
- Depends on the
UserKnownHostsFile sub-issue: both defects sit in the same lookup path, and fixing one without the other leaves the suite's configuration unusable.
Acceptance criteria
Part of #275
Part of the OpenSSH drop-in compatibility epic.
Problem
HostKeyAliastellsssh(1)which name to use when looking a host key up in and recording it into known_hosts, decoupling trust from the address actually dialed. bssh's parser recognizes the keyword (hostkeyaliasis in the accepted set) and the resolver stores it, buthost_key_aliasis never read outsidesrc/ssh/ssh_config/, so verification keys on the connection target instead.The regression suite depends on this. Its generated
ssh_configcontainsHostKeyAlias localhost-with-alias, and the generated known_hosts is keyed on that alias:Because the suite runs sshd on port 4242, a client without
HostKeyAliassupport looks up the bracketed[127.0.0.1]:4242form, misses, and refuses underStrictHostKeyChecking yes.The practical case outside the suite is the same shape: several hosts behind one address, a host reachable on a rotating port, or a tunnel endpoint whose identity should not follow the local forwarding port.
Scope
HostKeyAliasin place of the connection target for both known_hosts lookup and first-use recording.[host]:portbracketing that a non-default port would otherwise trigger. This bracketing rule is the reason the suite's configuration works with OpenSSH and fails with bssh today.Hostblock and a-o HostKeyAlias=both apply.UserKnownHostsFilesub-issue: both defects sit in the same lookup path, and fixing one without the other leaves the suite's configuration unusable.Acceptance criteria
HostKeyAliasset in a config file or via-ochanges which known_hosts entry is consulted.accept-newrecords the learned key under the alias.Part of #275