Slashdot Mirror

← Back to Stories (view on slashdot.org)

Tips For Securing Your Secure Shell

Posted by Soulskill on from the locking-your-locks dept.

jones_supa writes: As you may have heard, the NSA has had some success in cracking Secure Shell (SSH) connections. To respond to these risks, a guide written by Stribika tries to help you make your shell as robust as possible. The two main concepts are to make the crypto harder and make stealing keys impossible. So prepare a cup of coffee and read the tutorial carefully to see what could be improved in your configuration. Stribika gives also some extra security tips: don't install what you don't need (as any code line can introduce a bug), use the kind of open source code that has actually been reviewed, keep your software up to date, and use exploit mitigation technologies.

3 of 148 comments (clear)

  1. Re:new goals by TheGratefulNet · · Score: 2, Informative

    the current NSA is an imoral, ILLEGAL, unamerican organization.

    I see nothing at all wrong with actively trying to avoid them and their illegal unconstitutional spying.

    demanding privacy != 'guilty of something'

    --

    --
    "It is now safe to switch off your computer."
  2. RC4, how weak is it? by hankwang · · Score: 4, Informative

    TFA: "... RC4 are broken. Again, no need to wait for them to become even weaker, disable them now."

    Is that really so? I think RC4/arcfour is only known to leak secret data in the first 2 KB of the cipher stream, and for that reason SSH will simply feed it 2 KB or so of garbage data before encrypting the actual payliad. Or am I mistaken?

    RC4 has a big advantage: it is by far the fastest cipher, which is relevant if you want to do large file transfers over slowish hardware (home-grade NAS, Raspberry Pi, old Atom CPU, etc.).

    --
    Avantslash: low-bandwidth mobile slashdot.
  3. Re:Well Then by mlts · · Score: 5, Informative

    Those are OK recommendations... but I'd probably add a few of my own:

    1: First and foremost, limit the IP address space of what the SSH daemon can communicate with. If the bad guys can't get to the front door, they can't kick it in.

    2: Install SSHGuard, Fail2Ban, or a tarpit program. This won't stop the distributed brute force attacks that do 2-3 guesses per IP block, but it is a line of defense.

    3: 2FA. I use the Google Authenticator as backup to RSA keys.

    4: If root doesn't need SSH access, don't allow it.

    My concern is with the bad guys getting in, although cipher choice is important. However implementing SSH is just as much about access control as it is about encryption.