4 ms·

One approach I started using a could of years ago was storing SSH private keys in the TPM, and using it via PKCS11 in SSH agent. One benefit of Microsoft requi

• homebrewer 9mo ago
  Or use a FIDO token to protect your SSH key, which becomes useless without the hardware token. https://wiki.archlinux.org/title/SSH_keys#FIDO/U2F https://wiki.archlinux.org/title/SSH_keys#FIDO/U2F That's what I do. For those of us too lazy to read the article, tl;dr: ssh-keygen -t ed25519-sk or, if your FIDO token doesn't support edwards curves: ssh-keygen -t ecdsa-sk tap the token when ssh asks for it, done. Use the ssh key as usual. OpenSSH will ask you to tap the token every time you use it: silent git pushes without you confirming it by tapping the token become impossible. Extracting the key from your machine does nothing — it's useless without the hardware token.
  • NylonMeltdown 9mo ago
    Except that an attacker can modify the ssh config to enable session multiplexing with a long timeout and then piggy-back off that connection, right?
    • TacticalCoder 9mo ago
      Are you saying that because there are still more complicated potential attacks hardware tokens offer zero benefits? Anyway, what about the sshd server having this config line: sshd_config MaxSessions 1 could that help?
    • pxc 9mo ago
      Looks like on the server side this can be mitigated somewhat by the MaxStartups¹ setting for OpenSSH or equivalent behavior for other services that support SSH auth (e.g., Git forges like GitHub): MaxStartups Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10:30:100. Alternatively, random early drop can be enabled by specifying the three colon separated values start:rate:full (e.g. "10:30:60"). sshd(8) will refuse connection attempts with a probability of rate/100 (30%) if there are currently start (10) unauthenticated connections. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches full (60). So it looks like it's possible to support ControlMaster while still somewhat hampering mass-cloning thousands of repos via SSH key without reauthenticating. Admittedly I'd put this more in the category of making endpoint compromise easier to detect than that of actually preventing any particular theft of data or manipulation of systems. But it might still be worth doing! If it means only a few dozen or only a hundred repos get compromised before detection instead of a few thousand, that's a good thing. Besides all that (or MaxSessions, as another user mentions), if an attacker compromises a developer laptop and can only open those connections as long as the developer is online, that's one thing. But a plaintext key that they can grab and reuse from their own box is obviously an even sweeter prize! "The SSH key on my YubiKey is useless to attackers" is obviously the wrong way to think about this, but using a smartcard for SSH keys is still a way to avoid storing plaintext secrets. It's good hygiene. -- https://www.man7.org/linux/man-pages/man5/sshd_config.5.html https://www.man7.org/linux/man-pages/man5/sshd_config.5.html