26 ms·

Sign arbitrary data with your SSH keys

637 points by h1x 5y ago

politelemon 5y ago
> You'll soon be able to sign Git commits and tags with SSH Once Git 2.34 adds the ability to do this, will Github still show its verified indicator? https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification https://docs.github.com/en/authentication/managing-commit-si...
inopinatus 5y ago
This has long been possible by using the SSH key via the openssl command line, since they're available as PEM. I've relied on that occasionally in provisioning code, albeit specifically using the server key rather than a client identity. Heck, you can even use them for encryption that way. Nevertheless, it's nice to have some more direct support.
aliswe 5y ago
*with ssh-keygen. I'm sure this has been a technical possibility since the dawn of ssh keys themselves.
infogulch 5y ago
Wait, could we use ssh keys as the a federated id? (OIDC?)
- dredmorbius 5y ago
  Cryptographically, sure, that's always been possible, and it is in fact what SSH affords: if you create an SSH keypair and drop the public half on a remote host, then the corresponding private key serves as your identifier. The crypto part is relatively easy. Ensuring that you've got the right keys on the right hosts is the hard part. E.g.: - If Eve gives Bob a key Eve describes as Alice's but which is in fact Eve's, then Bob is (unwittingly, but cryptographically validly) permitting Eve access. - If Eve can copy Alice's public key from Bob's system to one controlled by Eve, and Alice isn't scrupulous in verifying host keys, then Alice may be tricked into logging into Eve's system (and perhaps divulging further information) when she thinks she's logging into Bob's. - There's the more common problem where Bob permits a login using Alice's key, but that key has been compromised in some fashion by Eve. The cyrptography is putatively valid,[1] but the presumption over identity is not. The PGP "web of trust" model was designed to give some assurance that a key purporting to be Alice, or Bob, or Eve, actually was, and without relying on a central certification authority. It ... mostly kind of worked, but also mostly kind of didn't. Trust itself isn't a cryptographic property. Aspects or indicia of trust may be cryptographically validated. For SSH, the trust aspect has been implied in the key-delivery mechanism. Either the trusted party transmits a key directly to the recipient, or they generate the key from on the recipient's system. Further trust of that key relies on both the crypto implementation remaining valid (see again CVE-2008-0166), and control over the private key and any additional authentication factors (passphrase, physical authentication factors, etc.) remaining uncompromised. There are numerous instances in which private keys and/or passphrases have been compromised. That said, I see some appeal in being able to use, say, SSH keys rather than passwords and other factors to authenticate to websites. In fact there's no need especially to authenticate in the case of content, I need only sign the content which would demonstrated the authenticity of 1) my having signed it and 2) it not being altered since creation. (Say, if dang were to get into the sneaky habit of surruptitiously editing HN comments by other users.) ________________________________ Notes: 1. Or perhaps not, as in the case of CVE-2008-0166, the Debian bug in which time-of-day in seconds was used in key generation resulting in a namespace of only 86,400 keys being possible, a feasibly-brute-forceable space. Those key values are now blacklisted.
chasil 5y ago
You can actually use openssl with RSA keys generated by ssh-keygen to sign also, and this has worked for a long time. https://www.linuxjournal.com/content/flat-file-encryption-openssl-and-gpg https://www.linuxjournal.com/content/flat-file-encryption-op... You will have to generate an openssl-compatible public key: openssl rsa -in ~/.ssh/id_rsa -pubout -out ~/.ssh/id_rsa.pub.openssl To sign: openssl dgst -sha256 -sign ~/.ssh/id_rsa -out known_hosts.sha256 known_hosts To verify: openssl dgst -sha256 -verify ~/.ssh/id_rsa.pub.openssl -signature known_hosts.sha256 known_hosts Here is a little script to automate this: $ cat rsign #!/bin/sh set -eu # http://redsymbol.net/articles/unofficial-bash-strict-mode/ case "$(basename "$0")" in rsign) for n do openssl dgst -sha256 -sign ~/.ssh/id_rsa -out "$n".sha256 "$n" done ;; rchek) for n do printf "$n " openssl dgst -sha256 -verify ~/.ssh/id_rsa.pub.openssl \ -signature "${n}.sha256" "$n" done ;; esac $ cp /etc/passwd /etc/group /etc/hosts . $ ./rsign passwd group hosts $ ls -l *.sha256 -rw-r--r-- 1 luser lgroup 256 Nov 12 13:21 group.sha256 -rw-r--r-- 1 luser lgroup 256 Nov 12 13:21 hosts.sha256 -rw-r--r-- 1 luser lgroup 256 Nov 12 13:21 passwd.sha256 $ ln rsign rchek $ ./rchek passwd group hosts passwd Verified OK group Verified OK hosts Verified OK
- agwa 5y ago
  A major problem with doing this is that you have to worry about cross-protocol attacks because there is no namespace parameter like there is with SSH signatures. SSH signatures provide the necessary structure to safely use a single key for multiple purposes.
  - chasil 5y ago
    It's true, I do remember the DROWN exploit relying upon keys presented over differing protocols. It doesn't take long to generate an RSA key, though. A dedicated signing key would seem to be the obvious thing to do. https://en.wikipedia.org/wiki/DROWN_attack https://en.wikipedia.org/wiki/DROWN_attack
laurent92 5y ago
He’s right, SSH is widespread and easy enough to understand for, at least, programmers. It makes for an excellent tool for signatures. Public keys are easy to upload everywhere. And you pass much less as a nerd as when using PGP.
- mherrmann 5y ago
  I actually always feel kinda cool when using PGP.
  - blitzar 5y ago
    Nerd.
    - rwky 5y ago
      I have my gpg key stored in my yubi keys and use those for SSH so does that make me a super nerd?
      - Ciantic 5y ago
        Probably, I did that too, but I wish I could switch to FiloSottile's age. However age still says in the docs: > SSH keys held on YubiKeys can't be used to decrypt files. So I'm stuck with gpg. I don't want to store my private keys as a file on a computer just to decrypt stuff.
      - errcorrectcode 5y ago
        Only if you use monkeysphere and fwknop.
      - visualphoenix 5y ago
        Same. Imho it’s the best solution we have right now.
matthberg 5y ago
Looking forwards to when this gets added to git in v2.34. Setting up pgp for commit signing is such a pain. Yet since ssh is installed everywhere and I'm using it for git anyways, that's one less setup step to worry about.
- elric 5y ago
  Is it a pain? At it's most basic, it's just one line of config in .git/config. The hard part is keeping track of historical keys and revocations, so that historical commits can be validated if they were made before (but not after) a revocation. And when that happens, you immediately run into the problem that time information in git offers zero security, and that the whole operation is moot.
kzrdude 5y ago
Apparently "Signing a file is straightforward" heh no, this can not be said to improve upon GPG's interface(*). But it will be cool to see where it can go. (*) Hiding signing behind a command that's called keygen is not the interface we deserve.
dane-pgp 5y ago
> GitHub acts as a trusted third party here, and you have to trust them not to lie about people's public keys, so it may not be appropriate for all use cases. But relying on a trusted third party with a professional security team like GitHub seems like a way better default than PGP's Web of Trust, which was nigh impossible to use. Hopefully that's a false dichotomy and the entire Free Software community doesn't end up reliant on Microsoft to host all our keys for us. The article goes on to mention key transparency, though, which does seem like the right solution. I note that rekor (the transparency log implementation used by sigstore) already supports signing with SSH keys[0], so this TechRepublic article about it[1] from March (which lists only "GPG, x509 and Minisign") is already out of date. [0] https://github.com/sigstore/rekor/blob/main/types.md#ssh https://github.com/sigstore/rekor/blob/main/types.md#ssh [1] https://www.techrepublic.com/article/a-new-linux-foundation-open-source-signing-tool-could-make-secure-software-supply-chains-universal/ https://www.techrepublic.com/article/a-new-linux-foundation-...
- IYasha 5y ago
  Thanks for the insight and links! And really... > relying on a trusted third party ... like GitHub seems like a way better default than PGP's Web of Trust Made me scream: "What??" I'd personally prefer some decentralized torrent-like way of user key distribution.
  - majou 5y ago
    What would that look like? Distributing keys is always the hard part.
    - IYasha 5y ago
      Well, I tried to avoid saying blockchain, which is already being implemented https://hackernoon.com/decentralized-public-key-infrastructure-dpki-what-is-it-and-why-does-it-matter-babee9d88579 https://hackernoon.com/decentralized-public-key-infrastructu... but is resource-heavy. On the second thought, there are potential problems with DHT-like way of distribution (rogue peer overwhelming, etc) I can't seem to find article on this idea (it's pretty old), sorry.
GauntletWizard 5y ago
That's pretty interesting. To some extent, it was possible even before - Support for converting SSH RSA Keys to OpenSSL formats is old old, and you can use those to encrypt/decrypt or sign/verify arbitrary data via the openssl command. In fact, AWS uses this in their Windows instances, to encrypt the Administrator password[1] Definitely will mean some interesting things for Git workflows, though. I've long been in favor of requiring every commit to be signed, and making that easy to enforce either in merges or push hooks. On the other hand, Linus is publicly against it[2], with good reasoning, though I don't think compelling enough reason[3]. Signing every commit would completely break the common pattern of handling merges centrally. Most companies, unlike kernel development, have a centralized server with a "trunk" and code review is done as part of that. Signing every commit with your SSH key would break that model, badly, but it could instead be an opportunity to improve the git tooling. One of my favorite features of the now-defunct Phabricator was that you typically merged your commits with `arc land`, which a) squashed and annotated your merge with the Phabricator code review metadata and b) Deleted your branch. The latter was especially handy, but the former made code review great. Github and Gitlab can do the same as part of their UI, but it would be far better if it were nicely integrated with your existing git workflow, and this would be the opportunity to add prepush hooks to nicely integrate with hosting sites and code review tools. [1]https://docs.aws.amazon.com/cli/latest/reference/ec2/get-password-data.html https://docs.aws.amazon.com/cli/latest/reference/ec2/get-pas... [2]https://web.archive.org/web/20201111174438/http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html#a2583316 https://web.archive.org/web/20201111174438/http://git.661346... - There has to be a better archive of this mailing list than the wayback machine. Searching for this, though, led me to my previous comment[3] [3] https://news.ycombinator.com/item?id=12291462 https://news.ycombinator.com/item?id=12291462
- rkeene2 5y ago
  Fossil [0] can sign every commit [1] (with GPG or S/MIME) and have merges performed centrally because it never modifies history. Git can probably also do this for certain merge modes ? I'm not very familiar with how this works in Git. [0] https://fossil-scm.org/ https://fossil-scm.org/ [1] https://fossil-scm.org/home/help?cmd=clearsign https://fossil-scm.org/home/help?cmd=clearsign
pizza 5y ago
I get that they're "public" keys, but I was surprised to learn (and from somebody other than github themselves) that ssh public keys are just available at that github.com/username.keys URL (without there being an option to disable it, it seems?). Did most people already know that? Probably fine but just surprised. Just tried searching their authentication docs [0] and I don't get any results for "public key url" either https://docs.github.com/en/authentication?query=public+key+url https://docs.github.com/en/authentication?query=public+key+u...
- whirlwin 5y ago
  This can be a security risk if you're using the same SSH keypair for other things, and you're using a less secure algorithm than RSA or ED or similar. Anyone doing a bit of research about you might discover a vulnerable host for which the vulnerable algorithm keypair might be targeted
  - teekert 5y ago
    When that happens you were relying on security by obscurity. It’s a hack waiting to happen. This, at least creates awareness and forces secure keys. But you are right, it may be a security risk, but only when it already was (arguably it was smaller).
- erk__ 5y ago
  And similarly GPG keys are at github.com/username.gpg
  - giaour 5y ago
    This seems more legit. If a user is signing their commits, other users should have access to their public keys in order to verify the signatures.
    - megous 5y ago
      Usefulness of that access from the same service you're getting the signed commit from is close to nil. Public keys should be distributed in a trustworthy way.
gorgoiler 5y ago
The ssh-agent protocol has always had the ability to sign data. It sounds like the new part is being able to verify signatures without needing the private key. If you give ssh-agent some data and a public key then — if it has the corresponding private key — it will return a signature for your data using that private key. The protocol command is SSH_AGENTC_SIGN_REQUEST and it’s the bread and butter of how the agent does its job. Historically, it’s not tractable for public sign/verify but you can use it as a way to do symmetric encrypt/decrypt with ssh-agent.
- IYasha 5y ago
  The use of ssh-agent may be forbidden at some places, even on personal machines. I knew a few. And not that it's completely unjustified..
  - visualphoenix 5y ago
    How about gpg-agent? Is that forbidden?
    - IYasha 5y ago
      Nobody used or asked about gpg-agent back then ) The point about ssh-agent was that it stored personal keys in memory of machines shared by multiple users (admins, shifters, devs). So everyone had to type in passwords for every "ssh" )
- rkeene2 5y ago
  It hasn't been able to do it in a meaningful way. I've been patching support for this into ssh-agent for about a decade. I wrote a PKCS#11 module which talks to the SSH agent socket to forward your smartcard [0]. Doing so requires three changes to the protocol: 1. The ability to sign arbitrary data and get back the signed result [1]; normally you get back a hashed result [2]. 2. The ability to decrypt data, this is what you said. This is less important since many things only require signatures (and not all algorithms support encryption/decryption). 3. The ability to request your certificates [3] [4] this one is kinda obvious. The benefits of this are that you can use your smartcard on the remote host to do fully authenticated password-less sudo with pam_pkcs11. You can also do anything else that requires you to use your private key to be used, which can include fetching files (TLS client certificate authentication). Within the US Government, passwords have been being phased out since 2004, but the requirements for authenticated privilege elevation remain. Another way to accomplish this is to use SSH forwarding of your PC/SC socket but that's less portable and more fragile (and even less secure). [0] https://github.com/rkeene/ssh-agent-pkcs11 https://github.com/rkeene/ssh-agent-pkcs11 [1] https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?ln=481-482%20561-563%20573-576 https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?l... [2] https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent-00#section-4.5.1 https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent... [3] https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?ln=296-312 https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?l... [4] https://datatracker.ietf.org/doc/html/rfc6187#section-2.1 https://datatracker.ietf.org/doc/html/rfc6187#section-2.1
tialaramex 5y ago
This comes with a rationale for why this should be safe re-use of SSH keys, and OpenSSH provides, as you would hope, an explicit namespace mechanism so when fifty people re-use this they don't pollute each other's cryptographic context. In both cases this is unlike Filippo's age - which to me makes it a whole lot more attractive. Its relationship to your identity, contextually ("this is my GitHub key, this is the one for $VolunteerProject servers, and this third one is for my local machines") makes more sense for this purpose than in age too. Signing a git commit with a key you use on gitlab for example.
- tptacek 5y ago
  This has literally nothing to do with age, which, by deliberate design, doesn't implement signing. What a strange and hostile thing to write.
  - tialaramex 5y ago
    You wrote: > This has literally nothing to do with age, which, by deliberate design, doesn't implement signing. What a strange and hostile thing to write. But of course I never claimed age performs signing I wrote that it re-uses SSH keys without a safety rationale. Here's what age actually says about its re-use of SSH keys: "As a convenience feature, age also supports encrypting to ssh-rsa and ssh-ed25519 SSH public keys, and decrypting with the respective private key file." -- https://github.com/FiloSottile/age#ssh-keys https://github.com/FiloSottile/age#ssh-keys So, we see age does in fact re-use SSH keys for this unrelated purpose. And we see that, unlike the OpenSSH feature described in this article, it offers no rationale for why this is safe. Filippo talked about writing such a rationale but ultimately there isn't one provided. Ordinary users shouldn't try to imagine for themselves why something dangerous might be safe. In the absence of a rationale for why re-using your SSH private keys to decrypt age messages is OK, don't do it. The article provides a rationale for OpenSSH's "sign arbitrary data" feature (a briefer one is included in the OpenSSH distribution itself) so that you can assure yourself that this is a reasonable thing to do.
    - akerl_ 5y ago
