11 ms·

I have been thinking about this. How do I make my git setup on my laptop secure? Currently, I have my ssh key on the laptop, so if I want to push, I just use gi

• noman-land 9mo ago
  You can add a gpg key and subkeys to a yubikey and use gpg-agent instead of ssh-agent for ssh auth. When you commit or push, it asks you for a pin for the yubikey to unlock it.
  • larusso 9mo ago
    There is the FIDO feature which means you don’t need to hackle with gpg at all. You can even use an ssh key as signing key to add another layer of security on the GitHub side by only allowing signed commits.
  • esseph 9mo ago
    You can put the ssh privkey on the yubikey itself and protect it with a pin. You can also just generate new ssh keys and protect them with a pin.
  • larusso 9mo ago
    1 store my ssh key in 1Password and use the 1Password ssh agent. This agents asks for access to the key(s) with Touch ID. Either for each access or for each session etc. one can also whitelist programs but I think this all reduces the security.
• benoau 9mo ago
  You can set up your repo to disable pushing directly to branches like main and require MFA to use the org admin account, so something malicious would need to push to a benign branch and separately be merged into one that deploys come from.
  • sallveburrpi 9mo ago
    Pushing directly to main seems crazy - for anything that is remotely important I would use a pull request/merge request pattern
    • esseph 9mo ago
      Depends on the use case of the repo.
    • otterley 9mo ago
      There's nothing wrong with pushing to main, as long as you don't blindly treat the head of the main branch as production-ready. It's a branch like any other; Git doesn't care what its name is.
      • sallveburrpi 9mo ago
        Yea ofc I was implying that main is the branch that is pushed to production.
  • t0mas88 9mo ago
    But the attacker could just create a branch, merge request and then merge that?
    • benoau 9mo ago
      They can't with git by itself, but if you're also signed in to GitHub or BitBucket's CLI with an account able to approve merges they could use those tools.
    • x0x0 9mo ago
      We require review on PRs before they can be merged.
• CGamesPlay 9mo ago
  Add a password or hardware 2-factor to your ssh key. And get a password manager with the same for those admin credentials.
• madeofpalk 9mo ago
  I’ve started to get more and more paranoid about this. It’s tough when you’re running untrusted code, but I think I’ve improved this by: not storing SSH keys on the filesystem, and instead using an agent (like 1Password) to mediate access Stop storing dev secrets/credentials on the filesystem, injecting them into processes with env vars or other mechanisms. Your password manager could have a way to do this. Develop in a VM separate from your regular computer usage. On windows this is essential anyway through using WSL, but similar things exist for other OSs
• anthonyryan1 9mo ago
  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 requiring them for Windows 11 support is that nearly every recent computer has a TPM, either hardware or emulated by the CPU firmware. It guarantees that the private key can never be exfiltrated or copied. But it doesn't stop malicious software on your machine from doing bad things from your machine. So I'm not certain how much protection it really offers on this scenario. Linux example: https://wiki.gentoo.org/wiki/Trusted_Platform_Module/SSH https://wiki.gentoo.org/wiki/Trusted_Platform_Module/SSH macOS example (I haven't tested personally): https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb4acf https://gist.github.com/arianvp/5f59f1783e3eaf1a2d4cd8e952bb...
  • 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?
• otterley 9mo ago
  Your SSH private key must be encrypted using a passphrase. Never store your private key in the clear!
  • nottorp 9mo ago
    And what do you do with the passphrase, store it encrypted with a passphrase?
    • 0xbadcafebee 9mo ago
      You memorize it, or keep it in 1Password. 1Password can manage your SSH keys, and 1Password can/does require a password, so it's still protected with something you know + something you have.
    • fwip 9mo ago
      One option is to remember it.
      • nottorp 9mo ago
        I don’t think that’s considered secure enough, see the other answers and the push for passkeys. I mean, if passphrases were good for anything you’d directly use them for the ssh connection? :)
        • otterley 9mo ago
          Passphrases, when strong enough, are fine when they are not traversing a medium that can be observed by a third party. They're not recommended for authenticating a secure connection over a network, but they’re fine for unlocking a much longer secret that cannot be cracked via guessing, rainbow tables, or other well known means. Hell, most people unlock their phones with a 4 digit passcode, and their computers with a passphrase.
          • nottorp 9mo ago
            > when they are not traversing a medium that can be observed by a third party Isn't that why all those security experts are pushing for SSL everywhere and 30 second certificate expiration? To make the medium unobservable by a third party? If you believe them, passphrases should be okay over fiber you don't control too.
