18 ms·

Some omissions IMO: never let people SSH in with a password, and for the love of god, stop leaving private SSH keys on servers. Privat SSH keys should never lea

• lathiat 6y ago
  This is a good theory and I mostly agree but if you disallow password logins, private keys on servers and agent forwarding - how do you copy things server to server without going through your slow and possibly remote local connection?
  • nerdbaggy 6y ago
    python3 -m http.server —bind 0.0.0.0 8080 is my favorite command
    • yjftsjthsd-h 6y ago
      If we're talking about security, then exposing your files to anything with network access to your server sounds like a terrible, terrible idea.
    • px43 6y ago
      I 100% endorse this method of securely moving files way way way above using things like agent forwarding and throwing keys on servers. It's shocking to me how people overlook HTTP as a tool for passing files around.
  • noodlesUK 6y ago
    Magic wormhole and friends are pretty good at doing this securely, especially between servers that can talk to each other without relays. See also croc
  • deleted 6y ago
    [deleted]
• systemvoltage 6y ago
  Why do you think this is a common problem? I've never heard of anyone leaving private keys on the server. Usually the ssh-keygen is run locally on their machine and the public key is deployed on the server.
  • 3np 6y ago
    Oh, I've seen it plenty times when users want to SSH from server A to server B, they copy their private key from their workstation to server A.
    • systemvoltage 6y ago
      Oh boy... I need to step out into the wilderness more :-D
    • bsder 6y ago
      Urk. Wow. The bigger issue is "Don't copy a private key. Ever. Period." How would you even do this? Don't the various private key containers make this quite difficult?
      • chrisan 6y ago
        It is just plain text in linux. Nothing hard to copy about it
    • midasuni 6y ago
      A natural consequence of server admins disabling ssh agent forwarding. All these “security truisms” tend to ignore the real world. When you remove features, people will work around it in a less secure way.
    • deleted 6y ago
      [deleted]
    • deckard1 6y ago
      A result of people not understanding how public/private keys work. They just want it to work, and copy everything over to get what they want done. These same people probably also joke about the marketing folks down the hall leaving post-it notes with their password on their monitor. Security is the first casualty in the battle for convenience.
• 3np 6y ago
  > Also SSH agent forwarding is the devil. Don't do it. Care to elaborate? First time I hear this.
  • viraptor 6y ago
    If you forward SSH agent, anyone with privileges to your sockets can use the agent. So for example when you log into some production machine, a process waiting on that machine connects to your agent and has access to... everything. (If you're agent caches key password you won't even get notified)
    • tomatocracy 6y ago
      Using ssh-add -c when adding keys means it asks for user confirmation (but can still cache the passphrase) each time key use is requested. This can mitigate some of the risk here in the absence of other solutions.
    • dpifke 6y ago
      Assuming your local agent silently signs all requests. This attack doesn't work if e.g. your Yubikey is configured to require a physical tap for every authentication.
  • marvion 6y ago
    Others already explained why. Matrix.orgs postmortem includes a real world exploitation: https://matrix.org/blog/2019/05/08/post-mortem-and-remediations-for-apr-11-security-incident https://matrix.org/blog/2019/05/08/post-mortem-and-remediati...
• andi999 6y ago
  How do you do key exchange if no pw login in ssh (here helpdesk prints random pws)
  • praptak 6y ago
    You can bootstrap key exchange from a short-lived password. Not perfect but at least limits the attack time window. Companies serious about security just have a trusted person hand out hardware with signed keys on it.
    • andi999 6y ago
      So is there a backup of the key on the hardware somewhere (in case it gets lost or destroyed)
      • praptak 6y ago
        Once you have exchanged the keys nothing stops you from creating new ones. You can for example register an additional backup Yubikey.
  • yjftsjthsd-h 6y ago
    Small scale: You generate a keypair and give the public key to whoever is setting up your account on the server. Large scale: You generate a keypair and give the public key to Vault or whatever, which signs it with the CA that all servers know to trust.
• BelenusMordred 6y ago
  > braindead advice in there too, like disabling RDRAND because there might be a backdoor Two sources of entropy xor'd will always be as strong as the best source. Done properly it's perfectly fine mixing rng sources you don't trust.
  • raegis 6y ago
    It is also important that the entropy sources are independent. For example, if RDRAND were defined in terms of /dev/xrandom, say by just flipping its bits, then doing (secret bits) xor (bits from /dev/xrandom) xor (bits from RDRAND) is very weak encryption. But of course, there is no reason to believe RDRAND is dependent on any of the usual random sources.
    • BelenusMordred 6y ago
      > (secret bits) xor (bits from /dev/xrandom) xor (bits from RDRAND) > is very weak encryption. It's as strong as the strongest source. This easily proven mathematically.
      • raegis 6y ago
        The mathematical result I think you are referring to is: any uniformly distributed random variable xored with any other independent random variable yields a uniformly distributed random variable. On the other hand, if we take the strongest random source in the universe, say X, and xor X with itself we get: X xor X = 0 The result is just a sequence of zeros, which is not "as strong as the strongest source". In practice, people may take lots of different "random" sources as input to their random generators to make them "more" random. But if you don't take care to check if they are independent, you may have a problem.
      • naniwaduni 6y ago
        On the contrary, the above computes exactly the identity cipher: your "ciphertext" is your plaintext. Mathematical results will lead you to surprising conclusions if apply them in the wrong context!
• mongol 6y ago
  How would you automate a job where a server uploads something, say a backup, to another server, without a private key?
  • ohazi 6y ago
    Standalone private key for a separate account that has write-only access to the backup area and little else? In this case the key would act more like an access token for a specific operation that you're trying to perform, rather than as a key to a generally usable account.
    • mongol 6y ago
      Yes that makes sense. I think grandparent could have been more precise. I assume he mean _personal_ private keys.
  • numpad0 6y ago
    I think he's talking about $ ssh-keygen -t rsa $ mv .ssh/id_rsa.pub .ssh/authorized_keys $ cat .ssh/id_rsa $ exit logout
  • mikewarot 6y ago
    In theory, I know Genode and other capability based systems could be answer this question... but not in practice. I'm off on that tangent seeking answers. Thanks for the "hacking prompt"
  • px43 6y ago
    Use HTTP, there's absolutely no reason to be using SSH if you're just transferring files around.
• swinglock 6y ago
  > RDRAND Did you read your own link?
• brobdingnagians 6y ago
  That source you shared seems to show that there could be a problem with tainted RDRAND, since it is xored in at the end of the function, and the linked email thread has comments by "maintainer of record (me) for the Linux RNG" who "quit the project about two years ago precisely because Linus decided to include a patch from Intel to allow their unauditable RdRand to bypass the entropy pool over my strenuous objections. From a quick skim of current sources, much of that has recently been rolled back" At the very least, that looks like there might be something in it. I don't know crypto well enough to say for sure, but it looks like Linus needs to re-read rand.h from what that article says about the state of the comments and previous rolled back changes from Intel. It does make one wonder if Linus' arrogance and rudeness could be used as cover for a genuine backdoor.
  • necheffa 6y ago
    It is xor'd because all entropy sources are xor'd. That's just the design of /dev/random. And because of this, Intel or whoever would need to have weakened each and every entropy source you use to make anything of it.
    • tremon 6y ago
      That's not true, because the RDRAND entropy is mixed in last. So once you're under the assumption that RDRAND is nefarious, the microcode only needs to detect the rdrand-to-xor pattern to make the entire entropy pool predictable (for example: by setting the non-rdrand input to the xor operation to zero it could disable all other entropy sources).
      • px43 6y ago
        A microcode backdoor capable of reading the existing entropy pool state is going to be a hell of a lot more powerful than a RDRAND backdoor, to the point of making a RDRAND backdoor worthless.
