OpenSSH's `ssh-keygen` command just got a great upgrade.In today's episode, I cover how Ed25519 keys are now the default, and how it probably doesn't impact ...
  • @RegalPotooEnglish
    316•7 months ago

    tl;dw - ed25519 keys are now the default

    • @SyntheadEnglish
      94•7 months ago

      Thanks for reducing the click bait.

    • @WalrusByteEnglish
      3•7 months ago

      Oh nice! That’s the key type I use anyway, so nice to know I don’t have to pass as many options in now

    • aard
      17•7 months ago

      A surprising amount of services (including Azure last I tried) can only handle RSA keys, so after trying ecdsa only for a while I ended up adding a RSA key again.

      With that said - it’s 2023, in almost all cases you should have your keys in a hardware module nowadays, in which case you’d use a different command for keygeneration.

      • FOSS Is FunEnglish
        8•7 months ago

        Actually it is the same story with TLS 1.3 and TLS 1.2. A bunch of sites still doesn’t support TLS 1.3 (e. g. arstechnica.com, startpage.com) and some of them only support TLS 1.2 with RSA (e. g. startpage.com).

        You can try this yourself in Firefox by disabling ciphers (search for security.ssl3 in about:config) or by setting the minimum TLS version to 1.3 (security.tls.version.min = 4 in about:config).

        • @deepdiveEnglish
          3•7 months ago

          Strange enough TLS 1.3 still doesn’t support signed ed25519 certificates :| P‐256, NIST P‐384 or NIST P‐521 curves are known to be “backdoored” or having deliberately chosen mathematical weakness. I’m not an expert and just a noob security/selfhoster enthusiast but I don’t want to depend on curves made by NSA or other spy agencies !

          I also wondering if the EU isn’t going to implement something similar with all their new spying laws currently discussed…

          • LaggyKar
            3•7 months ago

            AFAIK, they’re not known to be backdoored, only suspected

            • @deepdiveEnglish
              2•7 months ago

              Yeah wrong wording, but the fact that we have to depend mostly on NSA’s cryptographic schemes makes it very suspicious !

        • aard
          5•7 months ago

          Easiest and most affordable is probably a security key like the Nitrokey or the https://www.yubico.com/. I personally don’t like the company behind yubikey much, but if you want something small you can always leave in the device that’s pretty much your only option.

          For “cheaper, but a bit more effort” would be just getting a smartcard blank, a card reader (if you’re not lucky enough to have a notebook or computer with one built in), and then either write your own applet, or use one of the available opensource ones, and upload it to the card. A variant of that would be the Fidesmo card, where you get a card and their applet.

          Or you just use the TPM you may have in your system - though you’ll need to be careful with that: Typically one reason for using a hardware token is to make sure keys can’t get extracted, while TPMs often do allow key extraction. Software to make that work would be opencryptoki.

          Generally you’d use PKCS#11 to have the various components talk to each other. On your average Linux pretty much everything but GnuPG place nice. with PKCS#11. Typically you end up with pcscd to interface with the smartcard (the above USB tokens are technically also just USB smartcards), OpenSC as layer to provide PKCS#11 on top, and software (like OpenSSH) then talks to that.

          All of that should be available as packages in any Linux distribution nowadays - and typically will also provide p11-kit configured to use a proxy library to make multiple token sources easily available, and avoid blocking on concurrent access.

          ssh-add supports adding keys from pkcs#11 providers to the SSH agent (search pkcs11 in ssh-add manpage), with some distribution (like RedHat) also carrying patches allowing you to only select individual tokens for adding.

          If you’re also using GnuPG it gets more complicated - you pretty much have two options: Stick with PKCS#11, in which case you’d replace GPGs own smartcard agent with gnupg-pkcs11-scd, or you use GPGs own card implementation, in which case you can forget pretty much everything I wrote above, and just follow the security key manual for setting up a GPG card, enable SSH agent support in the GPG agent, and just use that for SSH authentication.

    • 𝒍𝒆𝒎𝒂𝒏𝒏
      11•7 months ago

      I delete them from the ssh config folder after installation, along with the DSA and ECDSA keys. No ed25519? No auth.

      Also prevents a handful of bots from attempting SSH login into your cloud infra, a lot of them don’t support ed25519 kex

    • @[email protected]
      5•7 months ago

      I had to create one this year after discovering that connectbot (ssh client on Android) didn’t support agent forwarding otherwise.

      • 𝒍𝒆𝒎𝒂𝒏𝒏
        6•7 months ago

        Probably a good idea to look for a different client, call me tinfoil but I wouldn’t want to touch a very old mechanism that is supported/pushed by a very recognisable 3 letter agency

        • LiveLMEnglish
          6•7 months ago

          I’ve just started using SSH inside of Termux, got tired of all the weird pitfalls SSH Clients for Android usually have

        • @[email protected]
          2•7 months ago

          Probably. It’s in f-droid but increasingly looking not quite unmaintained, but not developed actively enough.

    • @NoSpotOfGround
      12•7 months ago

      It says that

      Starting in 2014, OpenSSH defaults to Curve25519-based ECDH.

      So what changed recently? (I didn’t watch the video, in fairness).

      • Domi
        14•7 months ago

        ssh-keygen now defaults to ed25519 so you don’t have to do ssh-keygen -t ed25519 anymore. The default since 2014 is for key exchange when connecting.

  • @[email protected]
    7•7 months ago

    Nice no ChatGPT anymore to remember how that damn Algorithm is spelled.

    Why not just call it RSB ? People, really!