• Xanza@lemm.ee
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    2 months ago

    The only real advantage to using SSH vs PGP keys is you don’t need an external dependency (GPG). PGP is always going to be better, because you get the advantage of WOT, and PGP public key servers to verify identities over just “this is who I am, here’s my key.” You should always sign your commits, no matter what you use. Identity verification is very important in open source.

    $ git config --global gpg.format ssh
    $ git config --global user.signingkey ~/.ssh/examplekey.pub
    
    • SigmarStern@discuss.tchncs.de
      cake
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      Are you using your public ssh key for signing? Wouldn’t it make more sense to use the private one as people can then verify your identity by using your public key?

      • codesaIat@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        ·
        edit-2
        2 months ago

        Ha, good catch! Behind the scences, git is actually using your private key to sign the commit. You’re only specifying the ssh key git should ask ssh-agent about. You can also specify the private key and actually need to when not using an agent and the key is not available. See docs

        • SigmarStern@discuss.tchncs.de
          cake
          link
          fedilink
          arrow-up
          0
          ·
          2 months ago

          But why? Public is public. People can take my public key. The can encrypt my commit, making it indistinguishable from my commit.

          Isn’t the idea to use your private key for encryption so that everyone can use your public key to decrypt your signature and to verify that it’s you who actually did the commit, because no one else has access to the private key?

          • Xanza@lemm.ee
            link
            fedilink
            English
            arrow-up
            0
            ·
            edit-2
            2 months ago

            People can take my public key.

            And they can also encrypt things with it. That’s the whole point. Only the owner of the private key can decrypt what’s been encrypted with the public key, and that establishes ownership.

            Why the person you responded to is being down-voted, and why people in this thread don’t seem to understand how shared keys work is pretty insane to me. This technology has exited, and remained relatively unchanged, for like… 40 years.

            The can encrypt my commit, making it indistinguishable from my commit.

            That’s not how commits are verified. The commit is signed with your private key (not encrypted), not your public key. Referencing the public key simply tells the ssh agent which key-pair to use, and the ssh daemon decides which key to use (public or private) based on the action that you’re doing.

            Signing a commit requires your private key, so no. People can’t just grab your public key and sign commits to impersonate you. They can simply encrypt text with it. That’s it. This is all self evident by the git property user.signingkeysign”. You’re signing the commit message, not encrypting anything.

            • SigmarStern@discuss.tchncs.de
              cake
              link
              fedilink
              arrow-up
              0
              ·
              2 months ago

              Sorry for the confusion about “encryption”. I meant “signing” which is encrypting a hash of the commit with your private key, so that others can verify that your the author of the commit using your public key and the hash.

              I think, the only confusion here was the original comment that referenced the public key for signing, but this was resolved, as it is just telling git which key pair to use. Probably, all people here understand the basics of asymmetrical encryption and signing and it was merely misunderstanding of how the command for signing git commits can be used.

              • Xanza@lemm.ee
                link
                fedilink
                English
                arrow-up
                0
                ·
                2 months ago

                Signing isn’t encryption. It’s a non-cipher hash.

                $ ❯ echo "This is a signed message." | ssh-keygen -Y sign -n file -f ~/.ssh/id_ed25519 > content.txt.sig
                Signing data on standard input
                

                Which outputs the hash of the signed statement, which was signed with my private key;

                -----BEGIN SSH SIGNATURE-----
                U1NIU0lHAAAAAQAAADMAAAALc3NoLWVkMjU1MTkAAAAgCwxAYX85ptsTc+Dtz3a0IRondh
                qFF3wKMsTqt+c4oGMAAAAEZmlsZQAAAAAAAAAGc2hhNTEyAAAAUwAAAAtzc2gtZWQyNTUx
                OQAAAECvqKLkm+kWUgFh0bI8jYIR5BPUaq76MZ94exp2yUn+KnK5YA79ggFY/C4VsnDqJp
                SAedWp4eOUwPNG8RR59KsP
                -----END SSH SIGNATURE-----
                

                And can then be verified using my public key;

                ❯ echo "This is a signed message." | ssh-keygen -Y check-novalidate -n file -f ~/.ssh/id_ed25519.pub -s content.txt.sig
                Good "file" signature with ED25519 key SHA256:ltAIkPgF9rLt1KlRRh6tQUtWNT8/wErhtAibmSHfbVs
                
                • frezik@midwest.social
                  link
                  fedilink
                  arrow-up
                  0
                  ·
                  2 months ago

                  Mathematically, signing is encryption using the private key. That’s how the algorithm works. The input to the function is irrelevant.

  • Eager Eagle@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    2 months ago

    does anyone know how to configure SSH signing on a remote server without creating another key on that server?

    If I’m using the same SSH key pair to access the remote server it kinda makes sense to use it to sign, but I don’t know how I would go about configuring git to do it.