When attempting your initial SSH connection to a Gentoo AMI (specifically ami-6ab26f03) using your AWS key pair, you're unexpectedly prompted for a root password instead of using key-based authentication. This behavior differs from standard EC2 Linux instances where key-based auth is the default.

Unlike mainstream AWS Linux AMIs, Gentoo images often ship with different default configurations. The password prompt occurs because:

• The SSH daemon may have PasswordAuthentication yes set
• The PermitRootLogin setting might require password for root
• The authorized_keys file may not be properly populated during instance launch

For quick access, use the EC2 serial console (AWS web console > EC2 > Instances > Select instance > Actions > Monitor and troubleshoot > Get system log):

# Check for cloud-init errors
dmesg | grep cloud-init

# Verify SSH config
cat /etc/ssh/sshd_config | grep -E "PasswordAuthentication|PermitRootLogin"

# Manual key injection (if possible)
echo "ssh-rsa YOUR_PUBLIC_KEY" >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

Create a custom Gentoo AMI with proper AWS integration:

# Install cloud-init
emerge --ask cloud-init

# Configure cloud-init
cat > /etc/cloud/cloud.cfg << 'EOF'
system_info:
  default_user:
    name: root
    ssh_authorized_keys:
      - ssh-rsa YOUR_PUBLIC_KEY_HERE
EOF

# Update SSH configuration
sed -i 's/^#PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config

# Create AMI using AWS CLI
aws ec2 create-image --instance-id i-1234567890abcdef0 --name "Gentoo-Custom-AMI" --description "Gentoo with proper AWS SSH config"

If you can't modify the instance, try these approaches:

# Using AWS Session Manager (requires SSM agent)
aws ssm start-session --target i-1234567890abcdef0

# Via EC2 Instance Connect (if region supports it)
aws ec2-instance-connect send-ssh-public-key \
  --instance-id i-1234567890abcdef0 \
  --availability-zone us-east-1a \
  --instance-os-user root \
  --ssh-public-key file://~/.ssh/id_rsa.pub

# Then SSH normally
ssh -i ~/.ssh/id_rsa root@ec2-99-99-99-99.compute-1.amazonaws.com

Once connected, verify and correct the SSH settings:

# Check current settings
sshd -T | grep -E "authentication|root"

# Permanent fix
cat > /etc/ssh/sshd_config.d/aws.conf << 'EOF'
PermitRootLogin prohibit-password
PasswordAuthentication no
EOF

# Restart SSH service
/etc/init.d/sshd restart

When connecting to an EC2 instance for the first time using SSH with your key pair, you shouldn't be prompted for a password. The standard AWS workflow uses key-based authentication, not password authentication. This typically happens when:

• The AMI wasn't properly configured for EC2 key pairs
• The authorized_keys file is missing or incorrect
• SSH daemon configuration restricts key authentication

If you're locked out of your instance, AWS provides a serial console access method:

1. Go to EC2 Dashboard > Instances
2. Select your instance
3. Actions > Instance Settings > Get System Log
4. Look for password prompts or errors
5. Actions > Instance Settings > Get Instance Screenshot
6. Check for boot issues

For Gentoo AMIs specifically, you'll need to manually configure SSH access. Here's how to properly set it up when creating a new instance:

# First, create the .ssh directory with correct permissions
mkdir -p /root/.ssh
chmod 700 /root/.ssh

# Then add your public key to authorized_keys
echo "ssh-rsa YOUR_PUBLIC_KEY_HERE" >> /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

# Ensure SSH daemon allows key authentication
sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl restart sshd

If you're still facing problems, check these common issues:

# Verify the key pair was properly injected
curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

# Check SSH server logs for authentication attempts
tail -f /var/log/auth.log

# Test your key pair locally first
ssh-keygen -y -f your-key.pem

When SSH fails completely, consider these AWS-specific alternatives:

• Create a new AMI with proper cloud-init configuration
• Attach the volume to another instance for repair
• Use AWS Systems Manager Session Manager
• For EBS-backed instances: detach and mount the volume elsewhere