5 ms·

> We can’t change git’s shell to /sbin/nologin or /bin/false, or users wouldn’t be able to connect over SSH. Git actually has a solution for this! I don’t know

> We can’t change git’s shell to /sbin/nologin or /bin/false, or users wouldn’t be able to connect over SSH. Git actually has a solution for this! I don’t know if it would work with the custom python stuff going on, but you can set the login shell to `git-shell`

jbverschoor 2y ago
Or just use git over https. And heck, if that's such a big problem, switch to a vcs that you can properly manage
- xenophonf 2y ago
  You shouldn't use Git over HTTPS. With SSH, you can use a hardware authenticator that requires both proof of ownership (i.e., the unlock PIN) and proof of possession (i.e., physical touch) out of the box. That's technically possible over HTTPS, of course, but I have yet to see a Git server that works that way.
  - jbverschoor 2y ago
    Why not? Your password manager or passkeys do the same thing. Heck, just true the public key as the authentication header. Or use authentication certificates. If ssh is such a big problem, use something else
    - rwteueru 2y ago
      [flagged]
      - arccy 2y ago
        credential helpers: like the github cli: https://cli.github.com/manual/gh_auth_setup-git https://cli.github.com/manual/gh_auth_setup-git or git-credential-manager: https://github.com/git-ecosystem/git-credential-manager https://github.com/git-ecosystem/git-credential-manager
        declan_roberts 2y ago
        Sweet a new thing vulnerable to supply chain attacks to fix things vulnerable to supply chain attacks.
    - Joel_Mckay 2y ago
      The key difference is https certificates often require signing authority integrity, and leak-free SSL libraries. Traditionally both facets of the 3rd party trust model have had CVE over the years. SSL protocol misconfiguration is also very common, and connections can be downgraded by adversaries into a vulnerable version of the protocol. It could be argued ssh is a weaker Trust on first use model, but in most cases the keys will rarely change for the short service life of the server instance... and the server may be setup from a local physical terminal, and keys communicated out-of-band to remote users. At some point one has to admit if someone really wants in they will physically pull the drive in the data center. However, people using web vulnerability scanners on your systems are less of a nuisance. Best regards =3
      - fc417fc802 2y ago
        > It could be argued ssh is a weaker Trust on first use model That is but an optional aspect of the configuration (albeit by far the most common).
      - crote 2y ago
        > The key difference is https certificates often require signing authority integrity Couldn't you use your "traditional" SSH keys to generate an ephemeral self-signed client certificate which shares the same keypair as your SSH key? That would at least solve the CA issue for the client-to-server authentication.
        Joel_Mckay 2y ago
        It is a complex issue, and while public key encrypted exchanges could bootstrap a remote secure session (gpg/pgp etc.) to re-key the ssh server... there still is no guarantee someone isn't keeping a copy of that ssh session with the key-pair before you logged in as root. One should not completely trust TOFU over remote sessions, but it is the most practical solution. This is the inconvenient secret of cloud technology, and why the hosting company web panels often include abstracted firewall/vpn settings or proprietary key management (or the same authoritative problem manifests.) Good luck, =3
    - TacticalCoder 2y ago
      > If ssh is such a big problem, use something else It's not a problem. You can use SSH today (and since years already now) with Yubikey and the likes. I'm using Git over SSH with Yubikeys and it works. Use Git over SSH, use a Yubikey (or whatever suits you), set the login shell to git-shell.
      - johnisgood 2y ago
        Yubikey does look interesting, I thought of getting one. Sorry for this stupid question, but since if you use it with SSH, does that mean that somehow I may use my existing id_ed25519 file with Yubikey or does it need to generate a new one?
        microtonal 2y ago
        You need to generate a new one on key (it’s not actually generated and already on the key, but that’s a technical detail). The idea is that the private key cannot be leaked since it never leaves the key.
        johnisgood 2y ago
        Is there no way to use my existing one with either version / model? :(
        nine_k 2y ago
        No. The whole point of hardware keys is that the private key bytes are securely locked inside the key, with no way out (cannot steal) and no way in (cannot forge / tamper with). Reuse of an existing key for any reason after enrollment is not a good idea. A reluctance to just enroll another key may mean trouble with key rotation and revocation, and thus problematic security procedures. Key rotation should be fast, painless, and regular.
        johnisgood 2y ago
        I have two more questions. 1. Does it ever expire? 2. What would you do exactly if you were to lose the hardware key? Same thing as if you lost your id_ed25519 file? > Key rotation should be fast, painless, and regular. I agree. Right now I keep changing the expiry date of my GPG keys (once in a good while).
  - Joel_Mckay 2y ago
    Agreed, the ssh service on many git servers like gitea use their own user specific process instances to handle the connection. Combined with port-knocking and fail2ban, the setup has proven rather reliable over the years. The Go language can make surprisingly resilient servers if you have the memory available. The ssh key handling in gitea requires manual setup, and thus does not necessarily even have to use the same administrative user login key sets. Best regards =3
  - awesome_dude 2y ago
    FTR the "Proof of possession" relies on a (specific) random number being received from a device. It won't be long before that hardware device that is supposedly being held by a person becomes a soft device, which will then be impersonated.
    - xenophonf 2y ago
      Good point. Looking at this from the user's perspective, my concern is to limit the ability of someone with access to my computer from using a connected hardware authenticator. Maybe that physical touch activation of the authenticator has a better term—proof of presence?
      - awesome_dude 2y ago
        For my money - I'm incredibly sceptical of the technology. To me it looks like a false sense of security. There's a number of problems with the idea: - The device (eg. Phone or Tablet) gets owned and gives up its value as a provider of confirmation - Users end up nominating a password service like 1Password as the device - Someone manages to convince the authentication systems that their faux device emitting the signal, is the device in question For the second point, when I was integrating a (FOSS) passkey system into a product, it drove me up the wall having to have my phone right next to me every time I was working. I ciouldn't leave it in the next room on charge, for example. As a user I drew no comfort from the system, and viewed it as a burden, and was concerned about replacing the device in the event of a loss/theft or destruction - which is usually the pathway malicious individuals take to insert their device as the one to be used instead of the original.
        Joel_Mckay 2y ago
        Indeed, we used those RSA SecurID key fobs for VPN login in some places, and people would just "forget" them in the laptop bag. At a certain point, the user behavior IDS constraints become more important than building a deeper moat. 2FA cellphone based anything is $23 away from some adversaries control... ultimately more security theater in my opinion YMMV =3
  - arccy 2y ago
    it supports the mac osxkeychain for storing credentials https://git-scm.com/docs/gitcredentials#_available_helpers https://git-scm.com/docs/gitcredentials#_available_helpers
  - 3np 2y ago
    Both HTTPS and SSH are perfectly adequate transports for git, both can be used securely, both have their footguns. No need to be tribal about it. Use what's appropriate in your situation.
amelius 2y ago
Yeah, I tried that, but it doesn't work well with git-lfs (large file storage). At least, it didn't last time I tried.
- asdffdasy 2y ago
  So, it works perfectly to most sane use cases with git.
  - amelius 2y ago
    Git isn't that opinionated.
  - diggan 2y ago
    Are you saying storing pointers to large files isn't sane to do in Git? What are your suggested solution for dealing with large assets you want versioned and easily accessible? If you're really dogmatic about it, I guess you would have no dependency lock files either, but commit all that code directly to git instead of having references. Some people do that, so wouldn't be a huge surprise.
    - nine_k 2y ago
      It means that the large majority of projects that don't use git-lfs can improve their security immediately and without any trouble. It also may mean that git-shell could use a few PRs adding whatever is missing for git-lfs to work, given that git-lfs does not do anything extra fancy.
    - asdffdasy 2y ago
      use something that can actually version your large files. git-lfs is silly and trying too hard. it's the literal faster horse of file versioning. it's so wrong by design i don't even know where to start.

jbverschoor 2y ago

Or just use git over https. And heck, if that's such a big problem, switch to a vcs that you can properly manage

xenophonf 2y ago
You shouldn't use Git over HTTPS. With SSH, you can use a hardware authenticator that requires both proof of ownership (i.e., the unlock PIN) and proof of possession (i.e., physical touch) out of the box. That's technically possible over HTTPS, of course, but I have yet to see a Git server that works that way.
- jbverschoor 2y ago
  Why not? Your password manager or passkeys do the same thing. Heck, just true the public key as the authentication header. Or use authentication certificates. If ssh is such a big problem, use something else
  - rwteueru 2y ago
    [flagged]
    - arccy 2y ago
      credential helpers: like the github cli: https://cli.github.com/manual/gh_auth_setup-git https://cli.github.com/manual/gh_auth_setup-git or git-credential-manager: https://github.com/git-ecosystem/git-credential-manager https://github.com/git-ecosystem/git-credential-manager
      - declan_roberts 2y ago
        Sweet a new thing vulnerable to supply chain attacks to fix things vulnerable to supply chain attacks.
  - Joel_Mckay 2y ago
    The key difference is https certificates often require signing authority integrity, and leak-free SSL libraries. Traditionally both facets of the 3rd party trust model have had CVE over the years. SSL protocol misconfiguration is also very common, and connections can be downgraded by adversaries into a vulnerable version of the protocol. It could be argued ssh is a weaker Trust on first use model, but in most cases the keys will rarely change for the short service life of the server instance... and the server may be setup from a local physical terminal, and keys communicated out-of-band to remote users. At some point one has to admit if someone really wants in they will physically pull the drive in the data center. However, people using web vulnerability scanners on your systems are less of a nuisance. Best regards =3
    - fc417fc802 2y ago
      > It could be argued ssh is a weaker Trust on first use model That is but an optional aspect of the configuration (albeit by far the most common).
    - crote 2y ago
      > The key difference is https certificates often require signing authority integrity Couldn't you use your "traditional" SSH keys to generate an ephemeral self-signed client certificate which shares the same keypair as your SSH key? That would at least solve the CA issue for the client-to-server authentication.
      - Joel_Mckay 2y ago
        It is a complex issue, and while public key encrypted exchanges could bootstrap a remote secure session (gpg/pgp etc.) to re-key the ssh server... there still is no guarantee someone isn't keeping a copy of that ssh session with the key-pair before you logged in as root. One should not completely trust TOFU over remote sessions, but it is the most practical solution. This is the inconvenient secret of cloud technology, and why the hosting company web panels often include abstracted firewall/vpn settings or proprietary key management (or the same authoritative problem manifests.) Good luck, =3
  - TacticalCoder 2y ago
    > If ssh is such a big problem, use something else It's not a problem. You can use SSH today (and since years already now) with Yubikey and the likes. I'm using Git over SSH with Yubikeys and it works. Use Git over SSH, use a Yubikey (or whatever suits you), set the login shell to git-shell.
    - johnisgood 2y ago
      Yubikey does look interesting, I thought of getting one. Sorry for this stupid question, but since if you use it with SSH, does that mean that somehow I may use my existing id_ed25519 file with Yubikey or does it need to generate a new one?
      - microtonal 2y ago
        You need to generate a new one on key (it’s not actually generated and already on the key, but that’s a technical detail). The idea is that the private key cannot be leaked since it never leaves the key.
        johnisgood 2y ago
        Is there no way to use my existing one with either version / model? :(
        nine_k 2y ago
        No. The whole point of hardware keys is that the private key bytes are securely locked inside the key, with no way out (cannot steal) and no way in (cannot forge / tamper with). Reuse of an existing key for any reason after enrollment is not a good idea. A reluctance to just enroll another key may mean trouble with key rotation and revocation, and thus problematic security procedures. Key rotation should be fast, painless, and regular.
        johnisgood 2y ago
        I have two more questions. 1. Does it ever expire? 2. What would you do exactly if you were to lose the hardware key? Same thing as if you lost your id_ed25519 file? > Key rotation should be fast, painless, and regular. I agree. Right now I keep changing the expiry date of my GPG keys (once in a good while).
- Joel_Mckay 2y ago
  Agreed, the ssh service on many git servers like gitea use their own user specific process instances to handle the connection. Combined with port-knocking and fail2ban, the setup has proven rather reliable over the years. The Go language can make surprisingly resilient servers if you have the memory available. The ssh key handling in gitea requires manual setup, and thus does not necessarily even have to use the same administrative user login key sets. Best regards =3
- awesome_dude 2y ago
  FTR the "Proof of possession" relies on a (specific) random number being received from a device. It won't be long before that hardware device that is supposedly being held by a person becomes a soft device, which will then be impersonated.
  - xenophonf 2y ago
    Good point. Looking at this from the user's perspective, my concern is to limit the ability of someone with access to my computer from using a connected hardware authenticator. Maybe that physical touch activation of the authenticator has a better term—proof of presence?
    - awesome_dude 2y ago
      For my money - I'm incredibly sceptical of the technology. To me it looks like a false sense of security. There's a number of problems with the idea: - The device (eg. Phone or Tablet) gets owned and gives up its value as a provider of confirmation - Users end up nominating a password service like 1Password as the device - Someone manages to convince the authentication systems that their faux device emitting the signal, is the device in question For the second point, when I was integrating a (FOSS) passkey system into a product, it drove me up the wall having to have my phone right next to me every time I was working. I ciouldn't leave it in the next room on charge, for example. As a user I drew no comfort from the system, and viewed it as a burden, and was concerned about replacing the device in the event of a loss/theft or destruction - which is usually the pathway malicious individuals take to insert their device as the one to be used instead of the original.
      - Joel_Mckay 2y ago
        Indeed, we used those RSA SecurID key fobs for VPN login in some places, and people would just "forget" them in the laptop bag. At a certain point, the user behavior IDS constraints become more important than building a deeper moat. 2FA cellphone based anything is $23 away from some adversaries control... ultimately more security theater in my opinion YMMV =3
- arccy 2y ago
  it supports the mac osxkeychain for storing credentials https://git-scm.com/docs/gitcredentials#_available_helpers https://git-scm.com/docs/gitcredentials#_available_helpers
- 3np 2y ago
  Both HTTPS and SSH are perfectly adequate transports for git, both can be used securely, both have their footguns. No need to be tribal about it. Use what's appropriate in your situation.

amelius 2y ago

Yeah, I tried that, but it doesn't work well with git-lfs (large file storage). At least, it didn't last time I tried.

asdffdasy 2y ago
So, it works perfectly to most sane use cases with git.
- amelius 2y ago
  Git isn't that opinionated.
- diggan 2y ago
  Are you saying storing pointers to large files isn't sane to do in Git? What are your suggested solution for dealing with large assets you want versioned and easily accessible? If you're really dogmatic about it, I guess you would have no dependency lock files either, but commit all that code directly to git instead of having references. Some people do that, so wouldn't be a huge surprise.
  - nine_k 2y ago
    It means that the large majority of projects that don't use git-lfs can improve their security immediately and without any trouble. It also may mean that git-shell could use a few PRs adding whatever is missing for git-lfs to work, given that git-lfs does not do anything extra fancy.
  - asdffdasy 2y ago
    use something that can actually version your large files. git-lfs is silly and trying too hard. it's the literal faster horse of file versioning. it's so wrong by design i don't even know where to start.