csomar 5y ago
Ledger/Trezor have solved this since ~2016. I have a Ledger that has a private key inside and using a small open source tool (https://github.com/romanz/trezor-agent https://github.com/romanz/trezor-agent) I can SSH into machines, sign random data and Github commits and FIDO authenticate into several websites. All of that and knowing that these devices offer some of the best security out there.
- johnyzee 5y ago
  Hardware devices like the crypto wallets are a pretty good solution (no pun intended), imho. Both very convenient and very secure. I like the minimalism of something like the Trezor, no battery, tiny B/W display and two hardware buttons. Plug in, click button to confirm signing, done.
- stavros 5y ago
  FIDO2 is even better because SSH supports it natively, so there's no setup at all.
dandanua 5y ago
This is awesome and should be more widespread. I always feel embarrassed when I see government systems that use digital signatures infrastructure. Usually, a government website has their own web application through which you input your private key and your password. Sure, usually those applications use standard libraries that do computations locally. But how do I know this? If such a website is hacked – my private key will be exposed.
- numair 5y ago
  > web application through which you input your private key and your password Sorry, what? Can you point me to some examples, because this sounds so crazy. Why would you ever upload your private key to a server? Sounds like security theatre to me...
  - dandanua 5y ago
    The verification is local (through javascript, nowadays). But you can't know this if you're not a hacker that can check it. It's widespread in Ukraine, and I assumed it's similar in other countries. I mean hackers could change the code of the website so that private keys will be uploaded without noticing by users.
    - numair 5y ago
      Ahh yes, now that I think about it, I’ve seen this sort of implementation before: 1. Government forces you to jump through hoops with some collection of favored — sorry, I meant “authorized” — vendors who can issue you a certificate for $WTF (either paid directly or through your taxes...). 2. You are provided with the private key in some manner. Hopefully not in your email, but that’s often what happens. 3. Whenever you want to validate yourself to the service, the government website then has you upload that private key to use in their own homemade implementation of JavaScript PKI. Sometimes they actually take the key from you and send it to their server to do the work. ... I think we are both in agreement that this is pretty lousy. And if you’re seeing it in Ukraine, it’s a world-wide “security” model. Maybe someone else here on HN can explain the thinking that went into these sorts of implementations...
jatone 5y ago
this was always possible.... ssh just didn't do it. but you absolutely could use your key to sign data.
kybernetyk 5y ago
So a little offtopic but I’m still curious: how do you handle multiple machines and SSH keys? I mean do you run ssh-keygen on a new machine and have for each computer a separate key pair or do you have one key pair that you copy on every new machine? I have seen both and using one key pair looks very convenient but also makes me feel a little uneasy. I myself have a key pair for each of my machines. How do you handle it?
- rkeene2 5y ago
  I use two keypairs, but with no ability to read the private key (smartcard).
  - visualphoenix 5y ago
    This is what I do as well. Yubikey configured as a smartcard running gpg-agent with enable-ssh-support.
- Hendrikto 5y ago
  I have one key pair per machine and service. About 20 pairs on my laptop, 15 on my desktop.
- adrian_b 5y ago
  You can avoid specifying a lot of parameters at each SSH connection by defining aliases, e.g. of the form ssh-servername. In each alias you put the appropriate "-i private_key_for_that_server", the server name and also "-l user_name" if you have a different user there and "-p port" if the server uses a non-standard port. Thus, after the initial key setup, connecting to any server with different credentials is no more complex than when using a single key pair. Except for an extra keygen step, the initial setup is not more complex than when using a single key pair, as you have to copy the public keys anyway, which is the more difficult part of the setup.
  - theli0nheart 5y ago
    You might want to look into using .ssh/config instead, as it is built into SSH. In addition to letting you specify keys/usernames for arbitrary hosts, you can also use rules for wildcards, etc.
rvdginste 5y ago
Regarding PGP's 'Web of Trust', I thought the purpose of this was to validate the link between the key and the owner of that key. This is not what you get from retrieving a public key from github... that only gives you the link between that key and a github account. But what does that give you? From what I understand, it gives you nothing for anything that is signed and that does not have a direct link to a github account. Obviously, if someone releases software on that github account and I find a signed release of that software, I can validate that it really was signed by the official source of that software on github. For anything that does not have that direct link, it really does not give you anything. I've never used PGP, but I thought the web of trust was used to validate metadata on the key and that this can be used to validate that a key really belongs to the person that you think it belongs to. I saw it more like how you have SSL certificates with different degrees of validation and where you must deliver more proof of your identity if you want to receive a certification with a higher degree of validation. I'm all for using SSH keys for signing, but I still would like to have something like PGP's web of trust for those keys.
- kenmacd 5y ago
  I agree, but I think it's pretty clear that web-of-trust has failed. There may be 6 or fewer degrees of separation between us, but the chance that there's a path of people that actually validate and sign keys isn't very high. As an alternative keybase.io worked well. If you knew the person controlling the github account also controlled the mastodon/twitter where you talked to them, and the website/blog, etc, then you can be pretty sure it's them. (I saw mention of more open systems here too https://news.ycombinator.com/item?id=29132024 https://news.ycombinator.com/item?id=29132024). > I'm all for using SSH keys for signing, but I still would like to have something like PGP's web of trust for those keys. same here. I use my gpg key for ssh (stored on a yubikey). Seems like a better option to me.
  - notatoad 5y ago
    i think the main assumption that keybase makes is an important one: you don't need to link a key to a person, you need to link it to an identity. and a github page or a twitter account is an identity. the IRL identity of the person controlling that web identity can be considered out of scope. if you do need to link a key to an actual non-digital person, then you've got a whole different set of problems.
Tepix 5y ago
We've come full circle then: https://medium.com/@chrispisano/ssh-authentication-with-gpg-411676781647 https://medium.com/@chrispisano/ssh-authentication-with-gpg-... TL;DR: Use the same key in GPG and SSH by it exporting out of GPG into SSH gpg --export-ssh-key
- errcorrectcode 5y ago
  monkeysphere manages ssh keys in gpg and also communicating with ssh-agent (or gpg-agent).
alecco 5y ago
Please consider donating to the OpenBSD Foundation (OpenSSH project) https://www.openbsd.org/donations.html https://www.openbsd.org/donations.html
stavros 5y ago
Is this the same AGWA that made git-crypt? I look forward to being able to encrypt the repo key to SSH keys, rather than GPG ones.
- hardwaresofton 5y ago
  Yes it is, and they are awesome. git-crypt[0] is a godsend for smaller projects (and maybe larger ones if permissions are granular enough) -- way simpler than sops[1] and other alternative, with native integration via git filters (smudge). I use it on a ton of projects. [0]: https://www.agwa.name/projects/git-crypt/ https://www.agwa.name/projects/git-crypt/ [1]: https://github.com/mozilla/sops https://github.com/mozilla/sops
  - stavros 5y ago
    Same, I love it. The GPG bit is the only inconvenient part.
yewenjie 5y ago
Is it a good practice to use only one SSH key pair or different pairs for different things? Also, how do people usually store SSH keys for long term?
- elric 5y ago
  I use a different key pair for every service. Where "service" is defined pretty loosely. All the company servers I access for work, for instance, use the same key pair. But I have different key pairs for github, gitlab, etc. I also have a work github account for FOSS contributions, which uses a different key pair than my personal github account. I have a config file per identity (work, personal, second job, etc) in ~/.git/config_$identity. Each of those files contains a Host entry with key configuration for every service I use. I rely on a bit of shell foo to to select the correct identity (an environment variable and an alias). Life would be a bit easier if ssh_config supported the use of variables in Include statements, that way I could just Include ~/config_${identity}. Oh well.
upofadown 5y ago
>Here's why I like SSH signatures: >* It's not PGP. The most important reason people use the OpenPGP message format is because it is a well accepted standard. Sure the cryptography is not new and fun but it is secure. If you sign something with OpenPGP then you can be sure that those signatures are verifiable on any platform by anyone. The OpenPGP standard has provisions to ensure that the signatures are from a particular entity. This proposal suggests that Github could be treated as a trusted third party. If that is the case then you don't need signatures at all. Obligatory "The PGP Problem" rebuttal: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp
- geofft 5y ago
  > The OpenPGP standard has provisions to ensure that the signatures are from a particular entity. No, it does not - it has provisions to ensure that the signatures are from a particular private key. Mapping that to a human-meaningful entity is beyond the scope of the OpenPGP specification. The article you link does not really address that point, and it doesn't at all substantiate the claim that using GitHub as a trusted third party means you "don't need signatures at all". (Also, the original post says that other means like key transparency can be used instead of trusting GitHub.)
  - shp0ngle 5y ago
    Well, if you trust github enough for the keys, you can just download and distribute the arbitrary data through github itself. I guess that is what he was referring to.
  - zucker42 5y ago
    Isn't the web of trust part of a PGP? That maps private keys to human-meaningful entities. Or is that not part of OpenPGP?
    - int_19h 5y ago
      The argument is that the whole "web of trust" thing never really took off, so you can't rely on it in practice.
reidrac 5y ago
Verifying signatures is messy, because the SSH keys don't store identity information, isn't it? So basically you know that an specific SSH key signed a file, but that's all you know. Not very useful? Who's going to maintain a file with allowed signers per key?
- fstelzer 5y ago
  Correct. Linking an identity to the crypto signature is the hard part for every mechanism. Regarding the allowed signers file you have several options: A repository only allows signed commits / merges / pushes and simply stores the file in the repo itself. If you already rely on forges like github/gitlab/... and trust them to generate a file for you (e.g. from the users ssh keys having write access to the repo). You maintain this file independently for yourself with a "Trust on first use" mechanism (which will follow in a future patch to git) A git patch currently in progress will utilize the valid-after/before options that you can set on keys in this file to verify the commits/tags with keys valid at the time of the objects creation. This will allow for key rollover and still being able to verify old signatures. (Theres also the revoke file which will invalidate all signatures for a key). In addition to that a "trust on first use" patch will follow that can automatically add new keys with the committers ident to this file (unless the ident is already present with a different key of course, which should error badly). disclaimer: i wrote the git integration for this
oedmarap 5y ago
Slightly related, but I use age[0] for most of my non-automated file encryption tasks; and one of the neat features it has is the ability to encrypt to a GitHub user's pubkey[1]. [0] https://github.com/FiloSottile/age https://github.com/FiloSottile/age [1] https://github.com/FiloSottile/age#encrypting-to-a-github-user https://github.com/FiloSottile/age#encrypting-to-a-github-us...
fstelzer 5y ago
I think one of the most compelling reasons of using ssh for signatures is the possibilies of ssh-agent and especially agent-forwarding which allow for incredibly portable workflows like ssh to a ci/build host/container to sign some production binary/container/tag. Please note that these come with their own pitfalls and precautions you'll need to take to ensure your key's safety! If you consider agent forwarding i'd recommend use of "ssh-add -c" to have your agent at least confirm every use of your private key. Generally for private key security i'd always use a hardware token. Modern yubikeys are really easy to use and you can even enable touch policy instead of the agent confirmation. The UX for this is still a bit lacking in the tooling though.
dnamlin 5y ago
Ethereum has standardized ways to formulate (off-chain) signatures for arbitrary messages [1] and Solidity structs [2]. Convenient command-line tooling is lacking currently, but some interesting twists to consider: If you sign using a key that also controls cryptoassets, then you're incentivized to keep the key safe and secure indefinitely. Contrast with tendency to lose GPG and SSH keys after losing interest for a few years, changing jobs, etc. Moreover, consider key revocation. The revocation mechanisms for GPG and SSH keys are not that effective, due to impracticality of publishing your revocation in a way that really ensures subsequent verifiers are alarmed. If only there were some sort of decentralized, permissionless, globally-replicated database which verifiers could check for that information... More generally if you have a really important signature to publish, you can mint an NFT for it or otherwise inscribe it on the blockchain. There it will live, irrefutably notarized and timestamped, forever. I explored these ideas in a weeklong side project [3] that only got to cumbersome proof-of-concept stage. [1] https://eth.wiki/json-rpc/API#eth_sign https://eth.wiki/json-rpc/API#eth_sign [2] https://eips.ethereum.org/EIPS/eip-712 https://eips.ethereum.org/EIPS/eip-712 [3] https://github.com/mlin/stakesign https://github.com/mlin/stakesign Footnote: Bitcoin also had an arbitrary-message-signing mechanism -- commonly used on bitcointalk back in the day -- but I think it may now be ~defunct due to not keeping up with the newer address types introduced in recent years.
- Gargyle 5y ago
  Attaching this to cryptoassets increases your operational (more mental overhead, doesnt work with simple keybearer devices, you assume people to be lazy and bad at key management) and technical (irrevocable ethereum-bugs that can only be mitigated by chain splits) complexity. Albeit for long-term public signatures I see the benefit in spreading the sig and revocation information from the classical tools in to as many hard to modify places as possible. Popular global databases like Ethereum and similar are good condidates for that. And of course have the verification scheme expose inconsistencies between different key-sources and tag them with their respective power structure categories. (Lime Government, Cryptocurrency-Devs, HugeCodeHostingPlatform, CompanyBehindHugeCodeHostingPlatform, etc...)
  - 5y ago
cpressland 5y ago
This was a problem I’d really hoped Keybase would solve. Thanks Zoom. Whenever I rebuild my Mac I seem to inexplicably have endless problems getting GPG and Git to play nice. I quite like the idea of using my SSH Keys for this use case as it makes setting this up incredibly simple. I seem to spend a non zero amount of time helping developers and QAs at work setting up SSH Keys for GitHub, I might as well get them to sign commits at the same time now.
loloquwowndueo 5y ago
This has been possible for a long time using a combination of OpenSSL and ssh. To sign: openssl dgst -sha512 -sign ~/.ssh/id_rsa file > file.sig To verify, needs converting the public key (who.pub) to something OpenSSL can grok: ssh-keygen -e -f /tmp/who.pub -m pkcs8 > /tmp/who.openssl.pub Then verify: openssl dgst -sha512 -verify /tmp/who.openssl.pub -signature file.sig file
- stormbrew 5y ago
  What you get with this over monkeying around with openssl (other than having to deal with two tools with awful command line argument UX instead of just one) is that you can use ssh-agent to do the signing, which means you can also use tokens and such.
- riedel 5y ago
  We use openssl to encrypt our passworddb using SSH pub keys. Works nice in scripts. Wonder why we need the new command line.
_wldu 5y ago
Age uses this feature of GitHub, as an example, in the documentation: "Encrypting to a GitHub user Combining SSH key support and -R, you can easily encrypt a file to the SSH keys listed on a GitHub profile. $ curl https://github.com/benjojo.keys https://github.com/benjojo.keys | age -R - example.jpg > example.jpg.age" I also like distributing public keys via DNS TXT records and have written about that some here: https://www.go350.com/posts/age-file-encryption/#age-pki-issues https://www.go350.com/posts/age-file-encryption/#age-pki-iss...
- the8472 5y ago
  That's encryption (recipient key), not signing (sender key). But yeah (r)age is pretty useful for that.
- mlangenberg 5y ago
  Thanks! I was already wondering if this would be possible. Signing data has its uses, but I more often have to transfer sensitive data to other GitHub users and this tool seems really useful for that!
teekert 5y ago
Is it possible to encrypt something with an ssh pubkey and then decrypt with the corresponding privkey? GPG-style?
- Gargyle 5y ago
  That happens as part of the ssh handshake. And is the basis of this whole scheme. No idea if there is tooling to.do.that for arbitrary messages.
- fanf2 5y ago
  Yes, with https://github.com/FiloSottile/age https://github.com/FiloSottile/age
z3t4 5y ago
You could also just hash the file and publish the hash on your web-site which has a HTTPS certificate. Or simply publish the file on your website - no need to sign. My reasoning is that if your website get hacked it wont help if you have signed the file, the hacker could re-sign the files with a new public key.
- dredmorbius 5y ago
  Hashing only shows that a file hasn't been modified since the hash was made. It doesn't indicate who made the hash, if a simple checksum method was used. A cryptographic signature is a hash made using a private key, indicating that only someone with access to that key could create the hash. It asserts both integrity (the contents haven't changed) and authorship. Without the private key, the hash merely indicates access to the content at some prior point in time (which might be otherwise asserted or recorded), but not who had that access.
  - z3t4 5y ago
    For signing to work you need to have the public key of the signer beforehand. If you do not posses their public key it will be impossible to know if the one signing is really the one you think it is. So signing only works if you already have an established relation with the one receiving the data.
    - dredmorbius 5y ago
      You require the public key of the signer when verifying the signature. That needn't be before receiving the message, and could be at any point from now until doomsday. The signature itself verifies: 1. That contents haven't been modified since they were signed. (Integrity.) 2. That a party had access to the private key in order to create the signature. (Authentication) (You're not assured, of course, that others don't also have such access.) Determining the real-world identity of the signer is ... another matter. Though an exchange of content encrypted against their public key, and returned to you, might help establish that. Process and protocol will depend on your own needs, intent, and goals.
lisper 5y ago
It's great that you can do this, but why stuff this functionality into ssh-keygen? A command called ssh-keygen should only do one thing: generate keys. The command for using an ssh key to sign something should be ssh-sign, especially since one of the ostensible design goals here is to get away from PGP's horrible UI.
- stormbrew 5y ago
  ssh-keygen already does a bunch of other stuff, though it all relates to manipulating and using keys. It should probably really be renamed ssh-keytool or something.
lucb1e 5y ago
> SSH public keys are one line strings that are easy to copy around. You don't need to use the Web of Trust PGP public keys you can also just copy around? Nobody is forcing you to use the web of trust with PGP either, if you don't want it. But if you do use keys extensively, it actually helps you: if your boss already verified a customer key, you don't have to re-do the work and meet up in person or ask your boss to send it over before you can use it. Now extend that to a whole network of colleagues, where you configure per-colleague whether you think they properly verify other people's keys, and this whole key distribution problem becomes a lot easier without having to rely on third parties (CA system like with https). Just a small note, this obviously doesn't invalidate the rest of the article!
- kzrdude 5y ago
  On the other hand, it's very easy to "leak" keys into keyservers by one mistaken command with GPG. Maybe you have backup signing keys or whatever secret project encryption keys - and you would prefer for privacy and obscurity that the "public" halves are not distributed on keyservers. In this sense, I think GPG continues the culture of a more naive and smaller internet by thinking that most keys want to have their public part online.
throw7 5y ago
That's cool. I didn't know ssh-keygen could do this, but, to be honest, the UX of gpg is a step better as it manages the "allowed signers" file. Not that ssh-keygen couldn't do that, but it seems to be minimal design (which is fine and right for that tool). Also, article is biased toward pki (vs web of trust) and tries to pass off github as a type of 'cert authority'. ssh signing is 'web of trust' but it leaves the trust implementation totally up to the user. Neither system is "better", the tradeoffs just need to be known and at least pgp implementations will have ux to provide for web of trust.
ezekg 5y ago
I thought it wasn’t advisable to use Ed25519 for signing arbitrary files? It’s at least not advisable to sign large files due to the multi-pass nature of signature generation, per RFC 8032 (sec 8.7). Where do you draw the line on “large”? I’d assume they’re using Ed25519ph (pre-hash) with a context (the -n file namespace), but I can’t find the source for ssh-keygen with a quick search to confirm. But then again, it’s also not advisable to share keys between Ed25519 and Ed25519ph, which the author would be doing...
fishywang 5y ago
I think one problem with using ssh key instead of gpg/pgp key for signing data is key to people mapping, for lack of a better word. I can't speak about others, but for myself I use a single gpg key across all my machines, but I use one ssh key for each of my machine. When I replace a machine with a new one, I don't move/transfer that key to the new machine, I just generate a new key on the new machine and revoke my old key everywhere. To me a ssh key does not map to me, it maps to me and a machine combination. If I use an ssh key to sign something then after a few years I replaced that machine, that key is no longer used anywhere, and the verification can start to become tricky (I'll certainly remove it from my github, which invalidates the key distribution way proposed by the article). I also always use name@machine to name/annotate my ssh keys, but github's name.keys strip that info (for good reasons). So this is probably good for short lived signing needs, but for something that needs to be verified long into the future (git commits/tags), I don't think this is a good idea?
ak217 5y ago
So many people in this discussion talking about how this isn't a true alternative to PGP while ignoring the fact that gnupg and all other PGP software are a giant usability trainwreck. The PGP web of trust is as good as dead, and denialism around the usability issues in gnupg is mostly to blame. If we want people to use a decentralized web of trust solution going forward, it's time to accept the fact that we'll need a new set of clients and usability/accessibility standards.
- Gargyle 5y ago
  SSH tooling does not make that any better tbh. Things are being worked on. Watch Sequoia. Maybe some things regarding UX on my radar will surface in a range of <2 years.
- upofadown 5y ago
  >The PGP web of trust is as good as dead, ... I don't think the thing you are referring to ever actually existed. Just like in real life you would trust someone just because someone you trusted trusted them. This is a common strawman and does not represent some sort of weakness in the relatively straightforward certifications provided by stuff that supports OpenPGP.
  - Gargyle 5y ago
    Cryptographic Trust /= Trust in persons motives. I guess we need better words.
  - ak217 5y ago
    Of course I would trust someone if someone I trusted trusted them - subject to some obvious limitations. That is the essence of a social network. A cryptographic representation of that network is a profoundly powerful concept. But OpenPGP/gnupg are bad tools to represent it.
deleted 5y ago
[deleted]
recursive 5y ago
> And if you use GitHub, or any other service that uses SSH keys for authentication, you already have an SSH key that can be used to generate signatures. Nope. I just checked. I don't.
- deleted 5y ago
  [deleted]
- bogwog 5y ago
  So you enter your username and password every time you git pull/push?
  - frutiger 5y ago
    Or they use a git-credential-helper with a Personal Access Token.
  - recursive 5y ago
    Definitely not. I think I enter it about once per machine.
jedisct1 5y ago
Other tools that can use SSH keys for signatures include: - Minizign: an implementation of Minisign in Zig - Wasmsign: a tool for signing WebAssembly modules
exabrial 5y ago
Great idea: easy key distribution and management. Like most p2p ideas, PGP also sucked at this. Terrifying idea: trusting a third party to maintain the metadata about a key and who's identity it represents. PGP absolutely got this part right: if you modify the contents of the metadata, the hash changes. Basically, if a private key were to point to Myself, and I distributed it widely, then lost it... an attacker who recovered said key could _transparently_ change the identity of the key and we'd have no record of who was actually correct. And lets not pretend that a government couldn't coerce Github to add an ssh identity to your account (it is owned by Microsoft now, and they have DOD contracts to fulfill). Keybase solved both these issues: easy and intuitive, transparent proofs, along with the rigidity of metadata with pgp keys: if a key owner changes, the pgp key mutates.
- cassonmars 5y ago
  > if a key owner changes, the pgp key mutates. How does Keybase address this problem completely? If an attacker gains possession of a key, they don’t have to change ownership, they just assume the role of that user. NB: I know they could feasibly only do this once before the key is considered burned by detection from the original user, so I’m somewhat lost here. Presumably you could mean that revocation of a known stolen key would be easy to point to, but any PKI can handle this. Edit: I’m aware of Keybase itself doing per-device salts, but under a sophisticated attack, I don’t see a workaround here unless they’re doing some multi-party signing process with authorization against the Keybase server who acts as a second party, but even then, a sophisticated attacker who has control of the user’s machine impersonating someone would still be able to circumvent this.
  - exabrial 5y ago
    If you have a PGP key bound to your email: yeehaw@woot.com and you change the email in the key to: haha@yougotserved.com it produces a definitive hash change, while the underlying key material doesn't change. Contrast that to an ssh key, which has no bound metadata. And to your point, both systems in isolation are useless. But the first, combined with proofs and a distribution point like keybase, form a complete system. The second however, ALWAYS relies on a trusted party not doing bad things.
exabrial 5y ago
Also, ssh keys are not really supposed to be portable across devices like an identity is... YOU (a person) could/should have multiple ssh keys. You have the one your laptop, ipad, phone, work, all bound to an identity. You don't want to use the same key across multiple devices or locations. PGP ironically, got this right... and has a nice solution for this, where you can have multiple authentication subkeys tied to a single identity, each individually revokable, plus with key transparency when on is added/removed.
- dredmorbius 5y ago
  A reason SSH proliferation and lack of persistence matter so little is that that traditionally, SSH keys are used for transient session data authentication, encryption, and decryption, not for continued auth/decryption of PERSISTENT data. In the case of SSH, if a key is lost or compromised, no big deal: create a new set of keys and distribute the public key(s) to system(s) for which you wish to authenticate to. There's also no need to use the same key for different remote systems --- you can use specific keys only for a specific remote system (making an adversary's task of determining what remote systems you connect to, based on public keys used on such systems if obtained, a bit harder). The use-case for PGP was meant to be encrypting or authenticating (signing) data which would need to be accessible and/or validated from that point forward. If the sender's public key, or receipient's private key, are not available, valid, or uncompromised at some future time, then the data are either unreliable or unavailable. Using SSH for more durable cryptographic transactions is convenient. But it also changes the use-case and environment around SSH. That will have side-effects.
  - exabrial 5y ago
    ^ Well said
exabrial 5y ago
Also: something that pgp ironically got right: expiration dates. And modification of said dates produces a mutation of your identity... whereas using an ssh key as an identity doesn't have any sort of fetaures.
- stormbrew 5y ago
  ssh keys don't have expiration dates, but ssh certificates do [1]. Which is.. how it should work. A certificate is a declaration of providence of data, a key is not (in itself) that. At any rate, if you want to tell me you actually believe most users of PGP actually properly deal with key rotation and don't just give up and set unreasonably long expiration cycles on their keys or stop using pgp when they first encounter an error about an expired key, I might have a bridge to sell you. [1] See `man ssh-keygen` for the -h and -s arguments and -V for the validity window.
geocar 5y ago
> Since the first three bytes of the SSH protocol signature input are different from the ssh-keygen signature input, the SSH client and ssh-keygen will never produce identical signatures. Therefore, there is no risk of cross-protocol attacks That's not convincing to me. Does anyone have more details on this? It does not seem right to me that a signing protocol secure for similar things would necessarily be secure against random things; A LFR over a long sequence seems like it could be different than a single feedback over random space, and sometimes that difference could be important.
deleted 5y ago
[deleted]
throwaway984393 5y ago
Leaning on SSH to fix the problems in PGP is like trying to rebuild a bridge out of wood because the concrete is cracking. SSH keys were not designed to solve the problems PGP was; it is simply not a functional replacement. It's a stop-gap that will be monkey-patched until we either come up with a better standard, or fork and fix PGP.
xnormal 5y ago
I wrote a tool that lets me use keys in my ssh-agent for google cloud. This way, a vm can run with minimal privileges but when I ssh in I get gcloud cmdline with full control. It is very easy to connect to the agent and ask it to sign something.

637 points by h1x 5y ago

> You'll soon be able to sign Git commits and tags with SSH Once Git 2.34 adds the ability to do this, will Github still show its verified indicator? https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification https://docs.github.com/en/authentication/managing-commit-si...

inopinatus 5y ago

This has long been possible by using the SSH key via the openssl command line, since they're available as PEM. I've relied on that occasionally in provisioning code, albeit specifically using the server key rather than a client identity. Heck, you can even use them for encryption that way. Nevertheless, it's nice to have some more direct support.

aliswe 5y ago

*with ssh-keygen. I'm sure this has been a technical possibility since the dawn of ssh keys themselves.

infogulch 5y ago

Wait, could we use ssh keys as the a federated id? (OIDC?)

dredmorbius 5y ago
Cryptographically, sure, that's always been possible, and it is in fact what SSH affords: if you create an SSH keypair and drop the public half on a remote host, then the corresponding private key serves as your identifier. The crypto part is relatively easy. Ensuring that you've got the right keys on the right hosts is the hard part. E.g.: - If Eve gives Bob a key Eve describes as Alice's but which is in fact Eve's, then Bob is (unwittingly, but cryptographically validly) permitting Eve access. - If Eve can copy Alice's public key from Bob's system to one controlled by Eve, and Alice isn't scrupulous in verifying host keys, then Alice may be tricked into logging into Eve's system (and perhaps divulging further information) when she thinks she's logging into Bob's. - There's the more common problem where Bob permits a login using Alice's key, but that key has been compromised in some fashion by Eve. The cyrptography is putatively valid,[1] but the presumption over identity is not. The PGP "web of trust" model was designed to give some assurance that a key purporting to be Alice, or Bob, or Eve, actually was, and without relying on a central certification authority. It ... mostly kind of worked, but also mostly kind of didn't. Trust itself isn't a cryptographic property. Aspects or indicia of trust may be cryptographically validated. For SSH, the trust aspect has been implied in the key-delivery mechanism. Either the trusted party transmits a key directly to the recipient, or they generate the key from on the recipient's system. Further trust of that key relies on both the crypto implementation remaining valid (see again CVE-2008-0166), and control over the private key and any additional authentication factors (passphrase, physical authentication factors, etc.) remaining uncompromised. There are numerous instances in which private keys and/or passphrases have been compromised. That said, I see some appeal in being able to use, say, SSH keys rather than passwords and other factors to authenticate to websites. In fact there's no need especially to authenticate in the case of content, I need only sign the content which would demonstrated the authenticity of 1) my having signed it and 2) it not being altered since creation. (Say, if dang were to get into the sneaky habit of surruptitiously editing HN comments by other users.) ________________________________ Notes: 1. Or perhaps not, as in the case of CVE-2008-0166, the Debian bug in which time-of-day in seconds was used in key generation resulting in a namespace of only 86,400 keys being possible, a feasibly-brute-forceable space. Those key values are now blacklisted.

chasil 5y ago

You can actually use openssl with RSA keys generated by ssh-keygen to sign also, and this has worked for a long time. https://www.linuxjournal.com/content/flat-file-encryption-openssl-and-gpg https://www.linuxjournal.com/content/flat-file-encryption-op... You will have to generate an openssl-compatible public key: openssl rsa -in ~/.ssh/id_rsa -pubout -out ~/.ssh/id_rsa.pub.openssl To sign: openssl dgst -sha256 -sign ~/.ssh/id_rsa -out known_hosts.sha256 known_hosts To verify: openssl dgst -sha256 -verify ~/.ssh/id_rsa.pub.openssl -signature known_hosts.sha256 known_hosts Here is a little script to automate this: $ cat rsign #!/bin/sh set -eu # http://redsymbol.net/articles/unofficial-bash-strict-mode/ case "$(basename "$0")" in rsign) for n do openssl dgst -sha256 -sign ~/.ssh/id_rsa -out "$n".sha256 "$n" done ;; rchek) for n do printf "$n " openssl dgst -sha256 -verify ~/.ssh/id_rsa.pub.openssl \ -signature "${n}.sha256" "$n" done ;; esac $ cp /etc/passwd /etc/group /etc/hosts . $ ./rsign passwd group hosts $ ls -l *.sha256 -rw-r--r-- 1 luser lgroup 256 Nov 12 13:21 group.sha256 -rw-r--r-- 1 luser lgroup 256 Nov 12 13:21 hosts.sha256 -rw-r--r-- 1 luser lgroup 256 Nov 12 13:21 passwd.sha256 $ ln rsign rchek $ ./rchek passwd group hosts passwd Verified OK group Verified OK hosts Verified OK

agwa 5y ago
A major problem with doing this is that you have to worry about cross-protocol attacks because there is no namespace parameter like there is with SSH signatures. SSH signatures provide the necessary structure to safely use a single key for multiple purposes.
- chasil 5y ago
  It's true, I do remember the DROWN exploit relying upon keys presented over differing protocols. It doesn't take long to generate an RSA key, though. A dedicated signing key would seem to be the obvious thing to do. https://en.wikipedia.org/wiki/DROWN_attack https://en.wikipedia.org/wiki/DROWN_attack

laurent92 5y ago

He’s right, SSH is widespread and easy enough to understand for, at least, programmers. It makes for an excellent tool for signatures. Public keys are easy to upload everywhere. And you pass much less as a nerd as when using PGP.

mherrmann 5y ago
I actually always feel kinda cool when using PGP.
- blitzar 5y ago
  Nerd.
  - rwky 5y ago
    I have my gpg key stored in my yubi keys and use those for SSH so does that make me a super nerd?
    - Ciantic 5y ago
      Probably, I did that too, but I wish I could switch to FiloSottile's age. However age still says in the docs: > SSH keys held on YubiKeys can't be used to decrypt files. So I'm stuck with gpg. I don't want to store my private keys as a file on a computer just to decrypt stuff.
    - errcorrectcode 5y ago
      Only if you use monkeysphere and fwknop.
    - visualphoenix 5y ago
      Same. Imho it’s the best solution we have right now.

matthberg 5y ago

Looking forwards to when this gets added to git in v2.34. Setting up pgp for commit signing is such a pain. Yet since ssh is installed everywhere and I'm using it for git anyways, that's one less setup step to worry about.

elric 5y ago
Is it a pain? At it's most basic, it's just one line of config in .git/config. The hard part is keeping track of historical keys and revocations, so that historical commits can be validated if they were made before (but not after) a revocation. And when that happens, you immediately run into the problem that time information in git offers zero security, and that the whole operation is moot.

kzrdude 5y ago

Apparently "Signing a file is straightforward" heh no, this can not be said to improve upon GPG's interface(*). But it will be cool to see where it can go. (*) Hiding signing behind a command that's called keygen is not the interface we deserve.

dane-pgp 5y ago

> GitHub acts as a trusted third party here, and you have to trust them not to lie about people's public keys, so it may not be appropriate for all use cases. But relying on a trusted third party with a professional security team like GitHub seems like a way better default than PGP's Web of Trust, which was nigh impossible to use. Hopefully that's a false dichotomy and the entire Free Software community doesn't end up reliant on Microsoft to host all our keys for us. The article goes on to mention key transparency, though, which does seem like the right solution. I note that rekor (the transparency log implementation used by sigstore) already supports signing with SSH keys[0], so this TechRepublic article about it[1] from March (which lists only "GPG, x509 and Minisign") is already out of date. [0] https://github.com/sigstore/rekor/blob/main/types.md#ssh https://github.com/sigstore/rekor/blob/main/types.md#ssh [1] https://www.techrepublic.com/article/a-new-linux-foundation-open-source-signing-tool-could-make-secure-software-supply-chains-universal/ https://www.techrepublic.com/article/a-new-linux-foundation-...

IYasha 5y ago
Thanks for the insight and links! And really... > relying on a trusted third party ... like GitHub seems like a way better default than PGP's Web of Trust Made me scream: "What??" I'd personally prefer some decentralized torrent-like way of user key distribution.
- majou 5y ago
  What would that look like? Distributing keys is always the hard part.
  - IYasha 5y ago
    Well, I tried to avoid saying blockchain, which is already being implemented https://hackernoon.com/decentralized-public-key-infrastructure-dpki-what-is-it-and-why-does-it-matter-babee9d88579 https://hackernoon.com/decentralized-public-key-infrastructu... but is resource-heavy. On the second thought, there are potential problems with DHT-like way of distribution (rogue peer overwhelming, etc) I can't seem to find article on this idea (it's pretty old), sorry.

GauntletWizard 5y ago

That's pretty interesting. To some extent, it was possible even before - Support for converting SSH RSA Keys to OpenSSL formats is old old, and you can use those to encrypt/decrypt or sign/verify arbitrary data via the openssl command. In fact, AWS uses this in their Windows instances, to encrypt the Administrator password[1] Definitely will mean some interesting things for Git workflows, though. I've long been in favor of requiring every commit to be signed, and making that easy to enforce either in merges or push hooks. On the other hand, Linus is publicly against it[2], with good reasoning, though I don't think compelling enough reason[3]. Signing every commit would completely break the common pattern of handling merges centrally. Most companies, unlike kernel development, have a centralized server with a "trunk" and code review is done as part of that. Signing every commit with your SSH key would break that model, badly, but it could instead be an opportunity to improve the git tooling. One of my favorite features of the now-defunct Phabricator was that you typically merged your commits with `arc land`, which a) squashed and annotated your merge with the Phabricator code review metadata and b) Deleted your branch. The latter was especially handy, but the former made code review great. Github and Gitlab can do the same as part of their UI, but it would be far better if it were nicely integrated with your existing git workflow, and this would be the opportunity to add prepush hooks to nicely integrate with hosting sites and code review tools. [1]https://docs.aws.amazon.com/cli/latest/reference/ec2/get-password-data.html https://docs.aws.amazon.com/cli/latest/reference/ec2/get-pas... [2]https://web.archive.org/web/20201111174438/http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html#a2583316 https://web.archive.org/web/20201111174438/http://git.661346... - There has to be a better archive of this mailing list than the wayback machine. Searching for this, though, led me to my previous comment[3] [3] https://news.ycombinator.com/item?id=12291462 https://news.ycombinator.com/item?id=12291462

rkeene2 5y ago
Fossil [0] can sign every commit [1] (with GPG or S/MIME) and have merges performed centrally because it never modifies history. Git can probably also do this for certain merge modes ? I'm not very familiar with how this works in Git. [0] https://fossil-scm.org/ https://fossil-scm.org/ [1] https://fossil-scm.org/home/help?cmd=clearsign https://fossil-scm.org/home/help?cmd=clearsign

pizza 5y ago

I get that they're "public" keys, but I was surprised to learn (and from somebody other than github themselves) that ssh public keys are just available at that github.com/username.keys URL (without there being an option to disable it, it seems?). Did most people already know that? Probably fine but just surprised. Just tried searching their authentication docs [0] and I don't get any results for "public key url" either https://docs.github.com/en/authentication?query=public+key+url https://docs.github.com/en/authentication?query=public+key+u...

whirlwin 5y ago
This can be a security risk if you're using the same SSH keypair for other things, and you're using a less secure algorithm than RSA or ED or similar. Anyone doing a bit of research about you might discover a vulnerable host for which the vulnerable algorithm keypair might be targeted
- teekert 5y ago
  When that happens you were relying on security by obscurity. It’s a hack waiting to happen. This, at least creates awareness and forces secure keys. But you are right, it may be a security risk, but only when it already was (arguably it was smaller).
erk__ 5y ago
And similarly GPG keys are at github.com/username.gpg
- giaour 5y ago
  This seems more legit. If a user is signing their commits, other users should have access to their public keys in order to verify the signatures.
  - megous 5y ago
    Usefulness of that access from the same service you're getting the signed commit from is close to nil. Public keys should be distributed in a trustworthy way.

gorgoiler 5y ago

The ssh-agent protocol has always had the ability to sign data. It sounds like the new part is being able to verify signatures without needing the private key. If you give ssh-agent some data and a public key then — if it has the corresponding private key — it will return a signature for your data using that private key. The protocol command is SSH_AGENTC_SIGN_REQUEST and it’s the bread and butter of how the agent does its job. Historically, it’s not tractable for public sign/verify but you can use it as a way to do symmetric encrypt/decrypt with ssh-agent.

IYasha 5y ago
The use of ssh-agent may be forbidden at some places, even on personal machines. I knew a few. And not that it's completely unjustified..
- visualphoenix 5y ago
  How about gpg-agent? Is that forbidden?
  - IYasha 5y ago
    Nobody used or asked about gpg-agent back then ) The point about ssh-agent was that it stored personal keys in memory of machines shared by multiple users (admins, shifters, devs). So everyone had to type in passwords for every "ssh" )
