6 ms·

>OpenSSH is exposed to the internet a lot (even if, yes, that is not best practice) Please elaborate.

eropple 11y ago
A VPN with sshd exposed only inside the private network is a much smarter way of handling remote access. (But it's initially harder, so lots of people don't do it.)
- munin 11y ago
  the code for the VPN is better because...?
  - tjohns 11y ago
    It's not necessarily better. But now you have two layers of security (VPN + SSH), rather than just one. And as others have mentioned, either way it's still good practice to disable password auth, so that you can only connect to SSH using a public/private keypair.
    - baldfat 11y ago
      Even better don't use default ports. Or have a second ssh that doesn't except any IP address at port 22 and than have your non-standard port with keys and limited user names and if possible a white list of your IP addresses.
      - eropple 11y ago
        Not using default ports will mildly confuse automated scans and do absolutely nothing to a determined attacker. Or somebody with nmap, which is not the same thing. If you're whitelisting IPs, you may as well run it on port 22.
        baldfat 11y ago
        No it makes it harder and more of a pain. Trust me I have a friend who loves breaking into my personal server. That one trick two ssh running on different ports screwed with him for a long, long time. He is a genius of a hacker and has been doing it for a living for years. When he finally got in he was so pissed that threw him.
        eropple 11y ago
        You are describing an anecdotal instance of a person whose capabilities are not established being thrown by something that nmap will catch on a normal scan. Color me skeptical. I shall decline to "trust you."
        baldfat 11y ago
        nmap the whole internet isn't very fast
        tacticus 11y ago
        Scanning the internet isn't that slow https://www.youtube.com/watch?v=UOWexFaRylM https://www.youtube.com/watch?v=UOWexFaRylM
        DrPizza 11y ago
        > Trust me I have a friend who loves breaking into my personal server. Sterling work establishing your own competence there.
        baldfat 11y ago
        Not my competence it his competence I trust and I got him good with that one since it never occurred to him that one stupid trick messed with him for so long. Lie 5 minutes a month.
        mortenlarsen 11y ago
        One small benefit of using a non default port is that it keeps down the noise from automated scans. So any "real" suspicious activity will now stand out as it is not drowned out by the noise anymore.
      - tpio 11y ago
        If you do this, keep it in the privileged range (< 1024) or you run the risk of your ssh server crashing and some malicious normal user binds to your unprivileged port with a fake sshd and grabs your root password.
    - mattstreet 11y ago
      If there is a defect with VPN and you gain arbitrary execution then you'd have access on the system as whatever user the VPN was running as. You don't necessarily have to break VPN and SSH.
      - dpark 11y ago
        The machines running your VPN are presumably not the same machines you're trying to access via SSH. A compromise in your VPN should't give anyone execution access to anything interesting.
  - jarman 11y ago
    If VPN is broken, you still need to break SSH
  - CHY872 11y ago
    The reason that no one has given yet is that you can monitor more carefully when you have a VPN. With a VPN, you can follow the bastion model; the VPN server runs only the VPN code and nothing else (with as much crap removed as possible), with a really restrictive SELinux policy, every tiny error logged and forwarded. So now, since any attack has to be through the bastion, and all bastion errors are looked at by a human (because there should be only a few of them), then you're more likely to notice a breach more quickly because it won't become caught up in your general logs. It should be noted that it's as easily possible to have the bastion server run an SSH server, and allow SSH access to other servers on your network.
