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?
Making an SSH client the hard way
31–40 of 108 posts
Re: Making an SSH client the hard way
#32I 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…
Re: Making an SSH client the hard way
#33In 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?
Re: Making an SSH client the hard way
#34I 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…
Re: Making an SSH client the hard way
#35I 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…
Re: Making an SSH client the hard way
#36This is really cool and fun, but is this a safe way to run SSH clients? If, say, the adblock Chrome extension you're using gets bought by a malware operator and backdoored[0], now it also has SSH and VPN access. [0]: https://www.wired.co.uk/article/fake-chrome-extensions-malwa...
The Tailscale VPN client, the same one which runs on other devices, is compiled to WASM. It handles all of the key exchanges to connect to the tailnet. The SSH session is running as a WASM Tailscale client. The browser, opening connections from within the browser engine, doesn't have the keys for SSH or VPN access.
Re: Making an SSH client the hard way
#37Earlier 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…
Re: Making an SSH client the hard way
#38This is really cool and fun, but is this a safe way to run SSH clients? If, say, the adblock Chrome extension you're using gets bought by a malware operator and backdoored[0], now it also has SSH and VPN access. [0]: https://www.wired.co.uk/article/fake-chrome-extensions-malwa...
The Tailscale VPN client, the same one which runs on other devices, is compiled to WASM. It handles all of the key exchanges to connect to the tailnet. The SSH session is running as a WASM Tailscale client. The browser, opening connections from within the browser engine, doesn't have the keys for SSH or VPN access.
Re: Making an SSH client the hard way
#39In 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?
Re: Making an SSH client the hard way
#40Earlier quoted context omitted.
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…
Talking about inner platforms (and in case there's one person left who hasn't seen it): https://www.destroyallsoftware.com/talks/the-birth-and-death...
"""The inner-platform effect is the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using. This is generally inefficient and such systems are often considered to be examples of an anti-pattern."""
Like I said elsewhere, I'm not completely opposed to the idea of the browser as a complete and fully functional application container for an inner platform. And I want to encourage creative people to try new technologies, especially WASM to explore the idea of "how much can we move to the browser". However, I see the container as the mediator of the network, not the application.