Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making an SSH client the hard way

tailscale.com

Post reply on HN
Print view View original

71–80 of 108 posts

Re: Making an SSH client the hard way

#71

Post by lxgr »

Serow225 wrote: post #60
lxgr wrote: post #52

Earlier quoted context omitted.

You‘d have to redirect all network usage (i.e. the sockets API or your platform‘s equivalent) through the custom stack, which is possible if you can rebuild the source or by using something like LD_PRELOAD for binaries, but can get very tricky in the general case. There‘s an utility called SSHuttle that does something similar for SSH instead of Tailscale/Wireguard: It redirects all sockets usage to go through an SSH…

SSHuttle was created by the CEO/co-founder of Tailscale :)

Indeed, both the name and the very clever combination of existing components sounded familiar when I first heard about Tailscale :)

Re: Making an SSH client the hard way

#72

Post by sedatk »

gunapologist99 wrote: post #69
sedatk wrote: post #59

Earlier quoted context omitted.

That's unnecessary sensationalism. Most of those vectors are behind an SSO login and are not exposed to Internet at all (from the article: "your browser becomes a Tailscale client, and joins your tailnet in the same way as any other device that you run Tailscale on"). Or, did you mean attacks on SSO? If that's the case, then SSH web wouldn't make any difference. Someone authenticating themselves could use regular SSH…

> Again, attacks on browser means end of game already. A bad Chrome extension does not allow the bad guys to open a terminal on my machine, load my ssh keys, launch an authenticated SSH connection, and launch an authenticated SSH connection into an enumerated list of remote servers.

A malicious browser extension can access your email, SSO prompts, password manager, etc, and therefore gain access to your Tailscale network anyway. SSH web doesn't add a new threat vector here. It's already game over.

Re: Making an SSH client the hard way

#73

Post by amluto »

aleph- wrote: post #26
amluto wrote: post #25

Earlier quoted context omitted.

Smallstep and cloudflared do this. Sadly, both of them seem to use essentially identical client-side hacks. Smallstep is a small company that I wouldn’t trust with the keys to the kingdom, and Cloudflare seems to treat their SSH product as something thrown over the fence with nothing resembling support. Gravitational’s Teleport seems pretty good, but it’s heavyweight and doesn’t have any pricing appropriate for small…

I'm mildly curious what client side hacks you're talking about?

https://developers.cloudflare.com/cloudflare-one/identity/us...

The configuration is:

Host vm.example.com ProxyCommand bash -c '/usr/local/bin/cloudflared access ssh-gen --hostname %h; ssh -tt %r@cfpipe-vm.example.com >&2 Host cfpipe-vm.example.com HostName vm.example.com ProxyCommand /usr/local/bin/cloudflared access ssh --hostname %h IdentityFile ~/.cloudflared/vm.example.com-cf_key CertificateFile ~/.cloudflared/vm.example.com-cf_key-cert.pub

Think about this a bit. Contemplate what happens if you use sftp, vscode remoting, or anything else nontrivial. Hint: “cloudflared access ssh-gen” is not actually any sort of proxy, and the ssh -tt command is a kludge that should, if openssh were more on the ball about inherited file descriptors, should not work at all.

The right way to to this is to use Match … exec. Or to ask openssh to add an option for a command to execute before reading IdentityFile. Or to ask for an IdentityFileCommand option. Or to use a custom ssh agent.

Re: Making an SSH client the hard way

#74

Post by ipaddr »

sedatk wrote: post #72
gunapologist99 wrote: post #69

Earlier quoted context omitted.

> Again, attacks on browser means end of game already. A bad Chrome extension does not allow the bad guys to open a terminal on my machine, load my ssh keys, launch an authenticated SSH connection, and launch an authenticated SSH connection into an enumerated list of remote servers.

A malicious browser extension can access your email, SSO prompts, password manager, etc, and therefore gain access to your Tailscale network anyway. SSH web doesn't add a new threat vector here. It's already game over.

A browser extension cannot access your email or password manager. But it can use this new security hole created by tailscale.

