AWS provides access to EC2 by downloading the private key(.pem) into management host that connects to EC2.

AWS uses openssl tool

Key providers generally provide public key but not private key, because with keypairs, one can encrypt either with public key or private key and decrypt with other key, as shown below:

$ openssl genrsa -out mykey 2048

$ cp mykey privatekey

$ openssl rsa -in mykey -pubout -out publickey 

$ rm mykey

$ # Encrypt with public key

$ echo "the cat sat on the mat" | open ssl rsautl -encrypt -pubin -inkey publickey > ciphertxt

$ # cat cipher.txt

$ # cat cipher.txt | openssl rsautl -decrypt -inkey privatekey 

1) Why AWS distributes private key instead of public key? for secure communication...

2) Key pair is mainly to secure communication on the wire, but not authenticate user, to access a resource in AWS.

ssh -i something.pem user@ec2-public-dns-name

How does distribution of a key solve authentication problem? key can be stolen by any wrong person...Why AWS allow ssh login to EC2 without a password?

  • A password can also be stolen, and is easier to guess or attack in other ways than a cryptographic key.
    – john doe
    Nov 14, 2019 at 18:00
  • @johndoe Am not saying that password is a preferred auhentication method, but for sure, private/public key pair does not solve authentication problem. key distribution problem need to be addressed, before making private/publis key as solution for authenticattion Nov 14, 2019 at 18:07
  • SSH uses the private key to authenticate the client to the server, that's why you get the private key from AWS. Key distribution is addressed by you generating private/public keypair on a trusted device and sending only the public key to AWS instead of generating them on AWS.
    – user
    Nov 14, 2019 at 18:19
  • @user trusted device? you can create key pair using AWS in cyber cafe and download the private key. Nov 14, 2019 at 18:20
  • @overexchange If you create the keypair with AWS then AWS has your private key. I thought this was the key distribution issue you were asking about in the question? You want to generate the private key on the device that will be using it, not transfer the private key after creating it on a different device.
    – user
    Nov 14, 2019 at 18:22

3 Answers 3


1) Why AWS distributes private key instead of public key? for secure communication...

Without the private key, you cannot prove you are the owner of the public key. Without proving you are the owner, you cannot use SSH Public Key Authentication.

So Amazon generates a key itself, and send you. If you don't trust Amazon, you can create another key, put the public key on authorized_keys and delete the former one.

2) Key pair is mainly to secure communication on the wire, but not authenticate user, to access a resource in AWS.

Not quite. Key pair can surely be used for authentication too. If you sign some data with your private key, someone (or some system) can use your public key to see if you are indeed the one signing the data.

The oversimplification of SSH key authentication is something like this: the client sends the server the key he wants to use to authenticate. If the server have that key on its authorized_keys file, it will generate a random number, encrypt it with the public key, and send back. If the client really owns the corresponding private key, he can decrypt the file, concatenate with session key (left out for simplicity), hash the result and send to server. Server will have the random number, and the session key. If server hashes both and the result matches what the client sent, the client is the owner of the key and can login.

How does distribution of a key solve authentication problem?

Easy. See above.

Key can be stolen by any wrong person...Why AWS allow ssh login to EC2 without a password?

Because is several orders of magnitude harder to steal a key than to steal a password. If an attacker creates a phishing site to steal your Amazon password and you fall for it, your password is compromised.

If same attacker creates a phishing SSH server to steal your data, it will never steal your private key, as it is never transmitted. He cannot steal anything he doesn't already have (the random number and the session key), and the only borderline sensitive thing he can steal is your public key, and a public key is public anyway.

SSH with the key is the safest way. Passwords can be stolen or leak, but to steal a private key is way harder.

  • For your second part in answer... Am guessing.. keypair is assymetric key pair... Who is client in this scenario? Ec2 or my laptop? Nov 15, 2019 at 9:21
  • The client is your laptop. The server is EC2.
    – ThoriumBR
    Nov 15, 2019 at 12:18
  • In that case, server should distribute public key to client, for sharing random number.. Nov 15, 2019 at 16:15
  • No, the client sends the server the public key. Server generates random number, encrypts it and sends it to client.
    – ThoriumBR
    Nov 15, 2019 at 16:56
  • In my case, client does not have public key. I did not create any public key in my laptop(client). What I just do is, download private key(.PEM) from AWS and use it... Nov 15, 2019 at 19:03

