How to specify chost (client hostname) used for hostbased authentication?

[Brian Candler]

On 05/09/2025 10:45, Jan Schermer wrote:
> I am not that familiar with HostbasedAuthentication, or rather how it 
> was/is actually used and what the background is.

There's a reasonable overview here:

https://hea-www.harvard.edu/~fine/Tech/ssh-host-based.html

Basically it's to get rssh-like functionality between a local cluster of 
machines that trust each other.  A user logged in as "foo" on machine A 
can ssh into account "foo" on machine B. But instead of user foo having 
their own personal key pair, there's a key pair between the hosts 
themselves.

Hence all users on machine A can login as the corresponding user on 
machine B: convenient in some environments, but not very secure.  
Generally to be avoided unless you have a good reason to use it.  If 
you're on a dynamic IP address you probably want to do normal user 
pubkey authentication, not host authentication.

> To me, the whole thing with SSHKeySign looks like the server could 
> actually SSH back to the client(’s server), have the server 
> sign/verify it (sort of out-of-band) and then accept/reject the 
> original authentication, not sure if something like that is behind 
> this design or not but that’s why my thoughts went for verifying the 
> hostname by forward DNS lookup…

Sorry, I don't understand that at all.

With host-based authentication, host A is connecting to host B. Host B 
has a "known_hosts" entry for host A, which contains the public key 
corresponding to host A's private key.  Once host A has proved its 
identify (via ssh-keysign to prove it has the private key), host B 
accepts the connection. It then trusts host A to assert which username 
is logging in (whether that be "foo" or "bar" or "root")

I don't see why host B would also want to SSH back to host A as part of 
A logging into B. In that case, host A would also have to allow ssh 
connections from host B. Sounds like a chicken-and-egg situation.

The DNS is not really part of the authentication, except in as much as 
host B needs to know who is trying to authenticate, so that it can 
select the correct public key from its known_hosts file. This can be 
done either by:

- host B doing a reverse DNS lookup on the source IP address of the TCP 
connection

- host A sending its own identity "hostA" as the chost field in the 
authentication exchange

But in either case, it's only selecting a *candidate* for 
authentication. If hostA cannot actually *prove* that it is hostA, which 
it does by signing a challenge using hostA's private key, then 
authentication will fail.  So DNS is not really part of the security, 
any more that when I type "ssh brian at 1.2.3.4" I am *claiming* that I am 
user "brian" but won't get any further without a successful authentication.