61–70 of 92 posts
Earlier quoted context omitted.
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
1. Disable root This doesn't add any security, it only makes your admin life miserable.
Earlier quoted context omitted.
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
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.
Earlier quoted context omitted.
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.
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…
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.
Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night. Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers. Other than that, the main gist of this post is: on most p…
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 conve…
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.
Earlier quoted context omitted.
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 conve…
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.
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
Earlier quoted context omitted.
Then you're screwed when you need to log on to your server from some random machine that doesn't have your key installed.
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 o…
-% mkpass -h
Usage: mkpass [options]
-a, --attacker [RATE] Assume an attacker capable of RATE guesses/second (default: 1000000000)
-t, --time [DAYS] Resist an attack for up to this many days (default: 3652)
-b, --bits [BITS] Generate a password with this many bits of entropy (default automatic)
-l, --length [LENGTH] Make LENGTH word/char passwords (default automatic)
-n, --number [NUM] Make NUM passwords (default 1)
-w, --wordlist [FILE | name] Use file as wordlist (default comm3000 3esl)
-v, --verbose
-% mkpass -v
Complexity 22088^5, 72 bits of entropy. 1811 centuries at 1000000000 guesses/sec
messy photo groceries stoke horse
-% mkpass -vb 100
Complexity 22088^7, 101 bits of entropy. 88357157 million years at 1000000000 guesses/sec
ungainly shopping mall dissociation turf across stridden microphone
-% mkpass -vl3
Complexity 22088^3, 43 bits of entropy. 2 hours at 1000000000 guesses/sec
Weak passphrases: estimate 43 bits of entropy. 50+ recommended (length=5)
terrace lower-class paneling
-% mkpass -vw pin
Complexity 10^18, 59 bits of entropy. 34 years at 1000000000 guesses/sec
366565907478491511
-% mkpass -vw alnum
Complexity 62^10, 59 bits of entropy. 28 years at 1000000000 guesses/sec
cTDng2KioEI am curious as to what happens when this is done with an existent user? I feel like there would be different behaviors for timeouts when a non-existent username is used and when a wrong password is used for an existent username.
No, the behavior needs to be identical in all failure cases or attackers can use the different feedback to learn valid usernames, etc
Earlier quoted context omitted.
1. Disable root This doesn't add any security, it only makes your admin life miserable.
I keep trying to explain to people that if anything this adds complexity to the security problem...
We do it at work for accountability purposes, but I'm not sure I'm clear on the security implications.
Key takeaway: > And as several correspondents have reminded me already -- switching your sshd to keys only authentication will let you sleep better at night. Even with fail2ban and limited retries, there's no excuse for using password-based authentication anymore. Use an SSH key, protect the key with a password, and turn off password login on all your servers. Other than that, the main gist of this post is: on most p…
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.