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

[Jan Schermer]

I’m sorry, I was mostly thinking out loud.
I understand (mostly) how it technically works, but it seems a bit weird to invoke a SUID binary over client’s connection backwards. I’d expect it to be a completely separate and isolatd connection outside of the client’s control.
When I started working as a sysadmin everyone was already using pubkeys, so I never worked in an environment that used hostbased auth, rsh, I’ve never even seen NIS and stuff like that used, thatis  just so far back that I didn’t encounter it.

It’s just that the whole concept looks more like “more trustworthy identd”, which would make more sense if the target (server) sshd daemon did a callback instead of how it actually works, whence my thoughts on it and I wonder if the original authors were thinking about it that way.

>  DNS is not really part of the security,
^ if that were completely true, than there wouldn’t be any need for HostbasedUsesNameFromPacketOnly option, though it in fact seem to do something slightly different than what its name implies, at least for me - once disabled, I can’ t login at all, so it’s not supplementing the client’s “chost” but rather not using it/trusting it at all.

I’ll plunge into the RFCs over the weekend :)

Sorry and thanks for you explanation, very much appreciated

Jan

> On 5. 9. 2025, at 12:04, Brian Candler <b.candler at pobox.com> wrote:
> 
> 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.
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev