1. -5

  2. 3

    Having OpenSSH listen on odd port numbers can be defeated by port scanning.

    Definitely. This is not a security measure. It is a peace-of-mind measure, to prevent hoards of script kiddies from inundating your logs with a torrent of noise.

    If an employee can connect via their mobile phone or laptop and said device is sold, stolen or seized then any port-knocking configuration, as well as any private keys, will be compromised.

    Use a hardware token. There are many to choose from, including some that are completely open. I’m probably going to get a SoloKey in the next couple of weeks. If you’re serious about SSH security, I cannot emphasize “use a hardware token” too strongly or say it too frequently.

    ~/.ssh/authorized_keys files are rarely reviewed. Staff depart a business but their credentials can live on.

    They shouldn’t need to be reviewed individually. They should be managed by a software configuration management system like ansible. The offboarding process should require revoking those keys in the master config and then deploying an update.

    SSH keys are effectively radioactive. They are very useful but there are much safer and more reliable ways to connect via SSH.

    It’s also possible to go full PKI with the certificate stuff in OpenSSH. I haven’t used it, but I’ve encountered some folks on IRC who love it.

    Personally I disable password authentication and keyboard-interactive authentication in sshd_config on machines that run OpenSSH. When I’m super serious about the machine, I run tinyssh[1]. It requires public key authentication. There are almost no knobs to twiddle, so it is difficult to misconfigure.

    [1] https://tinyssh.org/

    1. 2

      Having deployed a PKI based ssh solution twice now, the “big” drawback is that a handful of popular tools (its mainly JetBrains products) which work over SSH don’t support SSH over PKI. Depending on your use cases and internal software stack, this might be a deal breaker.

      1. 2

        Very few businesses want to see BZ’s (or any of their competitors’) level of features re-implemented by someone on an hourly rate.

        You’re right about offboarding but how many smallish businesses are religious about following those guidelines? How many businesses have loads of random EC2 instances that were launched by some fly-by-night data scientist that quit out of the blue?

      2. 2

        This doesn’t explain how to harden SSH at all. It explains how to hide SSH from the internet with a proprietary solution that brings its own attack vectors.

        You’re getting downvoted as spam because it almost reads like an ad for the vendor.

        1. 1

          The biggest problem with OpenSSH security in this regard is the fact that the locally managed PKI toolkits aren’t developed well enough yet. I would welcome an open source PKI tool that generated certificates such that:

          • they were compatible with OpenSSH;
          • they worked with OpenBSD’s ikev2 PKI infrastructure for IPSec;
          • they could be used internally for https, ldaps, and other server identification problems.

          This would more than adequately address the problem of SSH priv/pub keys by replacing them with certificates that have a manageable lifespan, yet remain as convenient as the key infrastructure that they replace. Also, note well that this is really a problem of the documentation around the potential new project more than anything else.