SSH in-browser and key authentication options exclusives?

[drustan]

Hello!

First of all, big thanks for this amazing project; it truly is a fantastic tool :)

Now, I've encountered an issue where, if I enable both the "in-browser" and "key" authentication methods for SSH, the in-browser validation appears to malfunction. Attempting to click the button to authorize the connection results in no action.

Cheers and thanks again!

[Eugeny]

I haven't tested this directly, but have you also confirmed the keyboard-interactive prompt in the SSH client after clicking Authorize in the browser? The client is going to wait for your input before checking whether the auth was successful or not.

[drustan]

Yes, I did check that. When you hit enter in the shell, the shell hangs like when you did not authorized the connection.

It's actually working well when only the "in-browser" option is activated.

It would be nice to implement a feature that displays a "connection not authorized" message where the connection hasn't been validated by the user. This would clarify the connection status.

[budachst]

Can you please tell me, how you configured that? I can't find any documentation about this feature.

[drustan]

You can configure that for each user in Config / Users / youruser

[budachst]

Ahh… cool! Really nice. As for your question about whether in-browser and key authentication are exclusives, to me it seems that they're actually inclusive. If you activate either, you can't use the in-browser auth alone, but your keys must match as well. This is actually great stuff and I am so happy, that I stumbled across this.

[SheaSmith]

I think it depends what options you have setup. For example, if you select 'Any credential', then either the key OR the OOB auth can be used. Whereas if you enable both the key and OOB/in-browser auth, then both will be required.

For example, either key or OOB/in-browser would be enabled in this scenario:

Whereas both key and OOB/in-browser would be required in this scenario:

There seems to be a separate bug where if you have 'Any credential' enabled, only SSH keys and SSO configured for a user, and a key doesn't match (and so isn't used for auth) a password is prompted instead of keyboard interactive auth, but I'll make a separate issue for that.

[theMackabu]

~~ive been having this exact same issue, temporary fix is to create another account with the name sso (or similar) and have that only be able to use browser authentication~~

edit: should have commented this in issue #972

[Annihilater]

I found that when I added a public key for the admin user in the browser, the last username part of my public key was deleted when I saved it. This may cause the local public key to not match the public key saved by the warpgate admin account when I connect with the public key, so I need to enter the admin user password to log in. Please fix it as soon as possible

[Eugeny]

I've tried to reproduce the initial issue and couldn't. Could you try connecting with ssh -v to see what's going on with the auth process?

Here's my setup

OpenSSH_9.6p1, LibreSSL 3.3.6
...
debug1: Authentications that can continue: password,publickey,keyboard-interactive
debug1: Offering public key: /Users/eugene/.ssh/id_ed25519 ED25519 
debug1: Server accepts key: /Users/eugene/.ssh/id_ed25519 ED25519 
debug1: Authentications that can continue: keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Warpgate authentication
-----------------------------------------------------------------------
Warpgate authentication: please open the following URL in your browser:
https://warpgate.com/@warpgate#/login/b2a721d1-5236-431c-b320-165301215523

Make sure you're seeing this security key: 1 9 F 0
-----------------------------------------------------------------------

(admin:[email protected]) Press Enter when done: 
Authenticated to 127.0.0.1 ([127.0.0.1]:2222) using "keyboard-interactive".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Entering interactive session.