• 0xbadcafebee 9mo ago
  1) Get 1Password, 2) use 1Password to hold all your SSH keys and authorize SSH access [1], 3) use 1Password to sign your Git commits and set up your remote VCS to validate them [2], 4) use GitHub OAuth [3] or the GitHub CLI's Login with HTTPS [4] to do repository push/pull. If you don't like 1Password, use BitWarden. With this setup there are two different SSH keys, one for access to GitHub, one is a commit signing key, but you don't use either to push/pull to GitHub, you use OAuth (over HTTPS). This combination provides the most security (without hardware tokens) and 1Password and the OAuth apps make it seamless. Do not use a user with admin credentials for day to day tasks, make that a separate user in 1Password. This way if your regular account gets compromised the attacker will not have admin credentials. [1] https://developer.1password.com/docs/ssh/agent/ https://developer.1password.com/docs/ssh/agent/ [2] https://developer.1password.com/docs/ssh/git-commit-signing/ https://developer.1password.com/docs/ssh/git-commit-signing/ [3] https://github.com/hickford/git-credential-oauth https://github.com/hickford/git-credential-oauth [4] https://cli.github.com/manual/gh_auth_login https://cli.github.com/manual/gh_auth_login
  • zozos 9mo ago
    I already use 1password and have it already installed. Will try this out. Thanks!
  • throw14082020 9mo ago
    Okay great advice, thanks. I'm already using Bitwarden and found out they have an SSH Agent feature too [1]. I've tried lastpass, Bitwarden, 1password and I prefer Bitwarden (good UX, very affordable) [1] https://bitwarden.com/help/ssh-agent/ https://bitwarden.com/help/ssh-agent/
  • madeofpalk 9mo ago
    Make sure the gh cli isn’t storing oauth credentials in plaintext as it can silently do.
  • DANmode 9mo ago
    Bitwarden verbiage deserves to be higher than 1Password, here.
• snickerbockers 9mo ago
  password-protect your key (preferably with a good password that is not the same password you use to log in to your account). If you use a password it's encrypted; otherwise its stored on plaintext and anybody who manages to get a hold of your laptop can steal the private key.
• mr_mitm 9mo ago
  There is no defense against a compromised laptop. You should prevent this at all cost. You can make it a bit more challenging for the attacker by using secure enclaves (like TPM or Yubikey), enforce signed commits, etc. but if someone compromised your machine, they can do whatever you can. Enforcing signing off on commits by multiple people is probably your only bet. But if you have admin creds, an attacker can turn that off, too. So depending on your paranoia level and risk appetite, you need a dedicated machine for admin actions.
  • otterley 9mo ago
    It's more nuanced than that. Modern OSes and applications can, and often do, require re-authentication before proceeding with sensitive actions. I can't just run `sudo` without re-authenticating myself; and my ssh agent will reauthenticate me as well. See, e.g., https://developer.1password.com/docs/ssh/agent/security https://developer.1password.com/docs/ssh/agent/security
    • mr_mitm 9mo ago
      The malware can wait until you authenticate and perform its actions then in the context of your user session. The malware can also hijack your PATH variable and replace sudo with a wrapper that includes malicious commands. It can also just get lucky and perform a 'git push' while your SSH agent happens to be unlocked. We don't want to rely on luck here. Really, it's pointless. Unless you are signing specific actions from an independent piece of hardware [1], the malware can do what you can do. We can talk about the details all day long, and you can make it a bit harder for autonomously acting malware, but at the end of the day it's just a finger exercise to do what they want to do after they compromised your machine. [1] https://www.reiner-sct.com/en/tan-generators/tan-generator-for-the-sparkasse-via-chiptan-qr/ https://www.reiner-sct.com/en/tan-generators/tan-generator-f... (Note that a display is required so you can see what specific action you are actually signing, in this case it shows amount and recipient bank account number.)
      • otterley 9mo ago
        Do you have evidence or a reproducible test case of a successful malware hijack of an ssh session using a Mac and the 1Password agent, or the sudo replacement you suggested? I assume you fully read the link I sent? I don't think you're necessarily wrong in theory -- but on the other hand you seem to discount taking reasonable (if imperfect) precautionary and defensive measures in favor of an "impossible, therefore don't bother" attitude. Taken to its logical extreme, people with such attitudes would never take risks like driving, or let their children out of the house.
• benfrancom 9mo ago
  If github, take a look at gh cli or git credential manager: https://docs.github.com/en/get-started/git-basics/caching-your-github-credentials-in-git https://docs.github.com/en/get-started/git-basics/caching-yo...
  • progbits 9mo ago
    I wouldn't say that's better. Now your .config directory contains a github token that can do more than just repo pull/push, and it is trivially exfiltrated. Though similar thing could be said for browser cookies.
• mshroyer 9mo ago
  Not a perfect defense, but sufficient to make your key much harder to exploit: Use a Yubikey (or similar) resident SSH key, with the Yubikey configured to require a touch for each authentication request.
• TacticalCoder 9mo ago
  > Currently, I have my ssh key on the laptop ... My SSH keys aren't on my computer: they're safely hidden on a hardware token, behind a secure element, like a Yubikey. Devices like the Yubikey do precisely exist because computers aren't things to be trusted. So their reason for being is to offer a minimal attack surface. When I git fetch/pull/push I just do it. But it requires me to physically use my Yubikey. It's not 100% foolproof but it's way better than having SSH keys only protected by a password. So Git over SSH, on a Git/SSH server that supports Yubikeys.
• fsflover 9mo ago
  You can use split-ssh on Qubes OS, such that your development environment won't have the access to your private keys: https://forum.qubes-os.org/t/split-ssh/19060 https://forum.qubes-os.org/t/split-ssh/19060