Question

I’ve got an instance using this AMI – ami-b7a29cc3

http://thecloudmarket.com/image/ami-b7a29cc3–bitnami-wordpress-3-3-1-1-multisite-linux-ubuntu-10-04-ebs#/details

Which is a WordPress Multisite Bitnami Image.

It’s installed and booted up fine, I’ve setup the security groups SSH, HTTP, HTTPs.

But weirdly enough connecting via SSH is not working, despite the front end working fine.

I’ve tried the following users and commands to no avail, ubuntu, root and bitnami.

I keep getting something weird like this happen though when I run the command.

D-Hewards-MacBook-Pro:Downloads dheward$ ssh -i macbookpro.pem bitnami@176.34.127.170
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
9f:85:89:8a:7a:9d:db:e0:15:e4:11:d0:e0:4b:74:a9.
Please contact your system administrator.
Add correct host key in /Users/dheward/.ssh/known_hosts to get rid of this message.
Offending key in /Users/dheward/.ssh/known_hosts:17
RSA host key for 176.34.127.170 has changed and you have requested strict checking.
Host key verification failed.
D-Hewards-MacBook-Pro:Downloads dheward$

Answer 1

This is likely (i.e. you need to judge this yourself after reading and understanding my explanation, because otherwise your security would indeed be at risk!) just normal behavior of SSH coupled with reuse of the meanwhile scarce IP addresses by Amazon EC2 (see IPv4 address exhaustion):

Background

The server side of your SSH connection needs to identify itself by the mentioned fingerprint for the RSA key, which is subsequently checked by your client side SSH tooling to ensure you are not falling victim of a Man-in-the-middle attack.

Regular SSH Process

1. you connect to a new SSH server for the first time
2. the new server presents its RSA key identity to your SSH client
3. your SSH client asks you to confirm this servers identity and will import the RSA key in turn for future security checks (into /Users/dheward/.ssh/known_hosts in your case)
   • ideally you’d have received this RSA key on a secure channel to properly assess its validity, however, most people simply don’t do that in nowadays ever changing cloud environments, see Eric Hammond’s Poll: Verifying ssh Fingerprint on EC2 Instances
     • Eric’s post mentions options to deal with this in principle already, i.e. For optimal security, you are supposed to request the instance console output and find the ssh host key fingerprint in the log to verify that it is the same as the fingerprint presented to you by the ssh command.
     • Furthermore, Eric discussed this topic in great detail in ssh host key paranoia.
   • Scott Moser has distilled a great summary how to actually Verify SSH Keys on EC2 Instances and provides instructions on how to update your known_hosts file in turn as well.
4. on every subsequent connect to the same SSH server, your SSH client will compare the stored RSA key with the one provided by the SSH server and will present a big fat warning regarding potential nastiness if it changes, because it usually shouldn’t indeed (I’ll skip the rare exceptions for now)
   • this means, if it suddenly changed (especially for a host you had been connecting to already without such a warning), you should indeed back out immediately and assess the situation first, i.e. if you don’t know a reason for the change, your connection security is at risk

Cause (i.e. Your Experience)

You might have gone through steps 1-4 once for another SSH server on EC2, which happened to have the very same IP address from their pool (i.e. 176.34.127.170); while not encountered every day, this is all but unlikely over time given the limited number of IPv4 addresses available in general and the respective pool available for Amazon in particular.

Now, since you are connecting to an entirely different server then the one for which the RSA key had been stored in the first place (every started EC2 instance has a respectively unique identity), your SSH client cries foul and presents the properly escalated warning you are seeing.

Furthermore, it seems to disallow SSH access entirely in this situation, since you [or your system administrator] have requested strict checking. (Most desktop SSH clients seem to ask for confirmation just like on first commit in this case by default).

Solution

1. Make damn sure my explanation of your experience actually applies to your situation!
2. Follow the instructions given in the warning message already:

The fingerprint for the RSA key sent by the remote host is
9f:85:89:8a:7a:9d:db:e0:15:e4:11:d0:e0:4b:74:a9. Please contact your
system administrator. Add correct host key in
/Users/dheward/.ssh/known_hosts to get rid of this message. Offending
key in /Users/dheward/.ssh/known_hosts:17 RSA host key for
176.34.127.170 has changed and you have requested strict checking. [emphasis mine]

I.e. the SSH RSA key cache maintained in /Users/dheward/.ssh/known_hosts currently has an entry No. 17 for IP address 176.34.127.170 with a different RSA key then the one presented by the server with IP address 176.34.127.170 you are currently trying to connect to – this must be adjusted, if you are sure there is no man-in-the-middle-attack in place in fact (which is unlikely, given that this is a new host you just commissioned, though as mentioned in 3) above, you might want to ensure this by following Scott Moser’s instructions how to actually Verify SSH Keys on EC2 Instances).

Good luck!