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

21–30 of 108 posts

Re: Making an SSH client the hard way

#21

Post by fisian »

amluto wrote: post #12

I can't shake the feeling that Tailscale's SSH authentication mechanism is at the wrong layer of the stack. It appears to work by looking at the (source, dest) IP address pair and mapping that to a Tailscale identity. But this may mean that any user or anyone who can initiate TCP connections from an authenticated user's IP can authenticate to the destination over Tailscale SSH. If Tailscale's client was a userspace c…

I agree.

I feel like there should be a lightweight way to use SSH certificates, so you could use it independently or on top of Tailscale. Like a server (CA), client and daemon on your machines that should be reachable via SSH that handles short lived certs and authentication of clients. But I'm not aware of anything like that.

I have used Teleport before but it seemed not that great for machines not publicly reachable, because then all the traffic goes through a proxy.

Re: Making an SSH client the hard way

#22

Post by dekhn »

0xbadcafebee wrote: post #9
dekhn wrote: post #7

Earlier quoted context omitted.

It's not a compliment. Or rather, within my understanding of how things should be architected, it's not. I certainly wouldn't claim that my own beliefs about network architecture should trump others, and I work in a different domain from most of the people with your use case. Whether the disruptive work you're doing is good for the world in the long run is still a very open question in my mind. I used to think that e…

SSH in the web browser is actually the best practice today. Here are some examples of why SSH in your browser actually compliments modern computing: - An SSO-authenticated web interface, integrated with a host agent on your instances, means you don't have to manage SSH keys. - If you just need a disposable CLI that inherits permissions from your SSO-authenticated user role, you can do that from a disposable box in a…

I'm fine with ssh in a browser. I used Chrome SSH Extension for many years to connect to a VM running tmux. And I use RDP if I truly need a remote desktop. However, it (browser SSH) not a replacement for, it's an augmentation of, the OS-level ssh client.

Turning this around. Let's take the idea of using WASM to put a full environment in the user's browser. This is a logical idea, after all- WASM exists to make it possible to write applications in Not-Javascript and deploy them in a browser. IE, don't stop with SSH: you should have a web server, a shell, multiprocessing, scripting languages, everything necessary to host VSCode server and a self-hosted compilation toolchain in a browser. Full linux user space in a browser, enough to compile ChromeOS and boot into a browser running linux

What have you achieved? A very expensive (in terms of porting cost, CPU usage, and deployment size) inner platform that does what an OS does already. But it's inside the browser, with a patched version of code (because WASM always trails native apps), with each sub-application maybe linking in its own TCP stack. So it will always trail innovations in desktops, since it's not a full replacement for the existing system. So it makes the world more complicated and exposes more surface areas for security management.

Re: Making an SSH client the hard way

#23

Post by amluto »

mihaip wrote: post #15
amluto wrote: post #12

I can't shake the feeling that Tailscale's SSH authentication mechanism is at the wrong layer of the stack. It appears to work by looking at the (source, dest) IP address pair and mapping that to a Tailscale identity. But this may mean that any user or anyone who can initiate TCP connections from an authenticated user's IP can authenticate to the destination over Tailscale SSH. If Tailscale's client was a userspace c…

Tailscale SSH's check mode ( https://tailscale.com/kb/1193/tailscale-ssh/#configure-tails... ) is meant to address the issue of "rogue process starts an SSH connection". For truly sensitive applications, you can set the check period to be "1s" to always require it.

Hmm. If the problem is that Tailscale SSH doesn’t strongly associate the person authenticating with the connection being authenticated, asking the person to reauthenticate seems like a pretty weak solution.

Re: Making an SSH client the hard way

#25

Post by amluto »

fisian wrote: post #21
amluto wrote: post #12

I can't shake the feeling that Tailscale's SSH authentication mechanism is at the wrong layer of the stack. It appears to work by looking at the (source, dest) IP address pair and mapping that to a Tailscale identity. But this may mean that any user or anyone who can initiate TCP connections from an authenticated user's IP can authenticate to the destination over Tailscale SSH. If Tailscale's client was a userspace c…

I agree. I feel like there should be a lightweight way to use SSH certificates, so you could use it independently or on top of Tailscale. Like a server (CA), client and daemon on your machines that should be reachable via SSH that handles short lived certs and authentication of clients. But I'm not aware of anything like that. I have used Teleport before but it seemed not that great for machines not publicly reachabl…

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 businesses.

Re: Making an SSH client the hard way

#26

Post by aleph- »

amluto wrote: post #25
fisian wrote: post #21

Earlier quoted context omitted.

I agree. I feel like there should be a lightweight way to use SSH certificates, so you could use it independently or on top of Tailscale. Like a server (CA), client and daemon on your machines that should be reachable via SSH that handles short lived certs and authentication of clients. But I'm not aware of anything like that. I have used Teleport before but it seemed not that great for machines not publicly reachabl…

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?

Re: Making an SSH client the hard way

#28

Post by asdfasdfasdfass »

dekhn wrote: post #22
0xbadcafebee wrote: post #9

Earlier quoted context omitted.

SSH in the web browser is actually the best practice today. Here are some examples of why SSH in your browser actually compliments modern computing: - An SSO-authenticated web interface, integrated with a host agent on your instances, means you don't have to manage SSH keys. - If you just need a disposable CLI that inherits permissions from your SSO-authenticated user role, you can do that from a disposable box in a…

I'm fine with ssh in a browser. I used Chrome SSH Extension for many years to connect to a VM running tmux. And I use RDP if I truly need a remote desktop. However, it (browser SSH) not a replacement for, it's an augmentation of, the OS-level ssh client. Turning this around. Let's take the idea of using WASM to put a full environment in the user's browser. This is a logical idea, after all- WASM exists to make it pos…

No post body was provided.

Re: Making an SSH client the hard way

#30

Post by rany_ »

skybrian wrote: post #27

In the old days, people said you shouldn't write crypto in JavaScript because it was somehow insecure. Have those concerns gone away with WebAssembly and https everywhere?

I don't think the argument was ever that "JavaScript was insecure." It was that the websites hosting it may be compromised or may change the script at any time without any indication (or the FBI forcing a site to backdoor the JS for some investigation)
Post reply on HN