5 ms·

What benefits does port knocking give over and above a simple VPN? They're both additional layers of authentication, except a VPN seems much more rigorous and b

• jgalt212 2y ago
  VPNs drop your bandwidth speeds by 50% on average. And if tailscale has to use a relay server, instead of a direct connection, bandwidth will drop by 70-80%.
  • gruez 2y ago
    >VPNs drop your bandwidth speeds by 50% on average Source? Wireguard can do 1GB/s on decade old processors[1]. Even openvpn can do 258 Mb/s, which realistically can saturate the average home internet connection. Also, if we're talking about SSH connections, why does throughput matter? Why do you need 1 gigabit of bandwidth to transfer a few keystrokes a second? [1] https://www.wireguard.com/performance/ https://www.wireguard.com/performance/
    • jgalt212 2y ago
      We ran iperf on our multi-cloud and on prem network. > Also, if we're talking about SSH connections, why does throughput matter? scp, among other things, runs over ssh.
      • gruez 2y ago
        >scp, among other things, runs over ssh. Ironically scp/sftp caused me more bandwidth headaches than wireguard/openvpn. I frequently experienced cases where scp/sftp would get 10% or even less of the transfer speed compared to a plain http(s) connection. Maybe it was due to packet loss, buffer size, or qos/throttling, but I wasn't able to figure out a definitive solution.
        • nh2 2y ago
          In almost all cases, the reason is OpenSSH's silly limitation of buffer sizes [1]. It limits the amount of data that's "in the cable" (which needs to be more if the cable is long). > The default SSH window size was 64 - 128 KB, which worked well for interactive sessions, but was severely limiting for bulk transfer in high bandwidth-delay product situations. > OpenSSH later increased the default SSH window size to 2 MB in 2007. 2 MB is still incredibly little. It means that on a 100 ms connection, you can not exceed 160 Mbit/s, even if your machines have 10 Gbit/s. OpenSSH is one of the very few TCP programs that have garbage throughput on TCP. This is also what makes rsync slow. The people from [1] patched that. You can support that work here: https://github.com/rapier1/hpn-ssh https://github.com/rapier1/hpn-ssh In my opinion, this should really be fixed in OpenSSH upstream. I do not understand why it doesn't just use normal automatic TCP window size scaling, like all other TCP programs. All the big megacorps and almost every other tech company in existence uses SSH, yet nobody seems to care that it's artificially 100x slower than necessary. [1]: http://www.allanjude.com/bsd/AsiaBSDCon2017_-_SSH_Performance.pdf http://www.allanjude.com/bsd/AsiaBSDCon2017_-_SSH_Performanc...
          • djmdjm 2y ago
            You can help by testing/reviewing https://github.com/djmdjm/openssh-wip/pull/29/commits/659cbc6516846aaeb86bb1b31d469afbd4799ab0 https://github.com/djmdjm/openssh-wip/pull/29/commits/659cbc...
            • nh2 2y ago
              Awesome!
          • nh2 2y ago
            I asked my "why not upstream" question here and got a response: https://github.com/rapier1/hpn-ssh/issues/89#issuecomment-2204069115 https://github.com/rapier1/hpn-ssh/issues/89#issuecomment-22...
• noname120 2y ago
  Port-knocking is way simpler and relies on extremely basic network primitives. As such the attack surface is considerably smaller than OpenSSH or OpenVPN and their authentication mechanisms.
• johnklos 2y ago
  Are you assuming that VPNs are more secure than ssh?
  • growse 2y ago
    No?
  • INTPenis 2y ago
    Yes, inherently yes. Because they have a lot less features than SSH. It's in the name; Secure Shell, vs. Virtual Private Network. One of them has to deal with users, authentication, shells, chroots. The other mostly deals with the network stack and encryption.