The
ssh-copy-id command fails on EC2 instances because the default Ubuntu user (
ubuntu) does not have password authentication enabled by default, and the remote server rejects public key injection attempts. To resolve this, you must first establish a secure connection using your existing
.pem key file, then manually append your local public key to the
~/.ssh/authorized_keys file on the instance with correct permissions.
Understanding the Failure Mechanism
When you run
ssh-copy-id, the tool attempts to connect to the remote host using password-based authentication or an existing SSH agent. It then transfers your public key to the
~/.ssh/authorized_keys file on the target machine. However, Amazon EC2 instances running Ubuntu are configured for key-pair authentication only. The root account is disabled, and standard users like
ubuntu cannot log in with passwords. Consequently, the
ssh-copy-id utility hangs waiting for a password prompt that will never succeed, or it throws an error stating that password authentication is disabled.
Furthermore, even if password authentication were enabled, security groups and network configurations might block the necessary ports. But the primary culprit is almost always the strict enforcement of key-only login on AWS infrastructure. You need to bypass the automated script and perform the key transfer manually via an active SSH session established with your private key.
Verifying Your Local Public Key
Before attempting any manual changes, ensure you have the correct public key ready. On your local machine, locate your public key file. It typically ends in
.pub. If you generated a new key pair specifically for this task, it might be located at
~/.ssh/id_ed25519.pub or
~/.ssh/id_rsa.pub. You can view its contents by running:
cat ~/.ssh/id_ed25519.pub
Copy the entire output string. It should start with
ssh-ed25519 or
ssh-rsa followed by a long string of characters and your email address or comment at the end. Do not truncate this string, as partial keys will result in authentication failures later.
Manual Key Injection Process
Since automation fails, you must use the working method: connecting with your existing
.pem key and editing the remote configuration files directly. This approach gives you full control over permissions and ensures the key is added correctly without relying on network services that might be restricted.
First, open a terminal on your local machine and navigate to the directory containing your
.pem key file. Then, establish an SSH connection to your EC2 instance using the following command structure:
ssh -i "your-key-pair.pem" ubuntu@your-ec2-public-ip
Replace
your-key-pair.pem with the actual filename of your private key and
your-ec2-public-ip with the public DNS or IP address of your instance. Once connected, you are operating as the
ubuntu user on the remote system.
Next, create or edit the authorized keys file. Run the following command to append your copied public key to the list:
echo "YOUR_PUBLIC_KEY_STRING" >> ~/.ssh/authorized_keys
If the
~/.ssh directory does not exist, create it first with
mkdir -p ~/.ssh. After appending the key, you must set the correct permissions. SSH is extremely strict about file permissions; if they are too open, it will ignore the keys entirely. Execute these commands to enforce security standards:
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
These commands ensure that only the owner can read and write to the directory and the key file. Without these specific permissions, your new key will be rejected silently.
Testing and Troubleshooting
After adding the key and setting permissions, exit the SSH session by typing
exit. Now, test the new authentication method by trying to connect again, but this time do not specify the
-i flag if you want to rely solely on the newly added key (assuming you have removed the old one from your agent or prefer testing the new path). However, for safety, keep using the original key for now to verify the new key works alongside it.
ssh ubuntu@your-ec2-public-ip
If you still encounter permission denied errors, check the logs on the EC2 instance. Although you cannot easily access
/var/log/auth.log without sudo privileges, you can enable verbose mode locally to see exactly where the handshake fails:
ssh -v ubuntu@your-ec2-public-ip
Look for lines indicating "Offering public key" and "Server accepts key". If the server refuses the key, the issue likely lies in the content of the
authorized_keys file or the permissions set earlier. Ensure there are no extra spaces or line breaks in the key string.
For more complex scenarios involving multiple users, refer to
Configuring a New User on AWS EC2 with SSH (Ubuntu) to understand how user-specific directories interact with SSH configurations. Additionally, if you manage several keys, consult
Managing Multiple SSH Keys on a Server to organize your local SSH config file for seamless switching between different instances.
Security Best Practices
Always restrict the source IP addresses in your security group settings to allow SSH traffic only from trusted networks. This reduces the attack surface significantly. Furthermore, consider disabling password authentication globally in the
/etc/ssh/sshd_config file if it is currently enabled, although AWS usually handles this by default. Regularly rotate your SSH keys and remove unused entries from the
authorized_keys file to maintain a clean and secure environment.
Frequently Asked Questions
Why does ssh-copy-id say "Permission Denied (publickey)"?
This error occurs because the server requires a valid private key for authentication, but the client did not provide one or provided the wrong one. Ensure you are using the correct
.pem file with the
-i flag during the initial connection phase before attempting to copy new keys.
Can I enable password authentication for my EC2 instance?
While technically possible by modifying
/etc/ssh/sshd_config, it is strongly discouraged due to security risks. AWS recommends using key-pair authentication exclusively. Enabling passwords makes your instance vulnerable to brute-force attacks.
What if I lose access to my .pem key file?
If you lose your private key, you cannot recover access to the instance via SSH. You must stop the instance, detach the root volume, attach it to a rescue instance, modify the
authorized_keys file there, and then reattach it. Alternatively, use AWS Systems Manager Session Manager if it was pre-configured.
How do I add a key for a different user on the same instance?
You must switch to that user using
sudo su - username and then repeat the process of appending the key to their specific
~/.ssh/authorized_keys file. Remember to adjust the ownership of the
.ssh directory to match the new user.
Is it safe to share my public key with others?
Yes, sharing your public key is safe. Only the corresponding private key allows decryption and authentication. Never share your private key file or
.pem file with anyone, as possession of the private key grants full access to your systems.