Requesting support for

Core Tunnel Request Feature
,
#1

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

image
image864×236 23.4 KB

The flow is like this

  • LDAP + 2FA -> generates a token with an expiry
  • I've setup a ProxyJump host as X
  • 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.

Thank you, team.

#2

Hi Aman, thank you for reporting.

Core Tunnel support 2FA inherently, but we didn't test it with LDAP ever.

Did Core Tunnel connect to 10.32.161.74 successfully? Do you have screenshots of authentication dialog when authenticating X?

Could you please also enable debug log and paste the log here? (don't forget remove sensitive information):

Kindly Regards,

Yang

#3

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

image
image1848×308 21.3 KB

--- Due to the restriction that new users can post only image in a post, I'm going to have to split

#4

image
image1910×290 19.5 KB

#5

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.

image
image2818×1380 391 KB

#6

After I enter the correct LDAP + 2FA, standard private key password is asked

image
image1632×880 153 KB

#7

Finally, upon closing the terminal, the tunnel works

image
image1980×294 18.9 KB

#8

P.S Also, attaching a screenshot where the Open Shell button is greyed out. Not sure why?
image

#9

Click this button reveals the full log:
image

So Core Tunnel didn't prompt you this question?

image
image1556×446 115 KB

May I have a look at your ~/.ssh/config file?

#10

To enable this button, Core Shell must be installed.

#11

That's correct @yang Core tunnel didn't prompt me this question.

Apologies about the core shell not being installed. I should've known better. Works now

Here's my ~/.ssh/config

Host 10.* *.my-workplace-domain.com !10.47.192.59
	ProxyJump 10.47.192.59
#12

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?

which ssh
#13

This returns /usr/bin/ssh

#14

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?

Yang

#15

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.

#16

I see, thanks a lot for the explanation.

adding the ability to specify a custom certificate path

It's already supported by Core Tunnel, you can set CertificateFile directive:

image
image1338×686 128 KB

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.

#17

Got it. Thanks a lot for the top quality support Yang.

#18

You're always welcome :smiley: