34 ms·

If you’re not using SSH certificates you’re doing SSH wrong (2019)

• skies457 5y ago
  Anyone using GitHub as a public key repository? I found it very convenient to set up a cron job that pulls https://github.com/USERNAME.keys https://github.com/USERNAME.keys into authorized_keys and SSH from any client that has GitHub access.
• tomrod 5y ago
  Rant engaged. As a person who feels responsible for ensuring what I build is secure, the security space feels inscrutably defeating. Is there a dummies guide, MOOC, cert, or other instructional material to better get a handle on all these things? SSH keys make sense. But certificates? Is this OIDC, SAML, what? Is it unreasonable to request better and deeper "how to do {new security thing}" when PKI is a new acronym to someone? Where can I point my data science managers so they can understand the need and how to implement measures to have security on PII-laden dashboards? As so on.
  • jpgvm 5y ago
    I would say PKI (and especially the associated X509 standards) is by far the least understood (or most misunderstood) part of actually building secure stuff. It would be nice if there was a dummies guide but I'm not really aware of one. Doesn't help that most of "how to PKI" on the web amounts to a bunch of unexplained cryptic openssl CLI incantations.
    • dfox 5y ago
      It is combination of two things. X.509 is arguably overly complex ASN.1/X.500 thing, but that is not the main issue. Main issue is that most people do not even grasp the concept of a certificate (ie. binding of public key to some additional information that is signed by some other entity).
    • raxxorrax 5y ago
      Also it is a moving space. Browsers don't accept a single certificate for a site anymore, you also have to have that signed by a CA. You can create such a certificate yourself too, but as of today you will need at least two certificates for browsers to fully accept a TLS secured connection. It hasn't been that long since that rule is in place. So it isn't only the technicalities of asynchronous encryption, there is also specific behavior of applications that use certificates to prove identities.
    • brandonmenc 5y ago
      I recommend Security without Obscurity: A Guide to PKI Operations by W. Clay Epstein and Bulletproof TLS and PKI by Ivan Ristić. I started working in this space a year ago (I'm on a project deploying zero trust networking at a large company) and these books have been invaluable. https://www.amazon.com/gp/product/036765864X https://www.amazon.com/gp/product/036765864X https://www.feistyduck.com/books/bulletproof-tls-and-pki/ https://www.feistyduck.com/books/bulletproof-tls-and-pki/
  • blueflow 5y ago
    I can surely recommend reading into SSH certificates using the ssh-keygen manpage. No any extra tools required. I sign SSH certificates for all my keypairs on my client devices, principal is set to my unix username, expiry is some weeks or months. The servers have my CA set via TrustedUserCAKeys in sshd_config (see manpages). SSH into root is forbidden per default, i SSH into an account with my principal name and then sudo or doas. My gain in all of this: I have n clients and m servers. Instead of having to maintain all keys for all clients on all servers, i now only need to maintain the certificate on each client individually. If i loose or forget a client, its certificate runs out and becomes invalidated.
    • jas- 5y ago
      Now you have a centralized single point of failure. While the ease of use is inherently obvious with the implementation, if/when it does fail you will have to fall back to public key/password auth anyways.
      • blueflow 5y ago
        Which failure mode do you mean? The CA is accessible via offline means. I can walk to it and sign me a new keypair.
        • jon-wood 5y ago
          What happens when the building the CA is in burns down?
          • BenjiWiebe 5y ago
            Scan printed QR codes of your private key that you had backed up off-site.
            • tomrod 5y ago
              That's actually pretty brilliant.
  • michael_j_ward 5y ago
    I have the same feeling, and it motivated me to recently purchase this "Bulletproof TLS and PKI" [0] I haven't read it yet, so I'm posting i hope of someone else giving a quick review. https://www.feistyduck.com/books/bulletproof-tls-and-pki/ https://www.feistyduck.com/books/bulletproof-tls-and-pki/
  • enriquto 5y ago
    > SSH keys make sense. But certificates? I am equally mystified... Never understood how involving a possibly malicious third party can make communication more trustworthy. But then again, I was also sure when I first heard about it that public key cryptography was obviously impossible. You just could not have secret communication when everything is on the open! Is there any simple explanation that we ignorant people can read about certificates to get an "aha! insight" moment? For the case of public key cryptography, the moment where everything snapped together was when I read the mathematical description of the Diffie-Helman key exchange [0]. I'm not interested in how to do certificates with ssh, but on what problem do certificates solve, exactly. [0] https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exc...
    • dsr_ 5y ago
      A certificate is just a formatted list of attributes that has been signed by a particular private key. Username, UID, GID, membership in this, privilege for that, good-after date and good-until date, for instance. Everybody knows the public key associated with that private key, so you can verify that the private key did sign this list of attributes. An ssh keypair is an actual public/private keypair, but a certificate is just signed and encoded (but not encrypted) formatted data. If an ssh daemon has knowledge of a public key used to sign a cert, and has been instructed to trust that cert, and all the dates are good, then the ssh daemon can accept that cert as proof of identity and allow a login.
      • enriquto 5y ago
        I understand what you mean, thanks for the explanation. But why would you want to do that? What problem does it solve? Just that you can connect without having a private key yourself? This doesn't sound very safe.
        • tfigment 5y ago
          It solves partly managing authorized_keys files. If you have a team separate keys can be difficult to manage. Shared keys are even worse. Certs can help with this if you properly manage the cert signing server (like hashicorp vault). All of that is currently free and open source. Also can now have short expiry times if desired.
  • capn_duck 5y ago
    Practical Cryptography by Bruce Schneier and Niels Ferguson is decent in that it gives a good lay of the land without diving too deep in to the mathematical rigor. The first half explains at a high level the concepts of encryption, key exchange, asymmetric encryption, digital signatures, and lays out the problem statement that PKI solves. It's nice in that it will list out a bunch of available encryption algorithms or hash algorithms, but at the end of the chapter say "Just use this one, it's considered safe right now." i.e. AES256 and SHA256. Unfortunately, it mostly avoids the practical steps of web security, like its not going to print out the command to type in to your shell to generate an SSL signing certificate. So I wouldn't recommend it if you're looking for an immediately practical book to help you secure your web server. But it orients you to the landscape so you have a general idea of what you're trying to achieve, and can google yourself the rest of the way there.
    • tomrod 5y ago
      I feel this is the exact right thing for me right now -- people trusted in industry. I can follow tutorials and documentation. The part where a concept is explained is often missing and can be guessed at (albeit often wrongly). I'll look into this and perhaps supplement with some good tutorials for my developers and data scientists. I appreciate your input!
    • vngzs 5y ago
      If they're willing to read a book on security design, I would recommend Security Engineering, 3rd Edition [0]. It includes a broad survey of what matters in the security space (rather than just cryptography), and generally in sufficient depth to understand how we may build secure platforms in the face of adversity. Also, many of the chapters are available to read for free - read author's text under the cover photo. [0]: https://www.cl.cam.ac.uk/~rja14/book.html https://www.cl.cam.ac.uk/~rja14/book.html
    • tptacek 5y ago
      I don't think Practical Cryptography is going to give you much of an intuition about why this article is advocating for certificates.
  • tener 5y ago
    I feel for you. Security is a complex, evolving topic, with a dizzying array of concepts. At work, we develop Teleport (https://goteleport.com/ https://goteleport.com/) to provide a secure access solution that is also easy to use and hard to get wrong. (Note: you cannot truly have "hard to use" and "secure" access, because people will always develop "backdoors" that are easier to use but not secure.) If you are interested in some accessible writing about security check out: https://goteleport.com/blog/ https://goteleport.com/blog/ On SAML: https://goteleport.com/blog/how-saml-authentication-works/ https://goteleport.com/blog/how-saml-authentication-works/ On OIDC: https://goteleport.com/blog/how-oidc-authentication-works/ https://goteleport.com/blog/how-oidc-authentication-works/ I can recommend the YouTube channel too: https://www.youtube.com/channel/UCmtTJaeEKYxCjfNGiijOyJw https://www.youtube.com/channel/UCmtTJaeEKYxCjfNGiijOyJw
    • LambdaComplex 5y ago
      Teleport seems like a genuinely cool product. With that said, the company really needs to improve its interview process--my experience was downright terrible, and Glassdoor shows that other people had a similar experience
      • GeorgeHahn 5y ago
        As a current candidate, I'd be interested in hearing more about your interview experience.
      • sparc24 5y ago
        Their pricing is bat shit crazy. Stay far, far away.
        • sofixa 5y ago
          It's a security product that could be a huge productivity gainer. All competitors i can think of are also expensive.
          • michaelt 5y ago
  • diarized 5y ago
    Scalable and secure access with SSH @FB https://news.ycombinator.com/item?id=12482212 https://news.ycombinator.com/item?id=12482212
  • hitpointdrew 5y ago
    Check out teleport. It abstracts away the certificate bit and manages it for you. You run 'tsh login' once and you get a cert good for 12 hours (then you can get access to all the teleport resources you are allowed to, weather that is ssh server access, db access, kubernets access, etc.) I am evaluating the product now and am quite impressed. https://goteleport.com/ https://goteleport.com/
  • throwaway984393 5y ago
    It's not unreasonable, but we need some kind of universal knowledge base for tech stuff. Security is just one of many inscrutable topics in tech where you need weeks of research to understand the best practices.
  • chefandy 5y ago
    My needs may be entirely different than yours and I don't want to downplay the importance of security, but... Security writing in "engagement" obsessed media yields lots of people screaming "FIRE!" whenever seeing something even theoretically flammable, and bandwagoneers— already imagining their hair is on fire— lambasting everyone not immediately evacuating for being careless about fire safety. It reminds me of politicians being 'tough on crime'— they reflexively jump at opportunities to tighten the screws regardless of its necessity or efficacy. It's an emotional response involving self-image, peer pressure, and fashion rather than rational cost benefit analysis. Perfect is the enemy of good. Attacking every theoretical threat like an international bank's network admin yields no practical benefit for most. Not nobody but most. If this TLA is new to me, there will be another new one that people will lambast me for not knowing in a couple of years, max. For me, this problem was a better fit for the Wizard of Oz than a security education resource— what I really needed was the right frame of mind rather than learning the implementation details of every incremental certificate authority update. I evaluate my attack surfaces and reduce them if I can, evaluate the real importance of keeping what I'm protecting secret, implement standard precautions and architecture to mitigate those risks, pay attention to the systems, pay attention to new vulnerabilities, and re-evaluate upon changes. The process is technology-agnostic and only requires you deep dive into the stuff you need to know without feeling like you need a new certification ever 6 months to run your company's CalDAV server.
    • scottLobster 5y ago
      Relevant article: How I learned to stop worrying (mostly) and love my threat model https://arstechnica.com/information-technology/2017/07/how-i-learned-to-stop-worrying-mostly-and-love-my-threat-model/ https://arstechnica.com/information-technology/2017/07/how-i...
    • TedDoesntTalk 5y ago
      > evaluate the real importance of keeping what I'm protecting secret Excellent. This is often ignored by the security obsessed, those people yelling FIRE! as you say. Securing access to my cloud-hosted cat photos does not demand the same energy as securing ICBM launch codes.
    • 5y ago
  • pphysch 5y ago
    I spent an afternoon implementing a SSH cert service in Go using the standard "x/crypto/ssh" package, with little to no prior knowledge of SSH internals. SaaS like Smallstep and Teleport are trying to middleman and monetize what is actually a simple process that more developers should be comfortable implementing themselves. This isn't "rolling your own crypto", this is standard SSH key stuff plus a bit more nuance and LOC to make things more secure. When you pay for those services, you are essentially paying for a wrapped SSH command + dead-simple web app + someone to be your CA (read: store the resulting files of `ssh-keygen`, hopefully securely). And all the potential headaches of relying on yet another SaaS. Plenty of developers are comfortable writing a script, a simple web app, and securely storing a file on the webserver. This is all that is required to build SSH cert support into your internal apps/tools, plus an afternoon understanding how CAs work (in short, CA private key can sign any SSH public key, then that SSH public key can be validated by anyone holding the CA public key, no TOFU required).
  • Aeolun 5y ago
    This blog post seemed eminently understandable to me, at least as someone aware of public key, but not certificate based authentication.
  • ozim 5y ago
    What is the scale you are operating on? If you are having 10-50 servers and 5-10 people working on those - SSH keys are definitely good enough, it might be a bit of hassle to manage keys but quite OK. If you go into large corporation area with more than 100 servers and more than 50 tech people that need to login to those servers you probably would already found out that there are other options and you probably have to run your internal CA (certificate authority). If your org grows you would probably have CTO and other technical people who will have experience knowledge to implement things differently.
• el_duderino 5y ago
  Previous discussion from 2019: https://news.ycombinator.com/item?id=20955465 https://news.ycombinator.com/item?id=20955465
• andix 5y ago
  As long as it is not as easy as let’s encrypt, it won’t take off.
  • inetknght 5y ago
    I toyed with SSH certificates a few years ago. They seemed cool and secure but, ultimately, the x509 stuff was quite (!) arcane. And trying to get the IT team on board would have been a nightmare. I quite agree: as long as it's not as easy as Let's Encrypt then it won't take off.
    • blueflow 5y ago
      man ssh-keygen lists me this: > Note that OpenSSH certificates are a different, and much simpler, format to the X.509 certificates used in ssl(8). Where do you work with x.509 certificates when doing an SSH ca? I use SSH certificates productively and only ever used ssh-keygen commands.
      • inetknght 5y ago
        Like I said, it's been a few years so maybe things have changed since then. But if I recall... x509 supports all of the things that ssh key file format does ... and also a lot more. ssh supports x.509 too so that makes it "easier". When you use `ssh` to connect, you'd specify -I and point to the private key and it will automatically try to find a certificate file whose name is identical to the identity file but with "-cert.pub" appended (see `man ssh_config`). There's another option to explicitly specify the key certificate file `CertificateFile` but there's no short-argument version so you have to use `-o CertificateFile [filename]` or add that to your `~/ssh/.config` file. You'd need to use `openssl` command (or, of course, any openssl-like command line) to sign the your SSH key. And, of course, openssl doesn't understand ssh key files so you have to use `ssh-keygen` to convert the key to x509 format or else generate the key using `openssl` (but again, at least ssh understands x509 natively so the downside is having the much longer x509 text). And that's quite the arcane part: openssl cli is fucking awful. It doesn't follow normal command line conventions, doesn't have tab autocompletion, and its documentation is obscure/difficult to find, extremely terse, and difficult to even understand if you're not already explicitly familiar with exactly your inputs and outputs. And then there's the whole process of getting your key file signed. At least that process is (in general) identical to having a web SSL key signed -- because the private key is actually identical but the only nominal difference is the format of the file that you normally think of using for it. But the workflow is different because the certificate doesn't get installed to somewhere that a webserver would want. I had ended up creating my own Certificate Authority to test with and that was yet another rabbit hole of anger management.
• cj 5y ago
  I'm tempted to write a competing article: "If you're using SSH in 2022, you're doing it wrong" There's no need to open port 22 if tools like AWS Session Manager (and GCP's equivalent) are available to you.
  • core-utility 5y ago
    Don't forget about the no-ops "If you're opening a shell on any server, you're doing it wrong (2022)" method.
    • dtgriscom 5y ago
      What's next? "If you're using a computer, you're doing it wrong"?
      • kafkaIncarnate 5y ago
        "If you have data, code, or processor execution, you're doing it wrong."
        • jandrese 5y ago
          That's really not that far off from what some people think. "You should never touch your own data, that is what the cloud is for."
      • geodel 5y ago
        Now this is where I want to go! I mean using technology in 2022 feels so outdated. Don't we have cloud to do everything for us.
      • deleted 5y ago
        [deleted]
  • GekkePrutser 5y ago
    But even if you do it through that, SSH is a much nicer protocol than typing on a remote console. You get file transfer, X, agent and port forwarding, terminal window scaling and much lower bandwidth. Also, not all servers are on cloud platforms.
• client4 5y ago
  Keybase had an elegant solution I use https://keybase.io/blog/keybase-ssh-ca https://keybase.io/blog/keybase-ssh-ca
  • bloopernova 5y ago
    I used to like Keybase so much, it felt like a Next Big Thing. I just wish they had stuck to identity management and validation, providing SSO etc. Instead they tried to be a chat client, git host, and crypto wallet too. They spread themselves too thinly trying to compete with dozens of rivals for each function they added. I wish they'd have been a standard that Microsoft, Apple, Google etc provided implementations of.
• emrvb 5y ago
  I would love this to work, as it indeed fixes several issues addressed in the article. However, I don't think openssh-server supports OCSP natively, so while you might be doing SSH right, you're doing certificates wrong.
  • egberts1 5y ago
    OCSP natively? No. Does the current OpenSSL have its own KRL?
• sjaak 5y ago
  I'm not doing anything wrong. My sshd is behind spiped + logging in requires me to physically tap my yubikey.
• GekkePrutser 5y ago
  SSH certificates make sense. But can you use hardware backed ones like the OpenPGP applet on yubikey with this? I currently use this method to store my SSH keys safely. But I don't know how this would work with certificates. If I have to store them in the computer instead of a hardware token it's a huge step back in security. By the way what do home users use to set up a PKI? Scripting everything with OpenSSL is but very nice. It would be cool if there were an open source PKI platform ideally even with IDP built in. With a nice web interface and easy to install with docker. Never found one though.
  • blueflow 5y ago
    Yes, ssh-keygen allows you to use private keys from any PKCS#11 backend using the -D option. This includes smartcards and tokens. Including for the CA key.
    • GekkePrutser 5y ago
      Ah Yes I used this method before with PIV cards and OpenSC/OpenCT. The toolchain is a real PITA though. Unstable, difficult to provision. Proprietary tools for card management. Not all platforms support PKCS modules. As far as I remember openssh on macOS was compiled with support for it. So I had to replace it with one from brew which is much harder these days. Mind you we're talking 5-6 years ago. OpenPGP is really user-friendly. Nice config menu with gpg --card-edit . SSH agent functionality built into the gpg agent. I kinda want to retain this level of comfort to be honest.
      • RL_Quine 5y ago
        Why use gpg at all? SSH supports FIDO.
        • dfshsdfjsfj 5y ago
          FIDO is still of extremely limited availability. I'm still running into hosts I need to access that can only use RSA/DSA keys, as opposed to the ed25519 key on my Yubikey, nevermind FIDO.
• Cpoll 5y ago
  I wish revocation was covered as well. The article mentions this issue in SSH: > Keys are trusted permanently, so mistakes are fail-open. But you can make the same mistake using certificates, by issuing a certificate with a large expiration date. AFAIR you _can_ revoke valid certs, but that involves making changes to every box running ssh, much like when revoking a public key.
  • blueflow 5y ago
    You can distribute a key revocation list along with your regular configuration management. The key revocation list can be generated and maintained via ssh-keygen. I used to have a central location with an revocation list. All servers had a cronjob fetching it.
    • camtarn 5y ago
      And that's pretty much the exact same infrastructure you'd need for distributing authorized_keys. Instant revocation seems to be a giant hole in this article's argument which isn't addressed at all. If you fire somebody partway through the work day, end-of-day cert expiry is not good enough to prevent compromises.
      • blueflow 5y ago
        Active reconfiguration doesn't work well if your machines aren't unconditionally reachable.
        • camtarn 5y ago
          Hm, that is true.
        • deleted 5y ago
          [deleted]
• temp8964 5y ago
  There are cases where if you leave SSH enabled then you are doing it wrong. If you only need SSH to do a few things once a while, you should just turn it off, and only turn it on when needed. In these situations, I feel it’s OK to just use password to login.
  • Enginerrrd 5y ago
    Honestly, I agree. My ssh passwords aren't going to be brute-forced anytime this century. It's also pretty easy to put a fake sshd on port 22 and set the real one to some other port (preferably one low enough to still require root privileges though). I don't have encrypted drives on all my devices. I don't want to have to worry about what could happen if one of those gets lost/stolen. I'd rather not leave keys or certificates lying around. Also, things sometimes go wrong and I need to get access to a server from a device I've never been on. It's nice to be able to do that. Passwords do that. To be fair, I usually have a single VPS which I keep as locked down as possible that has VPN access to the server I really need. The VPS doesn't even need to be running most of the time. So I can spin it up to get access to the VPN, then ssh into the server with a password. If the VPS gets compromised, the VPN alone won't give an attacker immediate access to the server like it would if I left keys / certificates on there. I have to trust the VPS, and if it gets compromised without me noticing, and I then log in to my server, yeah, I'm SOL, but certificates don't solve that problem.
  • remram 5y ago
    How do I turn it on if I can't SSH into the machine? In most cases, SSH is what you use to do management tasks.
    • temp8964 5y ago
      Many hosting services have a control panel to do this on VPS. Some hardwares like Synology also have web interface to do this.
• withinboredom 5y ago
  > brew install step The audacity of mac users who think everyone uses a mac.
  • deleted 5y ago
    [deleted]
  • deleted 5y ago
    [deleted]
  • dljsjr 5y ago
    Brew has been available on Linux for a long time and works very very well.
    • withinboredom 5y ago
      There are other OSes than Linux and MacOS, in fact, one of those other OSes is far more popular than both of those put together: Windows. It has built-in openSSH support since 2018.
      • tomrod 5y ago
        I'd argue windows isn't terribly popular, in that popular means "people like it more than not", but rather is used often, if grudgingly, by folks who have experienced alternatives or are unaware objectively better options exist.
        • withinboredom 5y ago
          I use Linux (baremetal on a System76 machine, and WSL) and Windows daily. I can’t stand OSX. As in literally want to trash it and the device it’s installed on within 10m. It’s a beautiful OS, but as a windows manager, it’s literally unusable; at least with a QWERTY keyboard. Like what genius put cmd+q right beside cmd+a, with cmd+q not even prompting the user? I could rant for days… so I’m just going to stop.
          • 5y ago
• xrd 5y ago
  This article was very illuminating. And, I wish it was written like this: To really secure your SSH server, do these three things: 1. Setup a trusted authority 2. Use ssh certificates 3. With ssh certs, you can easily add MFA for logins expire until you reauth. Now that we've established this, here are the gory details. Lorem ipsum, lorem ipsum, lorem ipsum. It's a great narrative, but I wish I knew the big payout in advance.
  • michael_j_ward 5y ago
    Is that what I get out of the box using tailscale for ssh? https://tailscale.com/kb/1009/protect-ssh-servers/ https://tailscale.com/kb/1009/protect-ssh-servers/
    • tener 5y ago
      Tailscale (and other similar solutions) works on the network level. This is not a bad idea in itself, but SSH certs operate on the application level. The fact you can ping the server shouldn't mean you are allowed to actually access it.
    • tptacek 5y ago
      Two examples of things Tailscale doesn't give you for this usage model that SSH CAs can: * Transcript-level audit trails for what people are actually doing on SSH sessions. * Differential access to different groups of users to the same machines. Tailscale and SSH CAs work together nicely: require membership in the right Tailscale group to talk to SSH at all, thus tying access to SSH to your (e.g.) Google login and MFA requirement, and use something like Teleport for the actual SSH login, to get the audit log, group access, and an additional authentication factor.
  • AtlasBarfed 5y ago
    MFA for ssh means you can't automate cluster-level ops. Unless, well, you automate the MFA, which defeats the MFA. This drives me a bit nuts about security people in the age of cloudscale. They assume you don't mind MFA'ing every hour and are manually doing logins and accesses for everything. Yeah, uh, I need to script orchestration on several hundred machines at once, and orchestrate/access on the scale of hours or even days for some things like "Big Data" backups or restores. If certificates are anything like SSL certs and the horrorshow cli tools / options / management involved in those, no thanks. I'd rather have an automated sshkey switchover, or for stateless just routinely cycle the infrastructure with new keys. It's been a long time tenet of security that you want an open algorithm that gets broadly and publicly challenged so you know its secure. Well, in the age of the state actors, this might not be the whole truth. I think layering some klugy not-invented-here obfuscation atop the more battletested methods is a useful and important deterrent/delay. Sure someone will figure it out, but they have to TRY HARD. A lot of the institutional attacks seem to be based on human attacks on standardized systems, which HAVE to allow human access and vectors. So in AWS land, secrets manager is secure unless you get the permissions. Then you have everything. But if each of those secrets has some whacko obfuscation for the various apps, then that is a big slowdown to the human attack vectors. And the state actors? Well, even they have budgets. They'll probably move on to easier targets. If a state actor is motivated at targeting your company in particular, well, given that they'll have malware in the firmware of your hard drives and motherboards and the like, you're probably helpless. Finally, what really bothers me about most security is that it leaves one of the most important "canaries in the coal mines" aspects of security: honeypots. Sure do the diligence on securing the access, but how about some turnkey approaches for setting up honeypots to detect when people are poking around? Honeypots are perfect for that, because the devs only care about the stuff they are working on. The intruders are doing the scanning.
• FriedrichN 5y ago
  Stuff like this is really cool. But the problem is that certain clients (as in clients that pay your bills) can't even get public keys to work and we end up allowing password logins. So I don't know how I could make this work in the real world. That's where security ends, when 'it just has to work' because 'they're the ones paying/in charge'.
• brightball 5y ago
  Isn’t this the process that Teleport streamlines?
  • pzduniak 5y ago
    Teleport completely streamlined all sorts of access management in my projects. Every new feature they release (Kubernetes, Database, App access) work as advertised and the Helm chart + Terraform plugin (which for some reason is not published in the marketplace??) are great for automating the whole deployment + configuration. Great piece of software.
• 1970-01-01 5y ago
  Meh, you're not wrong for skipping SSH certs. They're mature security, but not mature enough for everyone. And like everything else, they break, predictably and unpredictably. If you're not ready for someone to emergency access their way into prod to fix a broken SSH issue on Christmas morning, you're not ready for SSH certs. Maintenance will get you, one way or another..
  • sergiosgc 5y ago
    The SSO flow is way too complex for something that must work on an emergency.
  • teknopaul 5y ago
    Is there something wrong with installing client public keys in the server and preventing password based logins? Seems more secure than handing over the security of your servers to a CA? Managing the authenticated_keys file is trivial and I like simple file based solutions. I find simpler is often more secure because its easier to understand. I have had plenty of ssh servers on the Internet even, (on non-22 ports to prevent logs filling) and not had a problem yet AFAIK. I have also been on call when certs expired gawd knows how many times.
    • aidenn0 5y ago
      I'm not sure I buy it, but, TFA tries to explain: Situation: A person's machine dies and takes the SSH private key with it No Certs: They now need to get IT to distribute the public keys to a set of hosts, where the full list is possibly not known by any one person, so for the next week it will be "oh shit, I forgot to ask IT to put the pub key on server-12, so I'll open a ticket and not get any work done for the next few hours" With Certs: They get IT to sign the new key.
      • politician 5y ago
        If the IT team is treating servers like pets, then this is a problem. If they aren't amateurs, then it's not a problem to update the script and push the configuration out to all of the servers.
• LinAGKar 5y ago
  Too bad you can't do that with dropbear
  • ayushnix 5y ago
    Which is why I installed openssh-server on my OpenWrt hosts. However, due to a bug [0] in openssh-server package in the latest 21.02.2 release of OpenWrt, OpenSSH doesn't allow you to login in failsafe mode on an OpenWrt host. Because my OpenWrt host lacked a recovery mode, it was essentially soft bricked. I was able to recover it using the serial port but even after all this, the comfort of using SSH certificates on all of my nodes was enough to keep making me use it instead of Dropbear. [0]: https://github.com/openwrt/packages/issues/17833 https://github.com/openwrt/packages/issues/17833
• cestith 5y ago
  The article does a pretty good job explaining advantages of certificates. It overlooks the existence of solutions to some of the individual problems it mentions with keys, though. Tools like sssd exist, with which a way for the end user to keep their public key updated in a directory takes care of key distribution and at the same time limits who can use sudo, all without changing any files per-user on the server.
• IgorPartola 5y ago
  If this is true then why does ssh not get set up this way by default? Honestly what I would prefer is a better (and faster) version of monkeysphere [1]. That was honestly the most natural-feeling solution to SSH security. (1) https://www.systutorials.com/docs/linux/man/1-monkeysphere/ https://www.systutorials.com/docs/linux/man/1-monkeysphere/
  • dsr_ 5y ago
    Because it's not suitable for everyone in all circumstances.
    • IgorPartola 5y ago
      So if I am not using certificates them I am not doing it wrong? :)
• rantanplan 5y ago
  Yes, SSH certificates are the way to go and pretty easy to set up. But what these articles fail to address is the user management aspect. For the SSH certificate to be accepted, the unix user must first be present on the system. As far as I can understand, FreeIPA(or similar LDAP systems) cannot be used in conjunction with SSH certs. Whereas SSH keys are supported by these systems. Can anyone provide any insight/experience with this?
  • blueflow 5y ago
    Its not the username that needs to match, its the principal. You can allow any principal for the root user, for example. You can define principals when allowing a CA via authorized_keys, or you can configure allowed principals globally using sshd_config directives like AuthorizedPrincipals* .
  • dsr_ 5y ago
    In most circumstances, you want these two things (user is authorized on the system, user can be identified and authenticated) to be different. Having a process that creates the user on system in order to authorize them to login is pretty similar to all your other configuration management tasks.
  • ehnto 5y ago
    I imagine it's a matter of automating the certificate insertion on the target servers when it's updated on the user's account in the LDAP server. In other words, it depends entirely on your systems and how far your administration is willing to go to automate it.
  • mbreese 5y ago
    Many years ago, I did all of this with an LDAP system. Public keys were generated by the user and entered into LDAP (or you could auto-generate keys, etc). Users were authenticated with their ssh key (stored in ldap, password based access was restricted). Authorization for access to each host was also in LDAP, as was sudoer status (as a group setting). It was actually quite an elegant setup. You would still need to setup a CA for generating local certificates for TLS connections to LDAPS, but the auth was handled all in the LDAP server. I think the main downside would be trying to have the authentication overhead on a single server (the ldap server) when you are dealing with many hosts. Over a handful of systems, it’s great. But it doesn’t scale when you’re taking thousands of hosts (or cloud vms that spin up/down).
• jimmaswell 5y ago
  I still don't care about any of this nonsense for my personal stuff when I can avoid it. Passwords all day for me. 0 security incidents in my lifetime. Sucks that Github and some other things force SSH keys which are just passwords except always saved to your disk so that anyone who steals your laptop gets access. It adds insult to injury when you try to capitulate to this malarkey, generate a key in PuTTy's key generator, then Github whines that the default setting isn't overkill enough and you have to make a whole NEW key with some other setting. I miss the good old days.
  • krnlpnc 5y ago
    > Sucks that Github and some other things force SSH keys which are just passwords except always saved to your disk so that anyone who steals your laptop gets access. This is the reason to encrypt ssh private keys with a passphrase. If the key is leaked it's still protected by the password. It's a built-in feature of ssh. For an existing key downloaded from a cloud provider, use ssh-keygen -p to add/change the passphrase.
    • gizzlon 5y ago
      How hard is it to crack these passwords? Since it's local (unlike the github password) I guess you can run brute force attacks etc at full speed ?
      • confident_inept 5y ago
        That's going to depend on the length of your password. Longer is more entropy and orders of magnitude more difficult to 'brute force' with each character added.
      • wombatpm 5y ago
        Pass phrase not password. You are going for length to protect from brute force. Soylent Green is NOT people Was one of my shorter pass phrases
        • 5y ago
• krnlpnc 5y ago
  It depends on the scale. If a company has a handfull of hosts I'd argue that deploying the full AAA and PKI systems to back cert auth is doing it wrong. Traditional ssh-key auth is simple and reliable, it's not until you have a large, complex and diverse user base that you need something more. That's why the huge fang sites use it. Every org doesn't need to mimic fang.
  • fvold 5y ago
    Exactly! I don't understand this obsession with enterprise-level security on home networks and hobby projects. If you think it's fun and educational to set up, then you're doing it for fun and education, not security. If you're doing it for security, you're basically setting up anti aircraft guns to do what a drone jammer could do with way less resources spent.
    • hedora 5y ago
      Anti-aircraft guns can't actually take out most drones. Good analogy.
  • ayushnix 5y ago
    I'm using SSH certificates to manage a few nodes in my homelab and it's a pleasure to not have to deal with managing the known_hosts file on my clients and authorized_keys file on my servers. There's only 1 line in my known_hosts for my nodes and authorized_keys doesn't even exist on any of my servers. If I add a new node to my homelab, I don't have to make any changes in known_hosts or authorized_keys in the existing nodes and it's easy to bootstrap the same known_hosts and sshd_config that I use everywhere in the new node. SSH keys would make managing these few nodes a lot more complex that it is.
  • nostoc 5y ago
    True, and while the title is somewhate clickbaity, I think your point was pretty clear in the article.
  • aseipp 5y ago
    You really don't need to be anywhere close to mega-scale to benefit from SSH certificates and integrated authentication flows, though. Even at the scale of "only" 10 people with SSH access, the whole system can be massively simplified and made more secure by integrating centralized logins, and SSH certificates are rather perfect for this. I implemented my own SSH certificate authority myself more or less, and while it's overkill for my own homelab-level stuff, I absolutely would never use anything else once I have more than like, 5 people logging into some set of machines. The benefits of centralized SSH access control that you can freely integrate (and pretty easily too, thanks to OpenSSH!) with your existing identity provider is really nice.
• tacostakohashi 5y ago
  This is definitely true... and a lot of people are doing it wrong. This is one of those things that drives me nuts as an experienced/old developer, seeing people type passwords for ssh/git/whatever several times per day. Sometimes there are tasks that require copying / checking some file on N servers, and these people seem to think that cannot be done in a shell script because the password needs to be entered interactively. Then there's ssh port forwarding, X11 forwarding, etc... but its amazing how many people use ssh for years without so much as glancing at the man page.
  • Symbiote 5y ago
    It is amazing how many people use any CLI tools for years without reading the man page. The man page for the shell (man bash; man zsh) is a good place to start.
    • tacostakohashi 5y ago
      Yes that too... "the kids of today" seem to regard basic shell tools and scripting as a dark art rather than an everyday part of using a computer and doing development productively. It's kind of sad.
      • klabb3 5y ago
        I can't speak for others but personally I've never built up enough motivation to learn shell scripts (and related hackery like awk and sed) properly, even though I've learnt maybe 5-10 programming languages quite well and use the shell interactively all the time. I can't explain with certainty why, but I think it's due to lack of discoverability, inconsistent conventions for flags and positionals, esoteric syntax for simple control flow, lack of errors/feedback for things like undefined variables, no scoping/namespaces, unclear type system (not asking for much, strings, bools and ints would suffice). That said, piping/streaming is amazing and often better than in modern languages. In short, it's quite different from other imperative languages - the design feels arbitrary and the learnings non-transferable, even though I know it is useful and ubiquitous.
      • 5y ago
• mnd999 5y ago
  Aside from being a pain to set up, what’s wrong with using GSSAPI / Kerberos? (within an org)
  • en4bz 5y ago
    Kids theses days hate using technology that's older than themselves? Kerberos is amazing and it make me sad to see all these people reinventing stuff that was solved 30 years ago. The number of companies selling SSO and doing it poorly (see this weeks okta hack) is unfortunate.
    • risson 5y ago
      21yo here, I think Kerberos is bloody awesome, but then I was introduced to it by a somewhat old timer, who showed me its benefits when properly integrated in the company.
  • zengargoyle 5y ago
    Yeah, my org had a Kerberos setup for some DB/middleware/CLI tools. I inherited a bunch of random script tools that took the whole typing in passwords for everything. Screw that, first thing I did was write a Kerberos module and set up a Kerberos keystore. Presto, no more typing passwords for everything. Typically it ends up boiling down to whether or not the backend thing you're talking to supports Kerberos, many don't and only have the whole SSL thing. A well setup Kerberos was much nicer to work with than chained SSL certs.
  • YATA0 5y ago
    This typically still involves typing in your domain username and password, no?
  • cduzz 5y ago
    I've long ago made up a corollary to Greenspun's tenth rule; any sufficiently complex or mature access regime will re-implement half of kerberos, poorly.
• tomxor 5y ago
  > What you’re supposed to do is verify the key fingerprint out-of-band by asking an administrator or consulting a database or something. But no one does that. Actually they do where I work, pretty much every time, and I didn't ask them to. Eyebrows will raise even higher if I forget to notify everyone I replaced a server at a domain causing a new signature (resulting in the scary "possible MITM attack" message). This is a good thing, but I should probably make it more efficient by publishing the fingerprints. Although the article does point out this specific disadvantage of domain reuse with known_hosts. I can see why this solution could make things easier at larger scales.
  • toast0 5y ago
    > I should probably make it more efficient by publishing the fingerprints. When I last ran a fleet of servers, I published the known hosts files via git, and strongly suggested using that in new user documentation (you needed to setup ssh_config for our jumphost/bastion anyway, may as well link to the known host keys). There's a tool to generate the files that comes with openssh, iirc.
• michaelmior 5y ago
  What seems to be missing from this is how I assign permissions to individual hosts. When I'm using public keys, I do so by only adding the user's public key to the hosts I want them to access. It seems the way that certificates were presented that adding a user implicitly gives them access to all hosts using the same CA. I'm sure there's a solution to this problem, but does anyone have any pointers? For example, I want hostA and hostB to use the same CA. But some users should only have access to hostA but others should only have access to hostB. Others may have access to both.
  • gouggoug 5y ago
    Simply don’t create a user account for these users on the hosts they shouldn’t access.
  • blueflow 5y ago
    Set the principal name in the Certificates to the name of the users team. On the server side, set the AuthorizedPrincipals* for root to the list of allowed teams.
  • tener 5y ago
    For scalable, centrally managed solution see: https://goteleport.com/docs/access-controls/reference/#rbac-for-hosts https://goteleport.com/docs/access-controls/reference/#rbac-... Disclaimer: day work.
  • tuananh 5y ago
    it's covered in this post https://engineering.fb.com/2016/09/12/security/scalable-and-secure-access-with-ssh/ https://engineering.fb.com/2016/09/12/security/scalable-and-...
    • michaelmior 5y ago
      Thanks! This seems like a pretty simple approach to implement but I'd also imagine it would scale reasonably well after automating various pieces.
• gotaquestion 5y ago
  Cool, how do I set up a CA?
  • 0xdeadb00f 5y ago
    Precisely this. From what I've read it isn't that easy to setup a CA. Look into step-ca though, I've heard it's.. Okay? I don't know. It seems too complicated still - I'd rather stick with pubkey auth
  • tfigment 5y ago
    Setup Hashicorp Vault. Almost easy but actyally hard to do right. Policies are easy to make too open and possibly insecure.
  • aidenn0 5y ago
    All you need is an ssh key, which you can generate like this: ssh-keygen -f ca.key Then you can generate certificates like this: # user key ssh-keygen -s ca.key -I key_id /path/to/user_key.pub # host key ssh-keygen -s ca.key -I key_id -h /path/to/host_key.pub Secure ca.key according to whatever level of paranoia you desire. e.g. Passphrase, hardware security module (PKCS#12 is supported for generating certs), airgap the machine. anyone who gets access to ca.key has access to everything that trusts ca.key
• 0xdeadb00f 5y ago
  > Users are exposed to key material and encouraged to reuse keys across devices. Keys are trusted permanently, so mistakes are fail-open. What? This just sounds like you're doing it all wrong then blaming the tools. Maybe I'm just thinking about it from my POV as a mainly hobbyist user of SSH, but I rotate my keys (not as frequently as I should, but I do), and I remove old ones from .authorized_keys files and I use different keypairs for different servers sometimes too. I never copy keys to other devices - I ssh-keygen on every device, and add my pub key to the authorized_keys file manually. It isn't even "hard" to do it this way. Sure, it doesn't "scale" for big corps - but I don't need it to scale, so I'm not "doing SSH wrong" by not using certificates.
  • metalliqaz 5y ago
    It's more effort than I would like. I should not be bothered with updating hidden config files containing data that is mostly not human readable. I want to prove my identity once and let the system take care of the rest.
    • 0xdeadb00f 5y ago
      Well that's fair enough, but I take issue more with the title of the post telling me I do "ssh wrong", because I can't be bothered to setup a CA and fuck around with certificates. To me, setting up a CA is more effort than I would like.
      • blueflow 5y ago
        It becomes feasible when you have a larger number of key pairs that are supposed to have access to the same set of machines. I did it as a private person because I'm an SSH nomad, using several clients with different key pairs each. I agree with you, for a regular user with a single client device (or two) its not worth it.
      • throwaway984393 5y ago
        It's very much a use-case and risk driven decision. A company should be using Teleport, which is a lot more than just certificates (but they do use certs). For your personal VPS or GitHub account, nobody is going to go out of their way to get your SSH keys. The biggest "you're doing it wrong" I see is people who disable host key verification because their servers' IPs change constantly. Do you want MITM?! Because this is how you get MITM! Might as well use Telnet for connections.
• charles_f 5y ago
  > you’re doing SSH wrong I understand the theoretical superiority to keys, but do we have some data per practically how many times key security actually failed someone?
  • haarts 5y ago
    I would very much like to read about that too. Setting some sane security parameters for your SSH setup looks like a less jarring/drastic approach into securing SSH further[1]: - Use keys. - Allowing only strong cyphers. - Remove weak primes. [1]: https://disknotifier.com/blog/simple-ssh-security/ https://disknotifier.com/blog/simple-ssh-security/
• JonChesterfield 5y ago
  The 'ideal ssh flow' involves a program that I think the author has written and a website login. Do these certificates require an existing system running single sign on or similar to hand out access to other machines, in single point of failure fashion?
• soraminazuki 5y ago
  I feel that trying to make SSH keys short-lived is becoming more painful each year because there's an increase of tools that use SSH keys for purposes other than SSH logins. For example, age [1] encrypts files with SSH keys, agenix [2] does secrets management with it, Git can now sign commits with it [3], and even ssh-keygen can now sign arbitrary data [4]. All of these become useless the moment you start using short-lived keys. [1]: https://github.com/FiloSottile/age https://github.com/FiloSottile/age [2]: https://github.com/ryantm/agenix https://github.com/ryantm/agenix [3]: https://calebhearth.com/sign-git-with-ssh https://calebhearth.com/sign-git-with-ssh [4]: https://www.man7.org/linux/man-pages/man1/ssh-keygen.1.html https://www.man7.org/linux/man-pages/man1/ssh-keygen.1.html
  • imwillofficial 5y ago
    Different strokes for different folks. Different keys for uhh, different complex application use cases.
  • ayushnix 5y ago
    Umm, please correct me if I'm wrong but I think you're confusing SSH keys with SSH certificates. A SSH client key can be reused to create short lived SSH client certificates. You can keep using that SSH client key to encrypt data, sign data, login to GitHub etc. There's no such thing as "short-lived keys", there's short lived SSH certificates.
    • deleted 5y ago
      [deleted]
    • pphysch 5y ago
      Yes, a cert is just a public key that's been "stamped" by a certificate-authority (CA), allowing it to be validated by servers holding the CA public key (as well as enforcing other policies like lifespan, principles). It is a totally separate file and does not modify the original public or private key, which indeed have no notion of lifespan. If you are constantly regenerating uncompromised SSH keys, you are probably doing something wrong. The GP is misleading in this way.
• hedora 5y ago
  Ughh. Go read up on ACME (Let's Encrypt). Unless you run your own Certificate Authority root, or configure things very carefully, using TLS certificates grants host level access to your DNS provider, and every organization that reliably routes external traffic to your host. To what end? The threat model rekeying tries to protect against involves compromised authenticated client machines. Once you have those, the attacker has shell on the server, and it's game over. There are these things called "advanced persistent threats" that have been in the news a lot already.
  • remram 5y ago
    This article has nothing to do with Let's Encrypt, ACME, TLS, or DNS.
• pilif 5y ago
  I love ssh certificates for access and indeed we're using this for accessing our production network using a few small pieces of home-grown infrastructure. However, there's one big issue nobody is talking about: There is zero support for certificate authentication in any SSH clients for iOS and most people who have network access here also have iOS devices. And even if there were support, just supporting the certificates alone is not enough - there would need to be some automatable way of getting a new certificate into an app as the whole idea of the certificates is that they are very short-lived (days or even hours if possible)
• throw7 5y ago
  The comparison to public-key authentication is wrong. Introducing cert authentication brings a third party: public key infrastructure (which isn't addressed at all and is described as some type of security panacea). The more apt comparison should be made to other authentication technologies like, in particular, kerberos.
• politician 5y ago
  The SSH servers that I'm familiar with are spun up with a host cert, so all of the FUD in this article about connecting to an unknown host is a non-issue. Check that the host cert matches the one you expect once, and the tooling makes sure to notify you if it changes. As far as provisioning, maintaining a secure CA signing practice is a nightmare. It's K8S level of self-inflicted pain for a startup. If you're running at a larger scale and can dedicate a team to it, fine. If you're a dozen people trying to launch, getting the devops guy to run `ssh-copy-id` is not the challenge that this article makes it out to be. Nor is the slightly more automated Terraform script that installs and uninstalls authorized keys from servers.
• gernb 5y ago
  dumb question but .... isn't it a problem that private ssh keys are stored in ~/.ssh and that any random app, npm dependency, build script, etc could copy them across the network?
  • marwis 5y ago
    You can password protect them and optionally load them to agent at logon.
• dmuth 5y ago
  Agreed--SSH certificate authorities (and principals) are powerful things that can be used to manage SSH access at scale. My workplace is a large enterprise that uses our own CA for getting access to systems--the keys it issues are good for 8 hours, then we have to grab a new key (using an internal utility). For anyone who is interested, I put together a little playground which can be spun up in Docker that allows you to play around with and learn how SSH CAs and Principals work: https://github.com/dmuth/ssh-principal-and-ca-playground https://github.com/dmuth/ssh-principal-and-ca-playground
• tonymet 5y ago
  Great article. All of your internal authentication should be using certificates. Web auth, Wifi, VPN, SSH In the late 90s we came close to having this for the public internet as well but it never caught on. We paid the price with endless breaches and unmanageable credentials.
• _wldu 5y ago
  SSH certificates are useful in large environments when scaling, automatic onboarding and offboarding are important, but IMO, small teams can (and should) continue using authorized key files as they have for years. They don't really need these features.
• defanor 5y ago
  > This makes it operationally challenging to reuse host names. If prod01.example.com has a hardware failure, and it’s replaced with a new host using the same name, host key verification failures will ensue. A new machine should just have a new name. If one really wants to pretend that it's the old one, they'd better really copy it, including the keys. But even skipping that, sorting this out doesn't seem like a big deal (at least at a small scale; I suspect the article makes more sense in some scenarios than in others). > Curiously, OpenSSH chooses to soft-fail with an easily bypassed prompt when the key isn’t known (TOFU), but hard-fails with a much scarier and harder to bypass error when there’s a mismatch. Seems to me like a sensible behaviour for TOFU, not sure what's curious about it. Sounds like it implies that an unknown key is at least as bad as a different-than-known key, but that sounds wrong in context of TOFU. > Once the user completes SSO, a bearer token (e.g., an OIDC identity token) is returned to the login utility. The utility generates a new key pair and requests a signed certificate from the CA, using the bearer token to authenticate and authorize the certificate request. So the weakest point will likely be the SSO and the related infrastructure, instead of SSH and actual keys, and you'll probably depend on third-party services and/or custom/uncommon self-hosted infrastructure. Likely with a SPOF too. Doesn't sound good in general. It probably does make sense in some organizations, but this particular setup doesn't seem to apply to all SSH uses, and to justify the title.
  • tptacek 5y ago
    Again, the alternative to SSO's single SPOF is many SPOFs for each individual engineer with access.
    • otabdeveloper4 5y ago
      Or you could automate key distribution and revocation instead of giving away the keys to your little kingdom to Google. (Let's not pretend that "SSO" doesn't mean "let Google or Microsoft handle password storage for me".)
      • tptacek 5y ago
        No: (1) Authentication bypass to your email service is already game-over for almost every serious company. (2) Google (if that's what you're using) has better MFA and access control than what you're going to roll yourself. (3) Having multiple sources of truth for authentication is a corpsec nightmare, and companies that don't have that invariably wind up accidentally persisting access for departed team members or contractors, and, worse, no single place to consult for a reliable catalog of who has access to what, which is why if you poll CISOs at large-ish tech companies, they'll universally tell you than one of the first 5 things they did when they took over was get SSO stood up. (4) The "automated key distribution and revocation" system you roll yourself will be jankier and less safe than the certificate-based systems that already exist. (5) Because that automated key distribution and revocation system does not in fact exist, what you're really saying is that you're going to live with developers having long-lived keys on their laptops. If you don't trust Google, set up Shibboleth or something; the Google stuff is a sideshow. But the idea that you should manage SSH authentication separately from the rest of your authentication is pretty unserious. I spent about 4 years, recently, parachuting into dozens of mid-sized startups, all of them clueful, and except for the teams that had SSO-linked SSH access, SSH management was invariably a total nightmare. The "just manage SSH directly" approach is, empirically, a failed model.
• risson 5y ago
  Anyone have experience with using SSHFP records to avoid the so-called anti pattern of trust on first use?
  • egberts1 5y ago
    Biggest problem with SSHFS RR is the trustworthiness of DNS to deliver the answer record. Most everything do not enforce their DNS resolver to only return the DNSSEC-verified Answer RR. Not that problem at all if you set the resolver to return only the DNSSEC-verified answer RRs; then again, most common websites would then stop working simply because they don’t use or have a proper setup of their DNSSEC overhead. Most implementation of distribution of the SSH public keys are delivered under cover of TLS, IPSec, or variants of secured tunneling just because … because it IS A metadata.
• nix23 5y ago
  If you trust a third party you doing ssh wrong :)
• sigmonsays 5y ago
  Who really wants to run a CA though?
• quillo 5y ago
  I have built a small signing service that works by a user SSHing in, performing LDAP (password) authentication and 2FA with duo, then injecting a time-limited certificate signed by Hashicorp Vault back to their user agent (although it could be modified to remove the Vault requirement). The UX is very simple (SSH to this address once per day), but the backend is complicated, so if there is any demand for me to put this on Github I am happy to do so.
  • egberts1 5y ago
    Did it make a good use of `AuthorizedKeysCommand` option of `sshd_config`?
• eternityforest 5y ago
  AFAIK unless something SSH passwords don't use any kind of PAKE or zero-knowledge. It just straight up sends it to the server after authenticating, as the password box on a website login page would. Really missed a great opportunity to add perhaps even more security than the server cert can(Because of how many users override it). Come to think of it, website logins shouldn't exist either, that's way too common and I don't see why there's no PAKE based http basic auth feature.
• gunapologist99 5y ago
  So now simple and reliable SSH keys must now be replaced by a far more complex security architecture with a lot of interworking parts and a full-blown PKI and certificate authority, and the opportunity for any of the nodes to DoS the CA and prevent me from logging in. I guess it's time to toss out my local (self-hosted) Userify setup that has been reliably working for years, where I can just instantly update my keys across all servers, and still log in even if some bad guys start DDoS'ing my Userify host, and just switch over to certs. Oh, wait, now I see. This is a sales pitch for their web-based SSO app. If you don't use it, you're "doing SSH wrong". Good to know.
• 9dev 5y ago
  SSH certificates are great in theory, but the whole certificate management, ad-hoc issuance, and revocation require boatloads of infrastructure. If you do it right, certificates will be signed as needed and have a short validity period, say half an hour or something. That means you need an automated signing application, or a very cheap full-time certificate manager. I’ve actually started working on such an app recently, including a web portal, CA rotation, automated configuration distribution, etc. Still far from usable, but if you’re interested in contributing: https://github.com/Radiergummi/fides https://github.com/Radiergummi/fides
• junon 5y ago
  Another headline that completely ignores the concept of threat modeling. If you're preaching about what's "right" and "wrong" regarding security without considering the threat model, you're only doing harm to your readers.
• egberts1 5y ago
  I am only disappointed that SSH certificate didn’t leverage OpenSSL for their powerful capability. I guess that’s the small price to pay for speed of development without going through the international committee of ASN.1
• egberts1 5y ago
  You can always host your own SSH CA pubkey server. It is called an “AuthorizedKeysCommand” in `/etc/ssh/sshd_config`. https://jpmens.net/2019/03/02/sshd-and-authorizedkeyscommand/ https://jpmens.net/2019/03/02/sshd-and-authorizedkeyscommand...
• parasense 5y ago
  I disagree. SSH keys seem great at first, 4KiB ~ 8 KiB public/private key-pairs are tremendously more secure than something like an 10-character password. The math checks out at an academic level, but the implementation has a glaring flaw. One cannot easily ensure private keys are themselves protected by a 10-character password unlock. Put another way, people using private keys NOT protected by a secret pass/phrase are super vulnerable to compromise. For example, physically take the laptop that contains the private key, and BOOM! That's the jist. Private keys can be setup with passwords, but the person in control of the private key can change their key's pass/phrase at anytime after, so straight-forward key escrow strategies don't work. Inspecting the public key does not indicate the associated private key has any protection, and that's good insofar as one key not leaking information about its' counterpart.