Re: Making an SSH client the hard way

#75

Post by yjftsjthsd-h »

ipaddr wrote: post #74
sedatk wrote: post #72

Earlier quoted context omitted.

A malicious browser extension can access your email, SSO prompts, password manager, etc, and therefore gain access to your Tailscale network anyway. SSH web doesn't add a new threat vector here. It's already game over.

A browser extension cannot access your email or password manager. But it can use this new security hole created by tailscale.

If the extension in question has the read/modify all websites permission, why would it not be able to access your email or password manager?

Re: Making an SSH client the hard way

#76

Post by r2_pilot »

yjftsjthsd-h wrote: post #75
ipaddr wrote: post #74

Earlier quoted context omitted.

A browser extension cannot access your email or password manager. But it can use this new security hole created by tailscale.

If the extension in question has the read/modify all websites permission, why would it not be able to access your email or password manager?

Who's using extensions in a work context anyway? I only use an ad-blocker because it's safer from a malware perspective.

Re: Making an SSH client the hard way

#77

Post by matthewaveryusa »

Spivak wrote: post #61
bradfitz wrote: post #48

Earlier quoted context omitted.

Which blog post are you referring to? But yes, we love Fly and use them (and they use us) and we share a slack channel between our two companies for casual banter.

This one! https://fly.io/blog/ssh-and-user-mode-ip-wireguard/

I mean if you want to go back, this is the original post from the horse’s mouth:

https://lists.zx2c4.com/pipermail/wireguard/2021-January/006...

Re: Making an SSH client the hard way

#78

Post by otterley »

dgentry wrote: post #68
gunapologist99 wrote: post #58

This significantly increases the threat model for your remote servers to include all sorts of remote attacks through the web, including: * garden-variety web attacks (i.e., XSS, CRSF, etc) * attacks that might become viable against the browser (for example, Mobile Safari has a history of vulnerabilities) * various attacks against the backend web server (API attacks) * attacks against the WASM layer * CDN injections *…

(Tailscale employee) It is not a web page with a shell open. It is the Tailscale client, compiled to WASM, maintaining the keys for connections to nodes on the tailnet. Connections opened from the browser engine don't get the ability to reach the tailnet.

Given the apparent (yet possibly unfounded) concern, it might be useful to discuss this issue in the blog post. Would you consider updating it?

Re: Making an SSH client the hard way

#79

Post by _hyn3 »

gunapologist99 wrote: post #58

This significantly increases the threat model for your remote servers to include all sorts of remote attacks through the web, including: * garden-variety web attacks (i.e., XSS, CRSF, etc) * attacks that might become viable against the browser (for example, Mobile Safari has a history of vulnerabilities) * various attacks against the backend web server (API attacks) * attacks against the WASM layer * CDN injections *…

This seems to really expand the scope of how keys are handled and authorized. It at least appears to be optional, however.

Or just use userify's public key distribution model (then you can stick with a simple and proven design that just automates the standard SSH design that's been around for decades)

Or just do it the old way, by hand: drop your teams' public keys on groups of remote servers, setup their sudo access, and you're done.

Or just use Ansible or Chef or Terraform, or any of those other server orchestration tools, too (just without the permission layer/bulk remote session kills/user deletes of Userify).

of course, if you really need an ssh terminal in a browser, then you have to go with one of these sorts of crazy things, and at least it's not using passwords!

Re: Making an SSH client the hard way

#80

Post by mynameisvlad »

otterley wrote: post #78
dgentry wrote: post #68

Earlier quoted context omitted.

(Tailscale employee) It is not a web page with a shell open. It is the Tailscale client, compiled to WASM, maintaining the keys for connections to nodes on the tailnet. Connections opened from the browser engine don't get the ability to reach the tailnet.

Given the apparent (yet possibly unfounded) concern, it might be useful to discuss this issue in the blog post. Would you consider updating it?

Doesn't the post say exactly what the parent comment did? It explains the process that they came up with the WASM Tailscale, and how it authorizes and works. If anything, the parent comment just paraphrased the article.
Post reply on HN