• samoa42 6y ago
  > never let people SSH in with a password this seems to be a recent cargo cult rooted in the fact that people tend to choose weak passwords and/or reuse them, but there is technically nothing wrong about it and the opensshd defaults (MaxStartups) make bruteforcing reasonable username/password combinations unfeaseable. A private key is just a very long password that is stored on disk and if there is no password on the key-file, it is stored there in plaintext an can be used by every other application (e.g. browser)
  • CraigJPerry 6y ago
    It’s not only bad passwords you’re battling against but social engineering and poor administrative practices. I’m comfortable with telling people to turn off password auth on their sshd’s and treat password auth as the exception rather than the rule. Also, it’s generally a nicer user experience.
  • sliken 6y ago
    Much of security improvements these days are not just enabling better security, but making them easy and default. Sure it's possible to: have a strong password, use it only for a single machine, keep it in a good password safe, never reuse it anywhere, have the discipline to not make it short/easy to type/easy to remember, change it every time a server is compromised, etc.... Or you could get all that for free with public keys. Yes a private key is like a very long password, but the important part is that it never leaves the client side and it's safe to use on every computer you want access to without the hassle of remembering one password per server. If you access many machines, how will you know when one is compromised? How will you prevent an attacker from logging in as you? Public keys really are the better way to handle user auth, less of a minefield for regular users.
    • samoa42 6y ago
      > Public keys really are the better way to handle user auth, less of a minefield for regular users. I'll go along with that, thou i consider a secret that resides in my brain vastly more secure than one residing on my disk.
• bayindirh 6y ago
  > Never let people SSH in with a password... Why not add libcrack (constraints) and auto-expiration of passwords instead of locking people out completely? Also adding fail2ban is a very effective solution to prevent brute forcing. > and for the love of god, stop leaving private SSH keys on servers Why not? Unencrypted private keys are dangerious, OK, but I fail to see the problem with a good password protected private key?
  • viraptor 6y ago
    > Why not add libcrack (constraints) If the user has a super secure password shared with a different, compromised service, libcrack will not detect that. > and auto-expiration of passwords Expiry results in passwords like: (prefix)Dec2020, (prefix)5, or cycling the last 2/3 entries. Keys can be relatively easily revoked and are guaranteed not guessable.
    • bayindirh 6y ago
      > If the user has a super secure password shared with a different, compromised service, libcrack will not detect that. There's a module[0] for that (TM). > Expiry results in passwords like: (prefix)Dec2020, (prefix)5 libcrack can enforce similarity and rotation checks too [1]. > or cycling the last 2/3 entries. There's also another module[2] just for that. > Keys can be relatively easily revoked and are guaranteed not guessable. You're right but, a good password policy and infrastructure is not a simple straw man which can be set alight with a simple match. PAM can be a bit hard to understand but, once understood, it's pretty easy to create complex rules and flows. If you get your workstation compromised somehow, you can always lose your keys. Then you need another password on top of your key to keep it encrypted. At the end of the day, a good security policy is required. Keys, passwords, fingerprints and other identifiers are just tools. If you can design your defenses and moats well, you can secure your system with any method you want. [0]: https://github.com/skx/pam_pwnd https://github.com/skx/pam_pwnd [1]: http://www.linux-pam.org/Linux-PAM-html/sag-pam_cracklib.html http://www.linux-pam.org/Linux-PAM-html/sag-pam_cracklib.htm... [2]: https://linux.die.net/man/8/pam_pwhistory https://linux.die.net/man/8/pam_pwhistory
• wrkronmiller 6y ago
  You say that having private keys on servers is bad, and you say that using SSH agent forwarding "is the devil." How, exactly, do you expect people to do things like use git or pivot from Server A to Server B over SSH?
  • px43 6y ago
    HTTP is a thing. Yeah, when pushing up files from a client to a server, or pulling down files, SSH makes sense, but for server to server, there's no need to use something with a full control channel for a simple file transfer. As to your question on how to use jump hosts, that's what -J is for. ssh -J ServerA ServerB
• deleted 6y ago
  [deleted]
• throwawaygulf 6y ago
  No SSH keys, passwords, etc. Use Kerberos baby, SSO in! SSH and Kerberos has been around for decades, but few companies have it implemented. It completely removes the need for SSH keys and their related management, user/group management, etc., which is a huge security and administration win.