3

Are there any advantages to using SSH keys vs. a PAT when interacting with a site like Github?

Github claims SSH keys are a way to not have to enter your username + password (personal access token) with every interaction, however, my Keychain manager takes care of storing my personal access token and I'm not prompted again to login.

So ... why bother with SSH vs just having the PAT in my Keychain? Is it more secure? Is it that PATs are more easily compromised?

chicks
  • 145
  • 1
  • 6
stk1234
  • 142
  • 5

1 Answers1

4

SSH keys work by showing you can encrypt a secret that can be decrypted by your public key.

So your key never leaves your machine.

Unlike a PAT, which you transmit with each request.

Which makes stealing a PAT a lot easier than stealing a key. (Incidentally, you can use a ssh-agent to store your keys for you.).

As to the granularity, deploy keys and group keys exist for a reason. But you have indeed more control with PAT’s there. In my view the SSH keys better security profile outweighs the benefits of granularity control of using PATs.

Adam Katz
  • 9,718
  • 2
  • 22
  • 44
LvB
  • 8,217
  • 1
  • 26
  • 43
  • Aren't public keys generally used for encryption and private keys for decryption? – stk1234 Jul 16 '22 at 23:27
  • Depends in what type of key it exactly is. But in general both sides have public and private keys. How does it matter anyways? PAT’s don’t have this as a feature. – LvB Jul 16 '22 at 23:45
  • 1
    Signing is not the same as encrypting with the private key and decrypting with the public key. The mathematical operations happen to be the same in textbook RSA, but RSA isn't the only signature scheme and signing is fundamentally different from encryption. Describing signing as encrypting with the private key is incorrect and confuses people for no reason. – eesiraed Jul 19 '22 at 02:21
  • @eesiraed who is talking about signing here? And the way the SSH protocol works, you encrypt a received nonce (and add a second one of yourself). Not sign it. If you just signed it the data wouldn’t be protected from snooping. – LvB Jul 19 '22 at 07:17
  • You're talking about client authentication using public keys, right? In that case, the client sends a signature to the server to prove that it has the private key. Confidentiality is provided by a separate protocol layer. – eesiraed Jul 20 '22 at 02:09
  • @eesiraed we are talking about SSH here. And as far as I understand ssh, it doesn’t work as how you described it here. – LvB Jul 20 '22 at 09:36
  • 1
    Public key client authentication is specified in [RFC 4252 section 7](https://www.rfc-editor.org/rfc/rfc4252.html#section-7) and the protocol architecture is specified in [RFC 4251](https://www.rfc-editor.org/rfc/rfc4251#section-1). Decryption with the public key makes no sense since encryption is supposed to provide confidentiality and the public key is not secret. – eesiraed Jul 21 '22 at 18:18
  • 1
    @LvB: it sounds like you're talking about SSHv1, which did use the keypair for encrypting a nonce if I remember correctly (and which is also extremely obsolete), but in sshv2 I'm very sure that the keypairs are used exclusively for signing only. The public key encryption isn't what protects data from snooping, the entirely separate DH key exchange is what does. – user1686 Jul 21 '22 at 21:23
  • It seems it depends. RFC 4252 mainly talks about the signature and uses the already encrypted tunnel for transmission. I don’t remember if what I said earlier was for ssh 1 specifically. Regardless, for SSH 2 the tunnel is made before this step and the verification is done through signature. So I am leaning towards giving you being correct here. It’s has no impact on the initial question though. But I will try and be clearer in the future when talking about encryption Vs signing. – LvB Jul 26 '22 at 15:52