Ubuntu 24 EC2: When EC2 Instance Connect Breaks SSH Key Logins (and How to Fix It)

If you’ve launched an Ubuntu 24.04 EC2 instance and suddenly:

• SSH keys that should work give you Permission denied (publickey), and
• The server logs contain lines like this:

…you’re probably running into a default integration with AWS EC2 Instance Connect that you didn’t ask for.

On some Ubuntu 24 images, EC2 Instance Connect is:

• Installed by default, and
• Injected into sshd via systemd flags, not via sshd_config.

When that integration doesn’t line up with how you actually manage SSH keys, it can do more than just clutter logs — it can prevent users from logging in with SSH keys at all.

This post explains:

• How to recognize this specific failure mode
• Why it can block key authentication
• How to disable it cleanly by uninstalling EC2 Instance Connect

All examples are generic: “server” for the host, “sshuser” for an SSH user, etc.

Symptoms: Valid Keys Start Failing for No Obvious Reason

Typical signs:

From the client:

From the server (in /var/log/auth.log or /var/log/syslog):

You might see:

• Keys that worked on earlier Ubuntu versions (or different AMIs) no longer work.
• Password authentication may still work (if enabled), so it looks like a “key-only” issue.
• Service or SFTP accounts that rely purely on public key auth suddenly can’t log in.

What’s Actually Going Wrong

1. EC2 Instance Connect is wired in on the command line

On these images, EC2 Instance Connect is not just a passive package. The ssh systemd service is started with extra options that look roughly like:

You can see this on a running server:

If the main listener process looks like:

then EC2 Instance Connect is actively in the path of key authentication.

Important: command-line -o options override what’s in /etc/ssh/sshd_config, so you won’t see this in the config file even if you go looking.

2. EC2 Instance Connect is asked to validate keys… and fails

For every public key the client offers, sshd now calls:

That helper is supposed to:

• Check with AWS APIs whether that key is allowed for this OS user on this instance.
• Return authorized keys on stdout so sshd can validate them.

If EC2 Instance Connect is not configured, or the request doesn’t match allowed IAM policies, the helper exits with a non-zero status — often 22. sshd logs that as:

At that point, sshd may have no matching key source:

• The helper didn’t authorize the key.
• The account may not have a usable ~sshuser/.ssh/authorized_keys (common for service accounts that were intended to be managed centrally).
• Or your config may have been relying entirely on the AuthorizedKeysCommand path without realizing EC2 Instance Connect was in control.

The net effect: every key the client offers is rejected, and you see Permission denied (publickey) on the client.

Step 1: Confirm EC2 Instance Connect is Involved

On the server, first check the running sshd:

If you see the main sshd listener with -o AuthorizedKeysCommand=/usr/share/ec2-instance-connect/eic_run_authorized_keys, EC2 Instance Connect is in play.

Next, confirm the package is installed:

You’ll typically see something like:

At this point, if:

• You never intentionally set up EC2 Instance Connect, and
• You want to manage keys using normal OpenSSH mechanisms,

…then the simplest fix is to remove the package.

Step 2: Uninstall EC2 Instance Connect

From a root or sudo-capable user:

Confirm when prompted.

Then refresh systemd’s unit definitions:

This removes the systemd bits that were appending those -o AuthorizedKeysCommand options when sshd starts.

Step 3: Restart SSH Safely

Restart SSH:

Do this from an existing session and keep it open until you’ve verified that a new SSH session works. If something unexpected happens, you still have a shell to fix it.

Step 4: Verify sshd is Clean and Keys Work Again

Check the sshd processes again:

You should now see a main listener like:

Note the difference:

• No -o AuthorizedKeysCommand=/usr/share/ec2-instance-connect/...
• No -o AuthorizedKeysCommandUser=ec2-instance-connect

Now try logging in again with your SSH key from a client:

If your user has a correct ~sshuser/.ssh/authorized_keys and appropriate permissions, you should now see a normal, successful key-based login.

On the server, the logs should show something like:

instead of the earlier eic_run_authorized_keys ... failed, status 22.

Extra Sanity Checks for Service/SFTP Accounts

If you rely on dedicated service or SFTP accounts (sshuser, backup, etc.), it’s worth confirming that their local key setup is solid now that EC2 Instance Connect is out of the way:

Recommended permissions:

• /home/sshuser → owned by sshuser:sshuser, not group/world-writable
• /home/sshuser/.ssh → 700
• /home/sshuser/.ssh/authorized_keys → 600

With EC2 Instance Connect removed and proper file permissions in place, key-based auth should work exactly as it does on non-EC2 Ubuntu hosts.

Summary

On some Ubuntu 24 EC2 images:

• ec2-instance-connect is installed and wired into sshd via systemd.
• sshd is started with -o AuthorizedKeysCommand=/usr/share/ec2-instance-connect/eic_run_authorized_keys, which inserts EC2 Instance Connect into every public-key login attempt.
• When EC2 Instance Connect isn’t properly configured for your environment, that helper fails and can prevent SSH key logins from working at all, not just generate noisy logs.

If you don’t need EC2 Instance Connect and prefer standard OpenSSH key management, the simplest and most reliable fix is:

1. Remove the package:
   
   sudo apt remove ec2-instance-connect sudo systemctl daemon-reload

   1 2 3

   sudo apt remove ec2-instance-connect sudo systemctl daemon-reload

2. Restart ssh and verify:
   
   sudo systemctl restart ssh ps aux | grep '[s]shd'

   1 2 3

   sudo systemctl restart ssh ps aux | grep '[s]shd'

3. Confirm that the sshd listener no longer has -o AuthorizedKeysCommand in its arguments and that your SSH key logins work again.

Once this is done, your Ubuntu 24 EC2 servers behave like “normal” SSH servers: no hidden cloud hooks, and no mystery failures when a perfectly good SSH key should just work.