rkeene2 5y ago
It hasn't been able to do it in a meaningful way. I've been patching support for this into ssh-agent for about a decade. I wrote a PKCS#11 module which talks to the SSH agent socket to forward your smartcard [0]. Doing so requires three changes to the protocol: 1. The ability to sign arbitrary data and get back the signed result [1]; normally you get back a hashed result [2]. 2. The ability to decrypt data, this is what you said. This is less important since many things only require signatures (and not all algorithms support encryption/decryption). 3. The ability to request your certificates [3] [4] this one is kinda obvious. The benefits of this are that you can use your smartcard on the remote host to do fully authenticated password-less sudo with pam_pkcs11. You can also do anything else that requires you to use your private key to be used, which can include fetching files (TLS client certificate authentication). Within the US Government, passwords have been being phased out since 2004, but the requirements for authenticated privilege elevation remain. Another way to accomplish this is to use SSH forwarding of your PC/SC socket but that's less portable and more fragile (and even less secure). [0] https://github.com/rkeene/ssh-agent-pkcs11 https://github.com/rkeene/ssh-agent-pkcs11 [1] https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?ln=481-482%20561-563%20573-576 https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?l... [2] https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent-00#section-4.5.1 https://datatracker.ietf.org/doc/html/draft-miller-ssh-agent... [3] https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?ln=296-312 https://cackey.rkeene.org/fossil/artifact/0d0e90bbfdee672c?l... [4] https://datatracker.ietf.org/doc/html/rfc6187#section-2.1 https://datatracker.ietf.org/doc/html/rfc6187#section-2.1

