7 ms·

Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night.

• feld 11y ago
  Unless they can provide a username that crashes fail2ban via blowing up the regex parsing... and then they get all the free tries they want. fail2ban/sshguard/etc are not infallible. Someone will find a way to break them.
  • mzs 11y ago
    I think fail2ban does not do IPv6 yet.
    • Aloha 11y ago
      I also get 0 attempts via IPv6 interestingly enough. That said, I think fail2ban does support v6 now, but not all of the firewalls do (like ipfw on my ancient ppc mac)
• jandrese 11y ago
  Then you're screwed when you need to log on to your server from some random machine that doesn't have your key installed.
  • cbhl 11y ago
    You can mitigate this by having lots of machines with your key installed (at least two), in different physical locations.
  • TheDong 11y ago
    Good. If you can login from "some random machine" that means your password is terribly weak as well. Use a password manager, generate passwords with over 100 bits of entropy, and then you can't log into anything without it present. Now start carrying around your password manager on an encrypted thumbdrive, along with your gpg key and private ssh key with the decryption password + password manager password being the only ones you remember. Any password a human creates and remembers is a problem. The best mitigation is to only remember passwords that are only useful in conjunction with physical access (the password manager / decryption ones).
    • ChristianBundy 11y ago
      >generate passwords with over 100 bits of entropy Is this arbitrary, or is there a specific reason you recommend at least 100 bits of entropy?
      • UnoriginalGuy 11y ago
        Not them, but this is arbitrary, and frankly a confusing way of even defining a password's strength. A password's strength is measured by both how it was created and also its absolute length. In this case they're simply calling anything longer than 12.5 ASCII characters or 6.25 Unicode characters secure. While those are good solid lengths for passwords (in both cases due to the larger character set of Unicode), without knowing exactly how they were calculated it is completely arbitrary. For example for a sentence-based password, 100 bits is insecure. But for a password generated using the secure random number generator, it is absolute unbreakable e.g. "goodnight moon": Insecure but 120 bits (16 chars) of 'entropy' "5%ML#_rjMe": Secure but "only" 80 bits (10 chars) of 'entropy' Now you could argue, that the word 'entropy' would discount any sentence based passwords by definition, but that's not how I've seen people [mis]use it. They call any content of a password that password's 'entropy.' I also want to take a moment to make fun of people measuring character passwords in bits (as opposed to characters). The whole bits thing started when people are contrasting character based passwords with other types of passwords like certificate based (as a way of showing how much more secure certificate based authentication is). It makes absolutely no sense to use bits in a discussion about purely character based passwords, and people only do it because they witness others do it but have no concept of WHY.
  • jms703 11y ago
    That's fine. Who knows what happens when you enter your password on the machine or if you have agent forwarding enabled.
  • tytso 11y ago
    Nope, because my ssh key is on my phone and my tablet, with an ssh client, and I pretty much always have my phone with me. I do have a USB thumb drive with a bootable standalone system which I could use on a random mmachine --- but even if that solves the problem of exposing my password or ssh keys to a system which has malware on it, I pretty much assume that random machines, especially those at airport lounges or internet cafes, probably have keyboard bugs installed, so I wouldn't really trust my bootable thumb drive on those machines anyway. I might use the thumb drive on a friend's machine which I really trusted, but most of the time I'd much rather use a trusted machine that I own, such as either my tablet or my laptop, or in the extreme cases, my phone.
  • deleted 11y ago
    [deleted]
• heywire 11y ago
  I've always wanted to disable password based auth, but I am worried that if I need to connect to my machine in a pinch from some random device (wife's phone, borrowed machine from friend, work, etc), that I won't be able to connect. How do people get around this? Keep in mind that I'm talking about home machines and hobby VM instances, I do not manage any production servers or anything.
  • UnoriginalGuy 11y ago
    Create a normal user, DON'T add them to the sudo group (or any other special group), and then generate keys for them. Store those keys in some online "cloud" storage (DropBox, Google Drive, OneDrive, et al). Then if you need to get in, download the key, type in the password, login as that user, and the su up to root by entering the password only you know. As an additional layer of security you could encrypt the key using AES-256 (e.g. 7Zip archive, Microsoft Office's Word .docx (NOT .doc) format (just drag drop the file into Word, "Encrypt with password") now AES-256 encrypted, others). Now you have four layers of protection: - su password. - Key password. - AES-256 encryption password. - "Cloud" storage credentials.
    • larrys 11y ago
      So in short store the keys in some place that you have easy access to by a password. Kind of a version of two factor "something you know and something you have" whereby the "something you have" is the cloud storage device with the key.
    • cbsmith 11y ago
      While I'm a big believer in defense in depth, I think this adds a lot more complexity on the usability side without really improving the overall security. You'd be better off just protecting the private key with more trials and storing it with whichever cloud storage solution you have the most confidence in.
  • kryptiskt 11y ago
    Put a key on your phone or an USB stick. I make a key for every machine that I have, and that keys never leaves that machine. In addition I keep another key that I can use to get started again if my laptop gets stolen or breaks. If I lose the phone, there's a pretty good password on that key that should give me ample time to remove access rights for it.
