openssh unix dev - Sep 2025 - How to specify chost (client hostname) used for hostbased authentication?

Thanks!
I am not that familiar with HostbasedAuthentication, or rather how it was/is
actually used and what the background is.
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?

Unfortunately I am not a dev, so I hope someone picks up this feature, possibly.
Hostbased authentication doesn?t seem to get as much love as it should
(especially in the context of bastions/jumphosts being deployed heavily in the
clouds).

Jan
> On 5. 9. 2025, at 11:30, Brian Candler <b.candler at pobox.com>
wrote:
> 
> On 05/09/2025 09:45, Jan Schermer wrote:
>> I have a question about hostbased authentication. It looks like the
client does a reverse DNS lookup on the IP it is connecting from and uses that
hostname as chost - which fails if it?s a dynamic IP (though wildcards in some
places seem to work).
> For reference: https://www.rfc-editor.org/rfc/rfc4252.html#section-9
> 
> The point under consideration is: how does the openssh client select the
chost value to put in the auth exchange for "hostbased"
authentication?
> 
> From the source:
> 
>         /* figure out a name for the client host */
>         lname = get_local_name(ssh_packet_get_connection_in(ssh));
>         if (lname == NULL) {
>                 error_f("cannot get local ipaddr/name");
>                 goto out;
>         }
> 
>         /* XXX sshbuf_put_stringf? */
>         xasprintf(&chost, "%s.", lname);
>         debug2_f("chost %s", chost);
> 
> ...
> 
> char *
> get_local_name(int fd)
> {
>         char *host, myname[NI_MAXHOST];
> 
>         /* Assume we were passed a socket */
>         if ((host = get_socket_address(fd, 0, NI_NAMEREQD)) != NULL)
>                 return host;
> 
>         /* Handle the case where we were passed a pipe */
>         if (gethostname(myname, sizeof(myname)) == -1) {
>                 verbose_f("gethostname: %s", strerror(errno));
>                 host = xstrdup("UNKNOWN");
>         } else {
>                 host = xstrdup(myname);
>         }
> 
>         return host;
> }
> 
> ...
> 
> and in turn, get_socket_address() uses getpeername() or getsockname() and
getnameinfo() to resolve.
> 
> So in short: I believe you're right, the chost that the client sends is
chosen via reverse DNS of the client-side bound socket.
> 
> It does seem to me that it would be reasonable to have a client option to
select an arbitrary chost string for host-based authentication (and/or to use
the value of gethostname() only), but as far as I can see, no such option
currently exists.
> 
> 
> 
>> Also I wonder if the server could/should just check forward DNS against
the connecting IP as a better alternative to
HostbasedUsesNameFromPacketOnly=yes, this would make it work with DynDNS
services.
> Whatever hostname the client claims to have via chosts, it has to back that
up by proving possession of the corresponding private key, so any DNS checks are
arguably unnecesary.
> 
> Having said that, the RFC does say:
> 
>    Whenever possible, it is RECOMMENDED that the server perform
>    additional checks to verify that the network address obtained from
>    the (untrusted) network matches the given client host name.  This
>    makes exploiting compromised host keys more difficult.  Note that
>    this may require special handling for connections coming through a
>    firewall.
> Regards,
> 
> Brian.
>

Hi,

On Fri, Sep 05, 2025 at 11:45:33AM +0200, Jan Schermer
wrote:
> I am not that familiar with HostbasedAuthentication, or rather how it
was/is actually used and what the background is.
> 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???
The server will never SSH back.  There is a suid binary on the client
(ssh-keysign) which will take the client's hostkeys and sign a challenge
with them.  It needs to be suid because a normal user's ssh has no
access to the client's private host keys.

gert
-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             gert at
greenie.muc.de

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.