- e40 11y ago
  You're just trading sshd bugs for VPN bugs, in that case. Which are more likely? From what I know, I think I'll put my lot in with sshd. Perhaps I'm not well informed, though. Also, sshd + fwknop (port knocking) is a very secure combo, IMO.
  - smhenderson 11y ago
    PubkeyAuthentication and disabling password logins helps a lot too. I've also been using deny_hosts a lot over the last couple years as an extra layer.
  - hammerandtongs 11y ago
    With openvpn (which is just ssl) you can simply not respond when someone presents a bad key. openssh always responds (unless I've missed a recent feature) thus exposing which port its listening on and that you sent a bad key. The silent failure is preferable for this application. Port knocking gives you a roughly equivalent layer.
    - XorNot 11y ago
      And both these things you never do in production because it takes little effort to establish there must be a port open, whereas the cumulative time you'll spend tracking down whether its a network issue or bad/wrong keys is just not worth it. Not to mention: nobody's going to be brute-forcing properly generated keys remotely. And if they're not properly generated, you have much bigger problems.
    - beagle3 11y ago
      openvpn, which is just ssl, was vulnerable to heartbleed. Like the GP said - you're trading VPN bugs for SSH bugs - and experience shows that betting on SSH is generally wiser. If you only need TCP/DNS and not a full-blown VPN, a program called sshuttle uses ssh+python to provide excellent seamless poor man's VPN. It's not perfect - e.g., you lose the ip src address on the forwarded connections - but it works amazingly well, much better than e.g. openvpn and most other vpn products I've used.
  - eropple 11y ago

A VPN with sshd exposed only inside the private network is a much smarter way of handling remote access. (But it's initially harder, so lots of people don't do it.)

munin 11y ago
the code for the VPN is better because...?
- tjohns 11y ago
  It's not necessarily better. But now you have two layers of security (VPN + SSH), rather than just one. And as others have mentioned, either way it's still good practice to disable password auth, so that you can only connect to SSH using a public/private keypair.
  - baldfat 11y ago
    Even better don't use default ports. Or have a second ssh that doesn't except any IP address at port 22 and than have your non-standard port with keys and limited user names and if possible a white list of your IP addresses.
    - eropple 11y ago
      Not using default ports will mildly confuse automated scans and do absolutely nothing to a determined attacker. Or somebody with nmap, which is not the same thing. If you're whitelisting IPs, you may as well run it on port 22.
      - baldfat 11y ago
        No it makes it harder and more of a pain. Trust me I have a friend who loves breaking into my personal server. That one trick two ssh running on different ports screwed with him for a long, long time. He is a genius of a hacker and has been doing it for a living for years. When he finally got in he was so pissed that threw him.
        eropple 11y ago
        You are describing an anecdotal instance of a person whose capabilities are not established being thrown by something that nmap will catch on a normal scan. Color me skeptical. I shall decline to "trust you."
        baldfat 11y ago
        nmap the whole internet isn't very fast
        tacticus 11y ago
        Scanning the internet isn't that slow https://www.youtube.com/watch?v=UOWexFaRylM https://www.youtube.com/watch?v=UOWexFaRylM
        DrPizza 11y ago
        > Trust me I have a friend who loves breaking into my personal server. Sterling work establishing your own competence there.
        baldfat 11y ago
        Not my competence it his competence I trust and I got him good with that one since it never occurred to him that one stupid trick messed with him for so long. Lie 5 minutes a month.
      - mortenlarsen 11y ago
        One small benefit of using a non default port is that it keeps down the noise from automated scans. So any "real" suspicious activity will now stand out as it is not drowned out by the noise anymore.
    - tpio 11y ago
      If you do this, keep it in the privileged range (< 1024) or you run the risk of your ssh server crashing and some malicious normal user binds to your unprivileged port with a fake sshd and grabs your root password.
  - mattstreet 11y ago
    If there is a defect with VPN and you gain arbitrary execution then you'd have access on the system as whatever user the VPN was running as. You don't necessarily have to break VPN and SSH.
    - dpark 11y ago
      The machines running your VPN are presumably not the same machines you're trying to access via SSH. A compromise in your VPN should't give anyone execution access to anything interesting.
- jarman 11y ago
  If VPN is broken, you still need to break SSH
- CHY872 11y ago
  The reason that no one has given yet is that you can monitor more carefully when you have a VPN. With a VPN, you can follow the bastion model; the VPN server runs only the VPN code and nothing else (with as much crap removed as possible), with a really restrictive SELinux policy, every tiny error logged and forwarded. So now, since any attack has to be through the bastion, and all bastion errors are looked at by a human (because there should be only a few of them), then you're more likely to notice a breach more quickly because it won't become caught up in your general logs. It should be noted that it's as easily possible to have the bastion server run an SSH server, and allow SSH access to other servers on your network.
e40 11y ago
You're just trading sshd bugs for VPN bugs, in that case. Which are more likely? From what I know, I think I'll put my lot in with sshd. Perhaps I'm not well informed, though. Also, sshd + fwknop (port knocking) is a very secure combo, IMO.
- smhenderson 11y ago
  PubkeyAuthentication and disabling password logins helps a lot too. I've also been using deny_hosts a lot over the last couple years as an extra layer.
- hammerandtongs 11y ago
  With openvpn (which is just ssl) you can simply not respond when someone presents a bad key. openssh always responds (unless I've missed a recent feature) thus exposing which port its listening on and that you sent a bad key. The silent failure is preferable for this application. Port knocking gives you a roughly equivalent layer.
  - XorNot 11y ago
    And both these things you never do in production because it takes little effort to establish there must be a port open, whereas the cumulative time you'll spend tracking down whether its a network issue or bad/wrong keys is just not worth it. Not to mention: nobody's going to be brute-forcing properly generated keys remotely. And if they're not properly generated, you have much bigger problems.
  - beagle3 11y ago
    openvpn, which is just ssl, was vulnerable to heartbleed. Like the GP said - you're trading VPN bugs for SSH bugs - and experience shows that betting on SSH is generally wiser. If you only need TCP/DNS and not a full-blown VPN, a program called sshuttle uses ssh+python to provide excellent seamless poor man's VPN. It's not perfect - e.g., you lose the ip src address on the forwarded connections - but it works amazingly well, much better than e.g. openvpn and most other vpn products I've used.
- eropple 11y ago