In this specific case, the private-public key pair is more for authentication.

You do not have to generate the private-public key pair on the AWS console, you can do this yourself and upload just the public key onto AWS.

The important thing is that the public key loaded onto the EC2 instances matches to the private key you're trying to logon with. As per their documentation:

You can use Amazon EC2 to create your key pair. For more information, see Creating a Key Pair Using Amazon EC2. Alternatively, you could use a third-party tool and then import the public key to Amazon EC2. For more information, see Importing Your Own Public Key to Amazon EC2. Each key pair requires a name. Be sure to choose a name that is easy to remember. Amazon EC2 associates the public key with the name that you specify as the key name. Amazon EC2 stores the public key only, and you store the private key. Anyone who possesses your private key can decrypt your login information, so it's important that you store your private keys in a secure place.

The private key once generated on the console can no longer be retrieved, hence it remains private to you. I suspect offer this ability to generate keys from the console to reduce the barrier to entry for using EC2.

The same applies for the console ssh access as well. A lot of folks start using EC2 aren’t familiar with SSH clients etc, and a logon directly in the browser is quite helpful. The direct access in the browser simulates connecting a monitor and keyboard directly to your server (not ssh) and will not prompt for a password unless explicitly set it. Of course now AWS have newer ways to connect to EC2, but I’m not familiar with those.

  • Good answer and very precise Nov 25, 2019 at 9:41

On the contrary, asymmetric (public-key) encryption is almost never used for bulk encryption and decryption of data flowing across an SSL or SSH connection; rather, it is used for authentication and key agreement. Symmetric encryption is far more efficient and less computationally expensive compared to asymmetric encryption.

SSL requires the server to provide a certificate which contains its public key and is signed by a Certificate Authority with the CA's private key. The client then verifies the signature using the CA's public key which is trusted by the client in advance. (There are usually intermediate signatures between the server and the root CA certificate.)

Once verified, the client uses the server's public key to share with the server a random master secret, which is used to create an encryption key to protect the session. While the certificate is used to authenticate the server to the client (important for browsers), the encryption key is symmetric and does not provide authentication in and of itself.

The client is not required by the protocol to authenticate itself to the server unless the service is configured to require this, which I believe AWS is configured to do. To authenticate itself, the client must generate a certificate of its own, which it needs its own private key to sign. AWS appears to be creating a private key on the client's behalf and retaining the corresponding public key so it can verify the client certificate. The alternative would be for the client to generate this key itself and send the public key to AWS, which is problematic because AWS would have to trust the client's public key on first use. This is used for authentication, not for encryption.

SSH skips much of the certificate process in favor of direct use of public-key authentication. In this case, the client authenticates to the server by signing some data related to the SSH connection and therefore known to both parties, and the server verifies this signature using the client's public key (which must be pre-shared with the server). SSH also requires the server to authenticate itself to the client, but instead of being pre-shared, the host keys are often trusted on first use. Again, as with the SSL case, AWS creating a private key to be retained by the client means that AWS already has the corresponding public key with which to verify the signature that authenticates the client. Also, again as with SSL, the data is encrypted with a symmetric key, which in this case is agreed on (using anonymous, ephemeral keys) before authentication is done (so that other forms of authentication, including passwords, are protected by encryption in transit).

All of this means that the client must guard against compromise of the private key issued to them by AWS. Anyone with possession of that key, as far as AWS is concerned, is the client and has full authority to do whatever the client may do.

  • asymmetric (public-key) encryption is used to share symmetric key(random master secret) provided by client Nov 14, 2019 at 18:48
  • edited to incorporate that fact. thanks! Nov 14, 2019 at 18:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.