SSH Key Management and Secure Access to EC2 Instances Quiz Quiz

Explore key concepts of SSH key management and secure access for virtual server instances within virtual private clouds. This quiz covers essential practices, common scenarios, and mistake prevention techniques important for cloud security in DevOps workflows.

1. Purpose of SSH Keys

   Which of the following is the primary purpose of using SSH key pairs when accessing EC2 instances in a virtual private cloud?

   1. To assign static IP addresses
   2. To verify user identity securely
   3. To speed up network traffic
   4. To increase instance storage

   Explanation: SSH key pairs are primarily used to securely verify a user's identity when connecting to an instance. Using SSH keys does not affect instance storage, has no impact on network speed, and is unrelated to static IP address assignment. The other options describe functionalities not provided by SSH authentication.

2. Private Key Storage

   If you generate an SSH key pair for EC2 access, where should you securely store the private key?

   1. In a public code repository
   2. On the EC2 instance
   3. On a shared cloud drive
   4. On your authorized local machine only

   Explanation: The private key should be kept only on your authorized local device and never be shared or uploaded elsewhere. Storing it on the EC2 instance or a shared drive compromises security, and putting it in a public repository is highly unsafe. Only local, secure storage ensures the private key remains confidential.

3. Default SSH User

   When connecting to a new EC2 instance using SSH, what is commonly the default username for most Linux distributions?

   1. ec2-user
   2. admin
   3. root
   4. ubuntu-user

   Explanation: For many Linux-based environments, 'ec2-user' is the default username provided for SSH access. 'Admin' and 'ubuntu-user' are not default users, although 'ubuntu' (not 'ubuntu-user') may be used for some images; however, 'root' is usually disabled for direct access due to security reasons.

4. Public Key Placement

   In typical SSH key authentication for an EC2 instance, where is the public key stored after initial setup?

   1. In the instance's authorized_keys file
   2. In the virtual private cloud settings
   3. In the local user's desktop folder
   4. In an unsecured TXT file

   Explanation: The public key is stored in the 'authorized_keys' file inside the user’s SSH directory on the server. Keeping it in the local desktop folder or VPC settings would not grant access. Leaving it in an unsecured text file poses a security threat and is not a recommended practice.

5. Lost Private Key Action

   If you lose the private SSH key for your EC2 instance and have no backup, which is the safest way to regain access?

   1. Guess the private key
   2. Use the public key instead
   3. Create a new key pair and update the authorized_keys file
   4. Restart the instance to reset keys

   Explanation: The recommended approach is to create a new key pair and update the server's 'authorized_keys' with the new public key; this restores access securely. Guessing or using the public key is not possible, and simply restarting the instance does not reset SSH credentials.

6. File Permissions for Private Key

   Which file permission setting should you use for your SSH private key to ensure it is securely protected on a local system?

   1. Read and write for user only (chmod 600)
   2. Write for everyone (chmod 222)
   3. Read for everyone (chmod 444)
   4. Execute only (chmod 111)

   Explanation: Setting permissions to 'chmod 600' ensures only the owner can read and write the key file, preventing unauthorized access. Allowing read or write access for everyone, or setting it to execute only, compromises the file’s security and confidentiality.

7. Key Pair Distribution

   Which method is considered unsafe when sharing SSH key pairs for EC2 access within a team?

   1. Assigning a unique key pair to each user
   2. Using secure file exchange tools
   3. Sending the private key over email
   4. Sharing only public keys

   Explanation: Transmitting private keys via email exposes them to interception and compromise. Assigning unique key pairs or sharing public keys are secure practices, while secure file exchange tools can help when public keys must be shared. The private key should never be distributed.

8. Revoking Access

   Which step should you take to revoke SSH access for a former team member from an EC2 instance?

   1. Delete the instance's security group
   2. Change the instance hostname
   3. Block all internet access to the VPC
   4. Remove their public key from the authorized_keys file

   Explanation: By deleting the user’s public key from 'authorized_keys', you effectively remove their SSH access. Changing the instance hostname, security group, or blocking all traffic is unnecessary or disruptive, affecting other users and services.

9. Network Security for SSH Access

   To enhance security, what is the recommended practice when configuring network access for SSH on EC2 instances?

   1. Allow inbound traffic on all ports
   2. Restrict port 22 access to trusted IP addresses only
   3. Open port 22 to all IP addresses
   4. Use default security group settings without changes

   Explanation: Limiting SSH (port 22) access to specific IP ranges significantly reduces the attack surface. Opening port 22 to everyone or allowing all inbound traffic exposes the instance to risks, while using default settings without review can be unsafe.

10. Rotating SSH Keys

    Why is it important to regularly rotate SSH key pairs used for EC2 instance access?

    1. To increase CPU performance
    2. To accelerate instance boot time
    3. To defeat network congestion
    4. To minimize risks if a key is compromised

    Explanation: Regular rotation of SSH keys ensures that if a key is lost or compromised, unauthorized access is prevented or limited. Key rotation does not influence boot time, network speed, or processing power; these are technical distractors unrelated to secure access.