There's a custom Jumphost CLI rolled out by our Secure Engg team that we've installed on our machines. When we're connected to our internal network, the CLI requests a token from our LDAP server, with an expiration and generates a cookie on our ~/.authn folders.
Any attempts to modify the token do not work because it's a JWT with a set expiry. I'm puzzled for the same reason as you. The SSH dialog doesn't even mention the LDAP communication. However, when the token expires, it knows somehow. When the token is set, it knows somehow.
This "knows" is definitely through a cookie.
There are some entries in our /etc/hosts file. Our laptops are workplace laptops with tons of custom utilities attached.
Edit: I think I got it. Our machines have replaced ssh in our bash profiles with something like this
$ alias ssh='custom-jumphost-cli installCert; ssh'
This explains why the ssh works differently.
When I run
$ custom-jumphost-cli installCert
It asks for the token and upon adding correct credentials, updates the cookie. The command basically installs an OpenSSH certificate with an expiry.
So as I see, we can solve this by adding the ability to specify a custom certificate path or by appending the custom command prior to the diagnostic command.
But again, not trivial. The experience I was looking for was to do it all from the Core Tunnel.