Hi team. Premium user here. Our org has setup LDAP and 2FA for enhanced security. So every access through a jump host (ProxyPass) requires us to go through LDAP authentication powered by a 2FA.
Let's say I'm trying to create a tunnel for a node 10.32.161.74. Because of the below restriction, the tunnel fails naturally because it cannot bypass this scheme
X only allows me to go through if it sees the token. Else rejects. This is where Core tunnel simply cannot connect.
If I have the token, core tunnel works for that duration until the token expires. Which is when I generate a new token and then access my tunnels.
Is there a way to setup LDAP based authentication amongst the plethora for security options in the Authentication settings? I'm trying to avoid adding my username / password every X hours to access my tunnels.
Hi @yang, Core tunnel wasn't able to connect because of the LDAP + 2FA based authentication. On a terminal, once I log in and enter my (both) credentials, I'm able to ssh into 10.32.161.74
Only after the above steps can I connect using the tunnel. Until then, Core Tunnel keeps on retrying until the maxRetry number of attempts have reached.
Once I am connected using the tunnel, I exit my terminal session and use the local port instead.
Also, I'm not able to access the Core Shell. I enabled debug3 log for one of the tunnels but where do I see the log?
Here's Core tunnel not being able to connect when the LDAP token expires
Also, when I ran the equivalent SSH command on the terminal, the very first thing asked in the username, password, 2FA and then the standard SSH dialog works.
It seemed the "Choose 2FA code from the above methods, (default - SMS):" question was not prompted by OpenSSH, your ssh command is likely replaced by a script or a custom executable.
Could you please run this command in Terminal and tell the result?
Aman, I must admit I've somewhat confused. Your ssh seems not be replaced, but I didn't see configuration on LDAP authentication in your ~/.ssh/config file.
How the LDAP authentication works on your Mac? From the screenshot you posted, the LDAP authentication was triggered before OpenSSH got involved.
If your bastion host X requires the 2FA token, then logically we should see the the log debug1: Executing proxy command: exec ssh … first before 2FA prompt appears.
Could you please tell more about how your LDAP infrastructure configured?
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.
appending the custom command prior to the diagnostic command
custom-jumphost-cli is a CLI tool, and Core Tunnel has no idea about its internal. Even Core Tunnel could run custom-jumphost-cli installCert before actual connecting, but it still has no means to interactive with the cli command.
