[dead]
SSH has no Host header
121–130 of 181 posts
Re: SSH has no Host header
#122Earlier quoted context omitted.
Using nonstandard ports would break the `ssh foo.exe.dev` pattern. This could also have been solved by requiring users to customize their SSH config (coder does this once per machine, and it applies to all workspaces), but I guess the exe.dev guys are going for a "zero-config, works anywhere" experience.
[flagged]
SSH configs support wildcards, so if you couple it with a ProxyCommand you can an arbitrary level of dynamism for a host pattern (like *.exe.dev).
But yeah, everything is a trade-off.
Re: SSH has no Host header
#123Earlier quoted context omitted.
Doesn’t it try one key at a time rather than send all?
Modern sshd limits the number of retries. I have 5 or 6 keys and end up DoSing myself sometimes.
This thread made me realize why fail2ban keeps banning me after one failed password entry :lightbulb:
Re: SSH has no Host header
#124We all should do our part to move to IPv6, the sooner, the better.
Re: SSH has no Host header
#125I would love it if more systems just understood SRV records, hostname.xyz = 10.1.1.1:2222 So far it feels like only LDAP really makes use of it, at least with the tech I interact with
This has history: https://egopoly.com/2008/02/ssh-slow-on-leopard.html I also know of https://github.com/Crosse/sshsrv and other tricks I agree more SRV records would have helped with a tremendous number of unnecessary proxies and wasted heat energy from unnecessary computing, but in this day and age, I think ECH/ESNI-type functions should be considered for _every_ new protocol.
SRV is essentially a simple layer of abstraction that provides (via one approach) the required end result (reachability + UX) that is easy to add to any $PROTO client without. Supporting ESNI would complicate the actual lib/protocol, increase the amount of dev and maintenance work required all around, significantly increase complexity, and require more infrastructure and invasive integration than any DNS-enabled service already uses.
Re: SSH has no Host header
#126You don't need SSH. Installing an SSH server to such a VM is a hold over from how UNIX servers worked. It puts you in the mindset of treating your server as a pet and doing things for a single vm instead of having proper server management in place. I would reconsider if offering ssh is an actual requirement here or if it could be better served by offering users a proper control panel to manage and monitor the vms.
Plenty of (cattle or pet) tooling essentially devolves to SSH under those layers of abstraction.
Re: SSH has no Host header
#127> We cannot issue an IPv4 address to each machine without blowing out the cost of the subscription. We cannot use IPv6-only as that means some of the internet cannot reach the VM over the web. That means we have to share IPv4 addresses between VMs. Give a user a option for use IPv6 only, and if the user need legacy IP add it as a additional cost and move on. Trying to keep v4 at the same cost level as v6 is not a thi…
(exe.dev co-founder here)
IPv6 does not work on the only ISP in my neighborhood that provides gigabit links. I will not build a product I cannot use.
Even when IPv6 is rolled out, it is only tested for consumer links by Happy Eyeballs. Links between DCs are entirely IPv4 even when dual stacked. We just discovered 20 of our machines in an LAX DC have broken IPv6 (because we tried to use Tailscale to move data to them, which defaults to happy eyeballs). Apparently the upstream switch configuration has been broken for months for hundreds of machines and we are the first to notice.
I am a big believer in: first make it work. On the internet today, you first make it work with IPv4. Then you have the luxury of playing with IPv6.
Re: SSH has no Host header
#128Earlier quoted context omitted.
This is great if you have IPv6 support from your ISP. Not so great if you don't. Before someone mentions tunnels: Last time I tried to set up a tunnel Happy Eyeballs didn't work for me at all; almost everything went through the tunnel anyway and I had to deal with non-residential IP space issues and way too much traffic.
ISPs won't bother with IPv6 until they've either run out of IPv4 space or the internet starts to use IPv6's advantages. Discussions about IPv6 quickly end with "we have enough v4 space and there are no services that require v6 anyway". As long as the extra cruft for v4 support remains free or even supported, large ISPs won't care. We're at the point where people need to deal with things like peer to peer connectivity…
(exe.dev co-founder here)
We are not running out of IPv4 space because NAT works. The price of IPv4 addresses has been dropping for the last year.
I know this because I just bought another /22 for exe.dev for the exact thing described in this blog post: to get our business customers another 1012 VMs.
Re: SSH has no Host header
#129Earlier quoted context omitted.
I also wonder what happens if you want to grant access to your VM to additional public keys and one of those public keys happen to already be routed to a different VM on the same IP.
Github has a similar system and just refuses to let you addthe key if it already exists. It's hacky but it's also obviously massively widespread.
I just encountered this the other day, in fact. You cannot utilize a single SSH key with multiple GitHub accounts.
Re: SSH has no Host header
#130I would love it if more systems just understood SRV records, hostname.xyz = 10.1.1.1:2222 So far it feels like only LDAP really makes use of it, at least with the tech I interact with
Even with SRV records, there’s still the problem of middleboxes restricting protocol traffic to certain ports. (There’s another comment thread in which we discuss this.) In practice, SRV records work much better inside network borders than on the larger Internet.