SSH in AWS vs SSH on GitHub [closed]

Question

This is not much of a technical but more of a practical question.

Both in AWS-EC2 instance and GitHub repos I had to generate a cryptographic key pair to encrypt data sent over SSH tunnel.

For AWS the public key is on the remote computer, and the private .pem key in mine. (my understanding of it). They keys are generated on AWS and you just download the .pem file.

I guess AWS runs a key-pair generation algorithm too, but this is all UI guided.

Even though both use SSH, for GitHub it's quite different, and I can see both private and public key locally. In this case we generate them using

1. Generate: ssh-keygen -t ed25519 -C "your_email@example.com"

This seems to be a new asymmetric algorithm/cipher, and before you use RSA

2. Load the private key somewhere eval "$(ssh-agent -s)" && ssh-add ~/.ssh/id_ed25519
3. Paste the public key on GitHub.

Probably both work the same, when my computer creates a request, they send data encrypted with the public key (maybe their own public key at first), and if this is the right computer, then it has the private key to open it.

But apart from this basic idea, why this 2 approaches seem to be so different even though the protocol is the same?

Also, if I'm not mistaken, AWS does not ask for a passphrase.

Answer 1

SSH works exactly the same way when logging in to an EC2 instance in AWS and when logging in to a git repo on github.

cryptography mumbo-jumbo

SSH is an old protocol from the 90s. Like SSL/TLS and IPSec, it has evolved since the 90s and the default (and even "must-implement") cipher suites from the 90s are no longer a good idea and should not be supported.

Everyone has converged on X25519-Ed25519-ChaCha20-Poly1305 as the best default cipher suite, with the following options/fallbacks:

1. AES-GCM used instead of ChaPoly in case your device has hardware AES and CLMUL instructions and you care about the difference between 1.7GB/s and 4.8GB/s (per core)

2. ECDHE over NIST P-256 instead of X25519 if you don't support X25519

3. RSA-PSS (with 2048, 3072 or 4096 bits) instead of Ed25519 if you don't support Ed25519

4. RSA-PKCS#1v1.5 (with 2048, 3072 or 4096 bits) instead of RSA-PSS if you don't support RSA-PSS

TL;DR: If you use a recent (8.x) version of openssh on the server and on the client, you don't need to worry about any of this - the defaults are fine. The latest version (>=0.74) of putty is also ok.

SSH host keys

EC2 will generate new host key for a new VM and you will need to use TOFU with the ssh host key.

Github doesn't create a new server for you, so it has published long term SSH host keys which you should verify when first connecting to github.

SSH user keys

In both cases (EC2 and github) you should generate the user keypair yourself on your own computer using ssh-keygen (or puttygen or equivalent) and upload the public key to the server that will authenticate you, either in the openssh authorized_keys format or in the PEM format (they carry the same data).

In AWS EC2, the option to generate your own user SSH keypair is present ("choose an existing key pair" and then use a public key you have previously uploaded), but it also has the option to let AWS generate a new SSH keypair for you, let you download it as a PEM file, and then use it (puttygen can import it to convert to a putty--format private key, and openssh can decode it and let you see the private key values, if you want). AWS might say: if you don't trust AWS with that key, why do you trust them with the VM?

But there are risks:

1. You might be tempted to use the same keypair for other things (like github), and if so then AWS has access to your account at github.

2. AWS might leak the private key it generated for you, though they should delete it after you download it.

Well, you shouldn't use that option - there is no need. The risks are real, while the benefits are non-existent. Just generate a keypair on your laptop and upload the public key to AWS.