71–80 of 181 posts
Earlier quoted context omitted.
ssh by default sends all your public keys to a server. Yes you can limit some keys to specific hosts but it's very easy to dox yourself.
so it's good practice to store key in non-default location and use ~/.ssh/config to point the path for each host?
Earlier quoted context omitted.
ssh by default sends all your public keys to a server. Yes you can limit some keys to specific hosts but it's very easy to dox yourself.
so it's good practice to store key in non-default location and use ~/.ssh/config to point the path for each host?
This is just an awfully designed feature, is all.
Earlier quoted context omitted.
They could buy a dedicated IPv4 address, but that address still has to be tunneled through [EDIT:] IPv6 networks if that dev has no access to [EDIT:] IPv4 networks. Thus DX still suffers. [ADDENDUM: I mistakenly swapped "IPv4" and "IPv6" there. See comments.]
I'm not sure I understand your point; if exe.dev operates a dedicated IP solely so a specific mythical IPv6-less developer can connect to a specific server, then there's no tunnelling involved at all.
> they could pay a small extra for a dedicated IPv4 address.
Did you mean that the dedicated IPv4 address to connect via SSH? Then my objection doesn't apply.
Earlier quoted context omitted.
ssh by default sends all your public keys to a server. Yes you can limit some keys to specific hosts but it's very easy to dox yourself.
Doesn’t it try one key at a time rather than send all?
You can try it yourself [0] returns all the keys you send and even shows you your github username if one of the keys is used there.
[0] ssh whoami.filippo.io
Not exactly what i built in for, but it'll do the job here too, and able to connect to private addresses on the server side.
> 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…
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.
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 with two sides behind CGNAT which require dedicated effort to even work.
I know it sucks if none of the ISPs in your area support IPv6 and you're left with suboptimal solutions like tunnels from HE, but I think it's only reasonable all this extra cost or effort becomes visible at some point. Half the world is on v6, legacy v4-only connections are becoming the minority now.
> 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…
SSH is an incredibly versatile and useful tool, but many things about the protocol are poorly designed , including its essentially made-up-as-you-go-along wire formats for authentication negotiation, key exchange, etc. In 2024-2025, I did a survey of millions of public keys on the Internet, gathered from SSH servers and users in addition to TLS hosts, and discovered—among other problems—that it's incredibly easy to m…
That's the point, though. An SSH key gives authentication, not authorization. Generally a certificate is a key signed by some other mutually trusted authority, which SSH explicitly tried to avoid.
This would be a great use case of SSH over HTTP/3[0]. Sadly it doesn't seem to have gained traction. [0]: https://www.ietf.org/archive/id/draft-michel-ssh3-00.html
I also know how to use SRV records so this is a non-issue for me and everyone I work with.
Earlier quoted context omitted.
so it's good practice to store key in non-default location and use ~/.ssh/config to point the path for each host?
What a great case of "you're holding it wrong!" I need to add individual configuration to every host I ever want to connect to before connecting to avoid exposing all public keys on my device? What if I mistype and contact a server not my own by accident? This is just an awfully designed feature, is all.
Are you AI?
You can wildcard match hosts in ssh config. You generally have less than a dozen of keys and it's not that difficult to manage.