tialaramex 5y ago

This comes with a rationale for why this should be safe re-use of SSH keys, and OpenSSH provides, as you would hope, an explicit namespace mechanism so when fifty people re-use this they don't pollute each other's cryptographic context. In both cases this is unlike Filippo's age - which to me makes it a whole lot more attractive. Its relationship to your identity, contextually ("this is my GitHub key, this is the one for $VolunteerProject servers, and this third one is for my local machines") makes more sense for this purpose than in age too. Signing a git commit with a key you use on gitlab for example.

tptacek 5y ago
This has literally nothing to do with age, which, by deliberate design, doesn't implement signing. What a strange and hostile thing to write.
- tialaramex 5y ago
  You wrote: > This has literally nothing to do with age, which, by deliberate design, doesn't implement signing. What a strange and hostile thing to write. But of course I never claimed age performs signing I wrote that it re-uses SSH keys without a safety rationale. Here's what age actually says about its re-use of SSH keys: "As a convenience feature, age also supports encrypting to ssh-rsa and ssh-ed25519 SSH public keys, and decrypting with the respective private key file." -- https://github.com/FiloSottile/age#ssh-keys https://github.com/FiloSottile/age#ssh-keys So, we see age does in fact re-use SSH keys for this unrelated purpose. And we see that, unlike the OpenSSH feature described in this article, it offers no rationale for why this is safe. Filippo talked about writing such a rationale but ultimately there isn't one provided. Ordinary users shouldn't try to imagine for themselves why something dangerous might be safe. In the absence of a rationale for why re-using your SSH private keys to decrypt age messages is OK, don't do it. The article provides a rationale for OpenSSH's "sign arbitrary data" feature (a briefer one is included in the OpenSSH distribution itself) so that you can assure yourself that this is a reasonable thing to do.
  - akerl_ 5y ago

