4 ms·

> I can always ssh to any of my machines (or the VMs) from anywhere. It's just simpler. Exposing an sshd to the public internet seems very risky. IPv6 or not.

by pilif 8y ago

> I can always ssh to any of my machines (or the VMs) from anywhere. It's just simpler. Exposing an sshd to the public internet seems very risky. IPv6 or not. Even with v6 in your LAN, you probably still want the firewall to drop all incoming connections and then use some kind of VPN or bastion host to get inside

jessaustin 8y ago
GP probably has password login turned off in sshd...
Fnoord 8y ago
> Exposing an sshd to the public internet seems very risky. IPv6 or not. That depends on factors. Personally, I prefer an SNT/VPN such as ZeroTier or WireGuard. SSH would suffice, so would SSH over Tor. Thing is though; you only need to expose 1 of these to public internet. The rest is redundant. Which can be useful though.
jacob019 8y ago
disable password authentication, ssh keys are secure enough
- pilif 8y ago
  would you rather emergency security patch opensshd on 10 machines or one bastion host?
  - supertrope 8y ago
    If you're worried about zero days you might consider not allowing SSH through firewall and requiring connecting to VPN first. That'd require a flaw in both OpenVPN and SSH.
  - jacob019 8y ago
    Not worth the added complexity. Exposing sshd (w/ disabled passwords) is common practice and fine for most use cases. Special use cases may require special precautions, but even airgapped systems can be compromised with enough effort. I'll take my chances with the industry standard and update as needed.
tialaramex 8y ago
If you just choose a completely arbitrary IPv6 address in your subnet for the server, random bad guys won't find it. This feels unintuitive, after all my IPv4 SSH servers have people banging on them 24/7, but that's orders of magnitude for you, bad guys who can try one host per second every second of every day, for a lifetime, can explore all of the actively deployed unicast IPv4 space. But those same bad guys will drown in the enormity of a single 64-bit IPv6 home subnet, never finding anything unless a well known address (e.g. ::80 for a web server is popular) was used for a server. If you use the default static addressing ("default" in the protocol sense, it's not the default in any major desktop OS today) they might find you, in a lifetime's worth of searching, by being clever and looking at specific device manufacturers. You probably have a MAC address from a popular company like Intel or 3Com, and there are only a few billion of those laying around, so it's a headstart. But you don't have to give them that headstart. So don't, just pick a random address from the other half of the pool. Roll dice if you don't trust your RNG.
- supertrope 8y ago
  No longer letting ssh listen on IPv4 address definitely cuts down on brute force attempts. One caveat is someone cleverly found a workaround to do the seemingly impossible task of scanning IPv6 address ranges. They hosted a NTP server and harvested live addresses. So I guess those who disable NTP on the most sensitive VMs might be right. One is already suppose to have a local NTP server anyway, if only by pointing hosts to the firewall's ntpd.
- Symbiote 8y ago
  Statistics since 1 June: An SSH server on port 22, home broadband connection: 212k failed IPv4 login attempts, zero failed IPv6 login attempts. An SSH server on port 22, university connection: 269k failed IPv4 login attempts, zero on IPv6. > If you just choose a completely arbitrary IPv6 address in your subnet for the server, random bad guys won't find it. So that is true, but it also seems they won't even bother looking. My computer is as obvious as I can make it, it's listening on 2001:xxxx:xxx0::1/44, and still has had no attempts. Nothing on port 80 either. And of course, there's nothing to prevent having several IPs on one machine, each for a different service. A DNS name for a web server then isn't revealing a possible SSH server.
devereaux 8y ago
My raspberry pi, home weather station, and test VMs are not THAT sensitive :) Besides, with temporary IPv6, I don't think I have much to fear.

by pilif 8y ago

jessaustin 8y ago

GP probably has password login turned off in sshd...

Fnoord 8y ago

> Exposing an sshd to the public internet seems very risky. IPv6 or not. That depends on factors. Personally, I prefer an SNT/VPN such as ZeroTier or WireGuard. SSH would suffice, so would SSH over Tor. Thing is though; you only need to expose 1 of these to public internet. The rest is redundant. Which can be useful though.

jacob019 8y ago

disable password authentication, ssh keys are secure enough

pilif 8y ago
would you rather emergency security patch opensshd on 10 machines or one bastion host?
- supertrope 8y ago
  If you're worried about zero days you might consider not allowing SSH through firewall and requiring connecting to VPN first. That'd require a flaw in both OpenVPN and SSH.
- jacob019 8y ago
  Not worth the added complexity. Exposing sshd (w/ disabled passwords) is common practice and fine for most use cases. Special use cases may require special precautions, but even airgapped systems can be compromised with enough effort. I'll take my chances with the industry standard and update as needed.

tialaramex 8y ago

If you just choose a completely arbitrary IPv6 address in your subnet for the server, random bad guys won't find it. This feels unintuitive, after all my IPv4 SSH servers have people banging on them 24/7, but that's orders of magnitude for you, bad guys who can try one host per second every second of every day, for a lifetime, can explore all of the actively deployed unicast IPv4 space. But those same bad guys will drown in the enormity of a single 64-bit IPv6 home subnet, never finding anything unless a well known address (e.g. ::80 for a web server is popular) was used for a server. If you use the default static addressing ("default" in the protocol sense, it's not the default in any major desktop OS today) they might find you, in a lifetime's worth of searching, by being clever and looking at specific device manufacturers. You probably have a MAC address from a popular company like Intel or 3Com, and there are only a few billion of those laying around, so it's a headstart. But you don't have to give them that headstart. So don't, just pick a random address from the other half of the pool. Roll dice if you don't trust your RNG.

supertrope 8y ago
No longer letting ssh listen on IPv4 address definitely cuts down on brute force attempts. One caveat is someone cleverly found a workaround to do the seemingly impossible task of scanning IPv6 address ranges. They hosted a NTP server and harvested live addresses. So I guess those who disable NTP on the most sensitive VMs might be right. One is already suppose to have a local NTP server anyway, if only by pointing hosts to the firewall's ntpd.
Symbiote 8y ago
Statistics since 1 June: An SSH server on port 22, home broadband connection: 212k failed IPv4 login attempts, zero failed IPv6 login attempts. An SSH server on port 22, university connection: 269k failed IPv4 login attempts, zero on IPv6. > If you just choose a completely arbitrary IPv6 address in your subnet for the server, random bad guys won't find it. So that is true, but it also seems they won't even bother looking. My computer is as obvious as I can make it, it's listening on 2001:xxxx:xxx0::1/44, and still has had no attempts. Nothing on port 80 either. And of course, there's nothing to prevent having several IPs on one machine, each for a different service. A DNS name for a web server then isn't revealing a possible SSH server.

devereaux 8y ago

My raspberry pi, home weather station, and test VMs are not THAT sensitive :) Besides, with temporary IPv6, I don't think I have much to fear.