If SSH is already being used, can't one just create an SSH tunnel to forward the login?

ssh -D ftw

AllowTcpForwarding no ftl

eh if you have shell access anyway this is easy to circumvent.

"If" is a good word. The setting above is usually being used in environments where network security is a bit paranoid, so shell access won't help against lack of a hole through the firewall somewhere in-between, unless there's a way to use avian carriers.

The thread we are in is talking specifically about using cli tools on a remote machine, so that’s why I mentioned it. If you have that you don’t need a hole in the firewall.

Some login requires Identity and access management (IAM) with a web interface only, if such gateway exists, a CLI tool would have to give user a link to open oneself I guess?

My SSH usage has multiple servers (staging, dev, etc..) and multiple clients (laptop, desktop). Some of those connections are going through jumphosts.

Setting up SSH tunnel would be possible, but a major pain, as every source/dest combination will need to have its own port, and every signin should specify the port number.

Compared to the current system, which prints a URL in terminal which I just need to click, it would be a major usability regression.

Something akin to ssh agent-forwarding ("oauth-forwarding"?) is really needed. And it needs to be integrated similarly well like support for jumphosts.

Haven't seen anything like this, I'll try to bring this up with the openssh folks.

Possibly redirect to localhost:<port> where the port is one forwarded over ssh could do the trick?

Curl can connect over unix domain sockets and ssh can forward them, I feel this would be a decent way to forward authentication as access control rules would apply to the sockets.

I wonder if having the user copy-paste the token could work?

As long as noone compromised their clipboard using malware etc. Which is a vector that seems quite common in spearphishing at least anecdotally.

Wouldn't they already be pwned in that case?

Their machine would be pwned, but their 2nd factor would not be compromised if they used something like a yubikey, so the attacker couldn't use the compromised host to SSO to other systems and enlarge their compromise. That's why yubikey requires that you touch it - an attacker can't just remotely trigger it even if they totally own the host the yubikey is plugged into.

That's the point of TFA - unphishable second factors and ways to make them phishable. I'm saying that using the clipboard would be a bad idea in this case.

If the machine is pwned, it seems like it wouldn't be super hard to get the user to touch the yubikey.

Copy and paste means a user can be phished. The user can copy and paste it to an attacker.

The token could be made only usable by the cli process that asked for it (should be really).

Yes, but that doesn't stop this attack.

1. Attacker runs the cli process to generate the URL

2. Attacker sends the URL to the victim saying "as a second factor verification, you need to copy this code into this form"

3. Victim does it

4. Attacker enters the code into the original cli process

Doesn't VSCode forward connections made in its terminal? I worked remote on some webstuff and I could use my local browser just fine.