• voidlogic 11y ago
  To secure SSH, the more I care about a system the farther down this list I go. 1. Disable root 2. Use keys, disable passwords 3. Install fail2ban 4. Restrict incoming subnets 5. MathAuthTries = 1 6. Run on high random port 7. Use port knocking
  • steckerbrett 11y ago
    If your threat model has someone stealing your private key and breaking/obtaining the password to it, none of the other measures are going to mean anything as they have root on your box. With root they can bypass the access restrictions, knocking, whatever else. 2FA with an external device would probably make more sense than any of them and be significantly less irritating.
    • emidln 11y ago
      That assumes that stealing your private key is the same thing as sending arbitrary packets from your machine, otherwise things like restricting subnets/ip addresses and port knocking could still be useful layers. How different exfil of a private key from being able to send arbitrary packets on the user's machine is...probably not that different under most circumstances I'd guess.
    • voidlogic 11y ago
      I'd recommend encrypting your private keys if needed with a pass-phrase. I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. 2 factor with a token is ideal, I suppose I should have added that to the list, but that is outside of feasibility for most users. Still, for someone who doesn't have RSA tokens etc available, assuming your remote machine doesn't get owned and someone doesn't extract your pass-phrase with a wrench, that list makes for a very secure system.
      • cbsmith 11y ago
        > I'd also recommend still requiring a sudo password on the other end and sending auth events to a auditing server. You should be auditing everything already, and adding in sudo now adds another attack vector. You also now have two different accounts that can be manipulated to compromise a system.
• scintill76 11y ago
  I've been toying with the idea of making a tool to derive SSH keys directly from memorable passphrases, with something like scrypt. Almost as convenient as a normal passphrase, almost as secure as a random key! ("Secure" because presumably no script kiddies are bruteforcing keys like they are bruteforcing passwords.) Besides the dubious security value, another reason I haven't bothered is that if you don't have convenient+secure access to a proper key, you're not going to have convenient+secure access to the key generator either. Maybe it could still be an excuse to learn a new language and how SSH keys work. I don't know if I could rationalize even tossing it up on Github with warnings though.
  • nickpsecurity 11y ago
    Generating simple ones then encrypt & MAC them with password-derived key seems simpler. There's standard constructions for each step, too.
  • cbsmith 11y ago
    Yeah, I'm not seeing the point of doing that. You might as well create the key, encrypt it with the passphrase as per usual, and then post it online for all to see. It's effectively the same thing as generating the key from the pass phrase, except you are mixing in a nice giant product of two primes in to the mix.
    • scintill76 11y ago
      Well, I don't know a lot of the math and crypto, but I would probably seed an RNG from the stretched key and then pull large primes out just as ssh-keygen would. You're right, though -- given my "requirements", it's not much more to assume a convenient place to store a normal, encrypted key. It can be public since I already based my security on the password strength and some obscurity. I wouldn't use either of these ideas for any serious production server. For the deterministic key, you could "backdoor" ssh-keygen's RNG through something like LD_PRELOAD... at that point it's probably just piping a couple of pre-made shell utils together, which could be more portable and simple than rolling-your-own all the key export stuff. Actually, this strikes me as potentially useful and secure in some niche cases where you don't trust your RNG and/or storage. Use diceware and write your long key down, derive anew for each use. Maybe it's silly, but I would consider something like that (at least the initial deriving part) if I were very paranoid or making a long-lived, deeply-deployed key. Here's a deterministic Ed25519 SSH key generator that takes a 32-byte seed: https://github.com/mithrandi/ssh-key-generator https://github.com/mithrandi/ssh-key-generator