csomar 5y ago

Ledger/Trezor have solved this since ~2016. I have a Ledger that has a private key inside and using a small open source tool (https://github.com/romanz/trezor-agent https://github.com/romanz/trezor-agent) I can SSH into machines, sign random data and Github commits and FIDO authenticate into several websites. All of that and knowing that these devices offer some of the best security out there.

johnyzee 5y ago
Hardware devices like the crypto wallets are a pretty good solution (no pun intended), imho. Both very convenient and very secure. I like the minimalism of something like the Trezor, no battery, tiny B/W display and two hardware buttons. Plug in, click button to confirm signing, done.
stavros 5y ago
FIDO2 is even better because SSH supports it natively, so there's no setup at all.

dandanua 5y ago

This is awesome and should be more widespread. I always feel embarrassed when I see government systems that use digital signatures infrastructure. Usually, a government website has their own web application through which you input your private key and your password. Sure, usually those applications use standard libraries that do computations locally. But how do I know this? If such a website is hacked – my private key will be exposed.

numair 5y ago
> web application through which you input your private key and your password Sorry, what? Can you point me to some examples, because this sounds so crazy. Why would you ever upload your private key to a server? Sounds like security theatre to me...
- dandanua 5y ago
  The verification is local (through javascript, nowadays). But you can't know this if you're not a hacker that can check it. It's widespread in Ukraine, and I assumed it's similar in other countries. I mean hackers could change the code of the website so that private keys will be uploaded without noticing by users.
  - numair 5y ago
    Ahh yes, now that I think about it, I’ve seen this sort of implementation before: 1. Government forces you to jump through hoops with some collection of favored — sorry, I meant “authorized” — vendors who can issue you a certificate for $WTF (either paid directly or through your taxes...). 2. You are provided with the private key in some manner. Hopefully not in your email, but that’s often what happens. 3. Whenever you want to validate yourself to the service, the government website then has you upload that private key to use in their own homemade implementation of JavaScript PKI. Sometimes they actually take the key from you and send it to their server to do the work. ... I think we are both in agreement that this is pretty lousy. And if you’re seeing it in Ukraine, it’s a world-wide “security” model. Maybe someone else here on HN can explain the thinking that went into these sorts of implementations...

jatone 5y ago

this was always possible.... ssh just didn't do it. but you absolutely could use your key to sign data.

kybernetyk 5y ago

So a little offtopic but I’m still curious: how do you handle multiple machines and SSH keys? I mean do you run ssh-keygen on a new machine and have for each computer a separate key pair or do you have one key pair that you copy on every new machine? I have seen both and using one key pair looks very convenient but also makes me feel a little uneasy. I myself have a key pair for each of my machines. How do you handle it?

rkeene2 5y ago
I use two keypairs, but with no ability to read the private key (smartcard).
- visualphoenix 5y ago
  This is what I do as well. Yubikey configured as a smartcard running gpg-agent with enable-ssh-support.
Hendrikto 5y ago
I have one key pair per machine and service. About 20 pairs on my laptop, 15 on my desktop.
adrian_b 5y ago
You can avoid specifying a lot of parameters at each SSH connection by defining aliases, e.g. of the form ssh-servername. In each alias you put the appropriate "-i private_key_for_that_server", the server name and also "-l user_name" if you have a different user there and "-p port" if the server uses a non-standard port. Thus, after the initial key setup, connecting to any server with different credentials is no more complex than when using a single key pair. Except for an extra keygen step, the initial setup is not more complex than when using a single key pair, as you have to copy the public keys anyway, which is the more difficult part of the setup.
- theli0nheart 5y ago
  You might want to look into using .ssh/config instead, as it is built into SSH. In addition to letting you specify keys/usernames for arbitrary hosts, you can also use rules for wildcards, etc.

rvdginste 5y ago

Regarding PGP's 'Web of Trust', I thought the purpose of this was to validate the link between the key and the owner of that key. This is not what you get from retrieving a public key from github... that only gives you the link between that key and a github account. But what does that give you? From what I understand, it gives you nothing for anything that is signed and that does not have a direct link to a github account. Obviously, if someone releases software on that github account and I find a signed release of that software, I can validate that it really was signed by the official source of that software on github. For anything that does not have that direct link, it really does not give you anything. I've never used PGP, but I thought the web of trust was used to validate metadata on the key and that this can be used to validate that a key really belongs to the person that you think it belongs to. I saw it more like how you have SSL certificates with different degrees of validation and where you must deliver more proof of your identity if you want to receive a certification with a higher degree of validation. I'm all for using SSH keys for signing, but I still would like to have something like PGP's web of trust for those keys.

kenmacd 5y ago
I agree, but I think it's pretty clear that web-of-trust has failed. There may be 6 or fewer degrees of separation between us, but the chance that there's a path of people that actually validate and sign keys isn't very high. As an alternative keybase.io worked well. If you knew the person controlling the github account also controlled the mastodon/twitter where you talked to them, and the website/blog, etc, then you can be pretty sure it's them. (I saw mention of more open systems here too https://news.ycombinator.com/item?id=29132024 https://news.ycombinator.com/item?id=29132024). > I'm all for using SSH keys for signing, but I still would like to have something like PGP's web of trust for those keys. same here. I use my gpg key for ssh (stored on a yubikey). Seems like a better option to me.
- notatoad 5y ago
  i think the main assumption that keybase makes is an important one: you don't need to link a key to a person, you need to link it to an identity. and a github page or a twitter account is an identity. the IRL identity of the person controlling that web identity can be considered out of scope. if you do need to link a key to an actual non-digital person, then you've got a whole different set of problems.

Tepix 5y ago

We've come full circle then: https://medium.com/@chrispisano/ssh-authentication-with-gpg-411676781647 https://medium.com/@chrispisano/ssh-authentication-with-gpg-... TL;DR: Use the same key in GPG and SSH by it exporting out of GPG into SSH gpg --export-ssh-key

errcorrectcode 5y ago
monkeysphere manages ssh keys in gpg and also communicating with ssh-agent (or gpg-agent).

alecco 5y ago

Please consider donating to the OpenBSD Foundation (OpenSSH project) https://www.openbsd.org/donations.html https://www.openbsd.org/donations.html

stavros 5y ago

Is this the same AGWA that made git-crypt? I look forward to being able to encrypt the repo key to SSH keys, rather than GPG ones.

hardwaresofton 5y ago
Yes it is, and they are awesome. git-crypt[0] is a godsend for smaller projects (and maybe larger ones if permissions are granular enough) -- way simpler than sops[1] and other alternative, with native integration via git filters (smudge). I use it on a ton of projects. [0]: https://www.agwa.name/projects/git-crypt/ https://www.agwa.name/projects/git-crypt/ [1]: https://github.com/mozilla/sops https://github.com/mozilla/sops
- stavros 5y ago
  Same, I love it. The GPG bit is the only inconvenient part.

yewenjie 5y ago

Is it a good practice to use only one SSH key pair or different pairs for different things? Also, how do people usually store SSH keys for long term?

elric 5y ago
I use a different key pair for every service. Where "service" is defined pretty loosely. All the company servers I access for work, for instance, use the same key pair. But I have different key pairs for github, gitlab, etc. I also have a work github account for FOSS contributions, which uses a different key pair than my personal github account. I have a config file per identity (work, personal, second job, etc) in ~/.git/config_$identity. Each of those files contains a Host entry with key configuration for every service I use. I rely on a bit of shell foo to to select the correct identity (an environment variable and an alias). Life would be a bit easier if ssh_config supported the use of variables in Include statements, that way I could just Include ~/config_${identity}. Oh well.

upofadown 5y ago

>Here's why I like SSH signatures: >* It's not PGP. The most important reason people use the OpenPGP message format is because it is a well accepted standard. Sure the cryptography is not new and fun but it is secure. If you sign something with OpenPGP then you can be sure that those signatures are verifiable on any platform by anyone. The OpenPGP standard has provisions to ensure that the signatures are from a particular entity. This proposal suggests that Github could be treated as a trusted third party. If that is the case then you don't need signatures at all. Obligatory "The PGP Problem" rebuttal: * https://articles.59.ca/doku.php?id=pgpfan:tpp https://articles.59.ca/doku.php?id=pgpfan:tpp

geofft 5y ago
> The OpenPGP standard has provisions to ensure that the signatures are from a particular entity. No, it does not - it has provisions to ensure that the signatures are from a particular private key. Mapping that to a human-meaningful entity is beyond the scope of the OpenPGP specification. The article you link does not really address that point, and it doesn't at all substantiate the claim that using GitHub as a trusted third party means you "don't need signatures at all". (Also, the original post says that other means like key transparency can be used instead of trusting GitHub.)
- shp0ngle 5y ago
  Well, if you trust github enough for the keys, you can just download and distribute the arbitrary data through github itself. I guess that is what he was referring to.
- zucker42 5y ago
  Isn't the web of trust part of a PGP? That maps private keys to human-meaningful entities. Or is that not part of OpenPGP?
  - int_19h 5y ago
    The argument is that the whole "web of trust" thing never really took off, so you can't rely on it in practice.

reidrac 5y ago

Verifying signatures is messy, because the SSH keys don't store identity information, isn't it? So basically you know that an specific SSH key signed a file, but that's all you know. Not very useful? Who's going to maintain a file with allowed signers per key?

fstelzer 5y ago
Correct. Linking an identity to the crypto signature is the hard part for every mechanism. Regarding the allowed signers file you have several options: A repository only allows signed commits / merges / pushes and simply stores the file in the repo itself. If you already rely on forges like github/gitlab/... and trust them to generate a file for you (e.g. from the users ssh keys having write access to the repo). You maintain this file independently for yourself with a "Trust on first use" mechanism (which will follow in a future patch to git) A git patch currently in progress will utilize the valid-after/before options that you can set on keys in this file to verify the commits/tags with keys valid at the time of the objects creation. This will allow for key rollover and still being able to verify old signatures. (Theres also the revoke file which will invalidate all signatures for a key). In addition to that a "trust on first use" patch will follow that can automatically add new keys with the committers ident to this file (unless the ident is already present with a different key of course, which should error badly). disclaimer: i wrote the git integration for this

oedmarap 5y ago

Slightly related, but I use age[0] for most of my non-automated file encryption tasks; and one of the neat features it has is the ability to encrypt to a GitHub user's pubkey[1]. [0] https://github.com/FiloSottile/age https://github.com/FiloSottile/age [1] https://github.com/FiloSottile/age#encrypting-to-a-github-user https://github.com/FiloSottile/age#encrypting-to-a-github-us...

fstelzer 5y ago

I think one of the most compelling reasons of using ssh for signatures is the possibilies of ssh-agent and especially agent-forwarding which allow for incredibly portable workflows like ssh to a ci/build host/container to sign some production binary/container/tag. Please note that these come with their own pitfalls and precautions you'll need to take to ensure your key's safety! If you consider agent forwarding i'd recommend use of "ssh-add -c" to have your agent at least confirm every use of your private key. Generally for private key security i'd always use a hardware token. Modern yubikeys are really easy to use and you can even enable touch policy instead of the agent confirmation. The UX for this is still a bit lacking in the tooling though.

dnamlin 5y ago

Ethereum has standardized ways to formulate (off-chain) signatures for arbitrary messages [1] and Solidity structs [2]. Convenient command-line tooling is lacking currently, but some interesting twists to consider: If you sign using a key that also controls cryptoassets, then you're incentivized to keep the key safe and secure indefinitely. Contrast with tendency to lose GPG and SSH keys after losing interest for a few years, changing jobs, etc. Moreover, consider key revocation. The revocation mechanisms for GPG and SSH keys are not that effective, due to impracticality of publishing your revocation in a way that really ensures subsequent verifiers are alarmed. If only there were some sort of decentralized, permissionless, globally-replicated database which verifiers could check for that information... More generally if you have a really important signature to publish, you can mint an NFT for it or otherwise inscribe it on the blockchain. There it will live, irrefutably notarized and timestamped, forever. I explored these ideas in a weeklong side project [3] that only got to cumbersome proof-of-concept stage. [1] https://eth.wiki/json-rpc/API#eth_sign https://eth.wiki/json-rpc/API#eth_sign [2] https://eips.ethereum.org/EIPS/eip-712 https://eips.ethereum.org/EIPS/eip-712 [3] https://github.com/mlin/stakesign https://github.com/mlin/stakesign Footnote: Bitcoin also had an arbitrary-message-signing mechanism -- commonly used on bitcointalk back in the day -- but I think it may now be ~defunct due to not keeping up with the newer address types introduced in recent years.

Gargyle 5y ago
Attaching this to cryptoassets increases your operational (more mental overhead, doesnt work with simple keybearer devices, you assume people to be lazy and bad at key management) and technical (irrevocable ethereum-bugs that can only be mitigated by chain splits) complexity. Albeit for long-term public signatures I see the benefit in spreading the sig and revocation information from the classical tools in to as many hard to modify places as possible. Popular global databases like Ethereum and similar are good condidates for that. And of course have the verification scheme expose inconsistencies between different key-sources and tag them with their respective power structure categories. (Lime Government, Cryptocurrency-Devs, HugeCodeHostingPlatform, CompanyBehindHugeCodeHostingPlatform, etc...)
- 5y ago

cpressland 5y ago

This was a problem I’d really hoped Keybase would solve. Thanks Zoom. Whenever I rebuild my Mac I seem to inexplicably have endless problems getting GPG and Git to play nice. I quite like the idea of using my SSH Keys for this use case as it makes setting this up incredibly simple. I seem to spend a non zero amount of time helping developers and QAs at work setting up SSH Keys for GitHub, I might as well get them to sign commits at the same time now.

loloquwowndueo 5y ago

This has been possible for a long time using a combination of OpenSSL and ssh. To sign: openssl dgst -sha512 -sign ~/.ssh/id_rsa file > file.sig To verify, needs converting the public key (who.pub) to something OpenSSL can grok: ssh-keygen -e -f /tmp/who.pub -m pkcs8 > /tmp/who.openssl.pub Then verify: openssl dgst -sha512 -verify /tmp/who.openssl.pub -signature file.sig file

stormbrew 5y ago
What you get with this over monkeying around with openssl (other than having to deal with two tools with awful command line argument UX instead of just one) is that you can use ssh-agent to do the signing, which means you can also use tokens and such.
riedel 5y ago
We use openssl to encrypt our passworddb using SSH pub keys. Works nice in scripts. Wonder why we need the new command line.

_wldu 5y ago

Age uses this feature of GitHub, as an example, in the documentation: "Encrypting to a GitHub user Combining SSH key support and -R, you can easily encrypt a file to the SSH keys listed on a GitHub profile. $ curl https://github.com/benjojo.keys https://github.com/benjojo.keys | age -R - example.jpg > example.jpg.age" I also like distributing public keys via DNS TXT records and have written about that some here: https://www.go350.com/posts/age-file-encryption/#age-pki-issues https://www.go350.com/posts/age-file-encryption/#age-pki-iss...

the8472 5y ago
That's encryption (recipient key), not signing (sender key). But yeah (r)age is pretty useful for that.
mlangenberg 5y ago
Thanks! I was already wondering if this would be possible. Signing data has its uses, but I more often have to transfer sensitive data to other GitHub users and this tool seems really useful for that!

teekert 5y ago

Is it possible to encrypt something with an ssh pubkey and then decrypt with the corresponding privkey? GPG-style?

Gargyle 5y ago
That happens as part of the ssh handshake. And is the basis of this whole scheme. No idea if there is tooling to.do.that for arbitrary messages.
fanf2 5y ago
Yes, with https://github.com/FiloSottile/age https://github.com/FiloSottile/age

z3t4 5y ago

You could also just hash the file and publish the hash on your web-site which has a HTTPS certificate. Or simply publish the file on your website - no need to sign. My reasoning is that if your website get hacked it wont help if you have signed the file, the hacker could re-sign the files with a new public key.

dredmorbius 5y ago
Hashing only shows that a file hasn't been modified since the hash was made. It doesn't indicate who made the hash, if a simple checksum method was used. A cryptographic signature is a hash made using a private key, indicating that only someone with access to that key could create the hash. It asserts both integrity (the contents haven't changed) and authorship. Without the private key, the hash merely indicates access to the content at some prior point in time (which might be otherwise asserted or recorded), but not who had that access.
- z3t4 5y ago
  For signing to work you need to have the public key of the signer beforehand. If you do not posses their public key it will be impossible to know if the one signing is really the one you think it is. So signing only works if you already have an established relation with the one receiving the data.
  - dredmorbius 5y ago
    You require the public key of the signer when verifying the signature. That needn't be before receiving the message, and could be at any point from now until doomsday. The signature itself verifies: 1. That contents haven't been modified since they were signed. (Integrity.) 2. That a party had access to the private key in order to create the signature. (Authentication) (You're not assured, of course, that others don't also have such access.) Determining the real-world identity of the signer is ... another matter. Though an exchange of content encrypted against their public key, and returned to you, might help establish that. Process and protocol will depend on your own needs, intent, and goals.

lisper 5y ago

It's great that you can do this, but why stuff this functionality into ssh-keygen? A command called ssh-keygen should only do one thing: generate keys. The command for using an ssh key to sign something should be ssh-sign, especially since one of the ostensible design goals here is to get away from PGP's horrible UI.

stormbrew 5y ago
ssh-keygen already does a bunch of other stuff, though it all relates to manipulating and using keys. It should probably really be renamed ssh-keytool or something.

lucb1e 5y ago

> SSH public keys are one line strings that are easy to copy around. You don't need to use the Web of Trust PGP public keys you can also just copy around? Nobody is forcing you to use the web of trust with PGP either, if you don't want it. But if you do use keys extensively, it actually helps you: if your boss already verified a customer key, you don't have to re-do the work and meet up in person or ask your boss to send it over before you can use it. Now extend that to a whole network of colleagues, where you configure per-colleague whether you think they properly verify other people's keys, and this whole key distribution problem becomes a lot easier without having to rely on third parties (CA system like with https). Just a small note, this obviously doesn't invalidate the rest of the article!

kzrdude 5y ago
On the other hand, it's very easy to "leak" keys into keyservers by one mistaken command with GPG. Maybe you have backup signing keys or whatever secret project encryption keys - and you would prefer for privacy and obscurity that the "public" halves are not distributed on keyservers. In this sense, I think GPG continues the culture of a more naive and smaller internet by thinking that most keys want to have their public part online.

throw7 5y ago

That's cool. I didn't know ssh-keygen could do this, but, to be honest, the UX of gpg is a step better as it manages the "allowed signers" file. Not that ssh-keygen couldn't do that, but it seems to be minimal design (which is fine and right for that tool). Also, article is biased toward pki (vs web of trust) and tries to pass off github as a type of 'cert authority'. ssh signing is 'web of trust' but it leaves the trust implementation totally up to the user. Neither system is "better", the tradeoffs just need to be known and at least pgp implementations will have ux to provide for web of trust.

ezekg 5y ago

I thought it wasn’t advisable to use Ed25519 for signing arbitrary files? It’s at least not advisable to sign large files due to the multi-pass nature of signature generation, per RFC 8032 (sec 8.7). Where do you draw the line on “large”? I’d assume they’re using Ed25519ph (pre-hash) with a context (the -n file namespace), but I can’t find the source for ssh-keygen with a quick search to confirm. But then again, it’s also not advisable to share keys between Ed25519 and Ed25519ph, which the author would be doing...

fishywang 5y ago

I think one problem with using ssh key instead of gpg/pgp key for signing data is key to people mapping, for lack of a better word. I can't speak about others, but for myself I use a single gpg key across all my machines, but I use one ssh key for each of my machine. When I replace a machine with a new one, I don't move/transfer that key to the new machine, I just generate a new key on the new machine and revoke my old key everywhere. To me a ssh key does not map to me, it maps to me and a machine combination. If I use an ssh key to sign something then after a few years I replaced that machine, that key is no longer used anywhere, and the verification can start to become tricky (I'll certainly remove it from my github, which invalidates the key distribution way proposed by the article). I also always use name@machine to name/annotate my ssh keys, but github's name.keys strip that info (for good reasons). So this is probably good for short lived signing needs, but for something that needs to be verified long into the future (git commits/tags), I don't think this is a good idea?

ak217 5y ago

So many people in this discussion talking about how this isn't a true alternative to PGP while ignoring the fact that gnupg and all other PGP software are a giant usability trainwreck. The PGP web of trust is as good as dead, and denialism around the usability issues in gnupg is mostly to blame. If we want people to use a decentralized web of trust solution going forward, it's time to accept the fact that we'll need a new set of clients and usability/accessibility standards.

Gargyle 5y ago
SSH tooling does not make that any better tbh. Things are being worked on. Watch Sequoia. Maybe some things regarding UX on my radar will surface in a range of <2 years.
upofadown 5y ago
>The PGP web of trust is as good as dead, ... I don't think the thing you are referring to ever actually existed. Just like in real life you would trust someone just because someone you trusted trusted them. This is a common strawman and does not represent some sort of weakness in the relatively straightforward certifications provided by stuff that supports OpenPGP.
- Gargyle 5y ago
  Cryptographic Trust /= Trust in persons motives. I guess we need better words.
- ak217 5y ago
  Of course I would trust someone if someone I trusted trusted them - subject to some obvious limitations. That is the essence of a social network. A cryptographic representation of that network is a profoundly powerful concept. But OpenPGP/gnupg are bad tools to represent it.

deleted 5y ago

[deleted]

recursive 5y ago

> And if you use GitHub, or any other service that uses SSH keys for authentication, you already have an SSH key that can be used to generate signatures. Nope. I just checked. I don't.

deleted 5y ago
[deleted]
bogwog 5y ago
So you enter your username and password every time you git pull/push?
- frutiger 5y ago
  Or they use a git-credential-helper with a Personal Access Token.
- recursive 5y ago
  Definitely not. I think I enter it about once per machine.

jedisct1 5y ago

Other tools that can use SSH keys for signatures include: - Minizign: an implementation of Minisign in Zig - Wasmsign: a tool for signing WebAssembly modules

exabrial 5y ago

Great idea: easy key distribution and management. Like most p2p ideas, PGP also sucked at this. Terrifying idea: trusting a third party to maintain the metadata about a key and who's identity it represents. PGP absolutely got this part right: if you modify the contents of the metadata, the hash changes. Basically, if a private key were to point to Myself, and I distributed it widely, then lost it... an attacker who recovered said key could _transparently_ change the identity of the key and we'd have no record of who was actually correct. And lets not pretend that a government couldn't coerce Github to add an ssh identity to your account (it is owned by Microsoft now, and they have DOD contracts to fulfill). Keybase solved both these issues: easy and intuitive, transparent proofs, along with the rigidity of metadata with pgp keys: if a key owner changes, the pgp key mutates.

cassonmars 5y ago
> if a key owner changes, the pgp key mutates. How does Keybase address this problem completely? If an attacker gains possession of a key, they don’t have to change ownership, they just assume the role of that user. NB: I know they could feasibly only do this once before the key is considered burned by detection from the original user, so I’m somewhat lost here. Presumably you could mean that revocation of a known stolen key would be easy to point to, but any PKI can handle this. Edit: I’m aware of Keybase itself doing per-device salts, but under a sophisticated attack, I don’t see a workaround here unless they’re doing some multi-party signing process with authorization against the Keybase server who acts as a second party, but even then, a sophisticated attacker who has control of the user’s machine impersonating someone would still be able to circumvent this.
- exabrial 5y ago
  If you have a PGP key bound to your email: yeehaw@woot.com and you change the email in the key to: haha@yougotserved.com it produces a definitive hash change, while the underlying key material doesn't change. Contrast that to an ssh key, which has no bound metadata. And to your point, both systems in isolation are useless. But the first, combined with proofs and a distribution point like keybase, form a complete system. The second however, ALWAYS relies on a trusted party not doing bad things.

exabrial 5y ago

Also, ssh keys are not really supposed to be portable across devices like an identity is... YOU (a person) could/should have multiple ssh keys. You have the one your laptop, ipad, phone, work, all bound to an identity. You don't want to use the same key across multiple devices or locations. PGP ironically, got this right... and has a nice solution for this, where you can have multiple authentication subkeys tied to a single identity, each individually revokable, plus with key transparency when on is added/removed.

dredmorbius 5y ago
A reason SSH proliferation and lack of persistence matter so little is that that traditionally, SSH keys are used for transient session data authentication, encryption, and decryption, not for continued auth/decryption of PERSISTENT data. In the case of SSH, if a key is lost or compromised, no big deal: create a new set of keys and distribute the public key(s) to system(s) for which you wish to authenticate to. There's also no need to use the same key for different remote systems --- you can use specific keys only for a specific remote system (making an adversary's task of determining what remote systems you connect to, based on public keys used on such systems if obtained, a bit harder). The use-case for PGP was meant to be encrypting or authenticating (signing) data which would need to be accessible and/or validated from that point forward. If the sender's public key, or receipient's private key, are not available, valid, or uncompromised at some future time, then the data are either unreliable or unavailable. Using SSH for more durable cryptographic transactions is convenient. But it also changes the use-case and environment around SSH. That will have side-effects.
- exabrial 5y ago
  ^ Well said

exabrial 5y ago

Also: something that pgp ironically got right: expiration dates. And modification of said dates produces a mutation of your identity... whereas using an ssh key as an identity doesn't have any sort of fetaures.

stormbrew 5y ago
ssh keys don't have expiration dates, but ssh certificates do [1]. Which is.. how it should work. A certificate is a declaration of providence of data, a key is not (in itself) that. At any rate, if you want to tell me you actually believe most users of PGP actually properly deal with key rotation and don't just give up and set unreasonably long expiration cycles on their keys or stop using pgp when they first encounter an error about an expired key, I might have a bridge to sell you. [1] See `man ssh-keygen` for the -h and -s arguments and -V for the validity window.

geocar 5y ago

> Since the first three bytes of the SSH protocol signature input are different from the ssh-keygen signature input, the SSH client and ssh-keygen will never produce identical signatures. Therefore, there is no risk of cross-protocol attacks That's not convincing to me. Does anyone have more details on this? It does not seem right to me that a signing protocol secure for similar things would necessarily be secure against random things; A LFR over a long sequence seems like it could be different than a single feedback over random space, and sometimes that difference could be important.

deleted 5y ago

[deleted]

throwaway984393 5y ago

Leaning on SSH to fix the problems in PGP is like trying to rebuild a bridge out of wood because the concrete is cracking. SSH keys were not designed to solve the problems PGP was; it is simply not a functional replacement. It's a stop-gap that will be monkey-patched until we either come up with a better standard, or fork and fix PGP.

xnormal 5y ago

I wrote a tool that lets me use keys in my ssh-agent for google cloud. This way, a vm can run with minimal privileges but when I ssh in I get gcloud cmdline with full control. It is very easy to connect to the agent and ask it to sign something.