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$
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
you connect to a new SSH server for the first time
the new server presents its RSA key identity to your SSH client
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.
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
Make damn sure my explanation of your experience actually applies to your situation!
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!
Related
I have a client who is remote. I need to debug some weird problem that none of my other clients are having. Before I try and set up a conference with this client, I would like to know if there is some way of remotely debugging our application.
I see that there are remote debugging tools available for Visual Studio, but from what I've read, I need to be on the same subnet. As the person is remote, this is not a possibility. Also, as I'd like to keep our connection secure, I would need to connect up some sort of encrypted tunnel (this is where I'm a little fuzzy as my networking skills are mostly theoretical).
As I understand it, an encrypted tunnel is a bridge to another (different) subnet. This is to ensure that those computers on the other side won't interfere with the local subnet computers.
So, because the client's computer is on a different subnet, I think that this is not possible. Or is it? Should there not be a way of making the client's computer show up as a virtual computer on my subnet, by forwarding packets from one subnet to another? I would think that this is theoretically possible, but I'm not exactly sure how I would go about this.
Also, at the moment, my current way that we connect to clients is through GoToMeeting, but I don't think that it supports tunneling. If not, then I may need some way of generating a tunnel, so I was also thinking of maybe using some SSH programme like PuTTY.
As I have said before, my knowledge of networking is quite theoretical, so if the tools that I am suggesting are not the correct ones, please correct me. (I'm a programmer, damm it! Not a network engineer!)
Both computers are Windows boxes. Windows 10 (client) and Windows 8.1 (development).
If you can connect to an ssh server in the remote network, you can (subject to configuration on the server) create a tunnel such that you connect to a socket on your local pic and the connection appears from the server to an endpoint on the remote network.
You'll want to investigate the -L command of OpenSSH, which combined with the PuTTY docs, should help explain what's required.
By default, the endpoint would be a port on the ssh server, but it could be a port on a different host that the remote server can connect to.
I'm not familiar with the current state of Windows SSH servers, but even if there isn't a system server to hand, you should be able to have on run 'on demand' - if you run it on a non-privileged port and by the user you want to connect in as, it shouldn't even need Admin privileges.
I'm not familiar with GoToMeeting, but the one thing with SSH tunnelling it that IT depts should be familiar with SSH. If trying that, focus on getting a working connection in, then setting up the tunnel, then connecting through it as separate steps.
Once you have an SSH connection, then it doesn't need to do something itself, and you can then investigate connecting while specifying the port forwarding, but will will need to get the basic connection working correctly first.
One of my EC2 instances was hacked a few days ago.
I tried logging in via SSH to the server, but I couldn't connect. I am the only one with access to the private key, and I keep it in a safe place.
Luckily, I had a backup of everything and was able to move the web app to a new instance quite fast.
My concern right now is that I don't know how my instance was hacked in the first place.
Why can't I log in via SSH using my private key? I would assume that the private key stored on the server can't be (easily) deleted.
Is there a way I can find out how the hacker gained access to the instance? Perhaps a log file that would point me in the right direction.
Should I attach the EBS volume in question to a new instance and see what's on it or what are my options in this case?
Right now, it seems I have to access at all to the hacked instance.
Thank you!
#Krishna Kumar R is correct about the hacker probably changing the ssh keys.
Next steps:
Security concerns (do these now!):
Stop the instance, but don't terminate yet
Revoke/expire any sensitive credentials that were stored on the instance, including passwords and keys for other sites and services. Everything stored on that instance should be considered compromised.
Post-mortem
Take an EBS snapshot of the instance's root volume (assuming that's where logs are stored)
Make a new volume from the snapshot and attach to a (non-production) instance
Mount and start reading logs. If this is a linux host and you have port 22 open in the firewall, I'd start with /<mount-point>/var/log/auth.log
They might have logged into your machine via password. In ssh config, check the value of: PasswordAuthentication. If it is set to yes, then users can login to the instance remotely via password. Check /var/log/secure for any remote logins. It will show up all logins (password or key based).
If someone logged in as 'root', they can modify the ssh keys.
The fact that you are unable to login to the machine does not mean that it has been "hacked". It could be due to a configuration change on the instance, or the instance might have changed IP address after a stop/start.
Do a search on StackOverflow for standard solutions to problems connecting to an instance and see if you can connect (eg recheck IP address, check security group, turn on ssh -v debugging, check network connectivity & VPC settings, view Get System Log, etc).
Worst case, yes, you could:
Stop the instance
Detach the EBS volume
Attach the EBS volume to another EC2 instance
Access the content of the EBS volume
I am attempting to Bind my Mac to a University AD server through an SSH tunnel. I have successfully created the tunnel and can access the directory by ldapsearch using the address localhost:389
The problem is that I wish to bind the computer through either the Directory Utility or dsconfigad but I get an error:
dsconfigad: Authentication server could not be contacted. (5200)
Could it be because I need to port forward more ports than just 389? or would it be a limitation put in place by the Directory Admins?
Active Directory is far more than LDAP - at the very least you'd need Kerberos, but it also tightly integrates with DNS (both SRV and A records), which'd require significant trickiness to fake over an SSL connection.
Realistically, I think you're going to need (at least) a full VPN connection to do this.
I have a computer at my college that I always ssh into from my laptop. However, I'm leaving for break soon, and I realize that whenever I try to ssh in from a different network, the server won't let me in. I really would like to be able to ssh into this computer during break, so what should I do?
Whenever I type this into terminal:
XXXXXXXXXX$ ssh -X XXXXXXX#XXXXX.XXXXX.XXXX.XXX.XXX
The process either won't go forward, or I get this error message:
ssh: Could not resolve hostname XXXXX.XXXXX.XXXX.XXX.XXX: nodename nor servname provided, or not known
Yes, you can, thru ssh-tunnelling. See this link.
The problem is that, you need to have a box of public fixed IP address outside of your school.
If you have a public floating address, it's still possible. First, you will need DDNS (just search 'DDNS' on the web), or other method for your server to get your client's IP address. For example, in your personal web page, somewhere, stores your current client's IP floating IP address. Then, you need a script/program to fetch that address. After that, apply the same ssh-tunneling technique. (Yet, you need a script/program to automatically apply all these steps, yet fail safe issue: When your client's is disconnected, your ssh-tunnel will break, and your ssh-tunneling process died. Your script need to sense it and re-launch (after getting the new floating IP address).
Oh, the pre-assumption is that, you need to be able to ssh from your school server (your linux box in school) to an outside server (a linux box in your home, for example). I think most school won't block ssh access to servers outside of the school.
I've got a Github account setup on one computer. I would like to also access my Github account on a second machine using the same SSH key I used for the first computer. How do I import the SSH private key into the new computers user profile?
cp ~/other_comp_github_key ~/.ssh/github
The above command did not do the job in the git bash console on Windows.
Argh! No!
Do. Not. Share. Private. Keys.
Make a new keypair on the second computer.
It'd be best to create a new private key if github allows you to have several associated with your account. (Sharing private keys among machines is very much like sharing passwords on multiple accounts.) But not all services allow multiple keys, so...
You don't specify that you copied the private portion of the key; make sure you copy the private portion.
You don't specify that you configured the ~/.ssh/config block to use the ~/.ssh/github key for the github.com host. Make sure you add a new block to your ~/.ssh/config file just like block on the machine you stole the key from.
host github.com
IdentityFile ~/.ssh/github
(I don't know that the host is github.com -- if you use a different hostname, then use that.)
The copying of the private key will work, iff the permissions to the ssh files copied are correct, i.e. readable for the user who uses the keys, something like 555 will do. Also, since github allows multiple ssh keys to be used with same account, you can create a new keypair and add it to your account.
I had the same issue, simply create a new SSH Key in the other computer since its not advisable sharing the same SSH Keys across different computers.
Follow these sets of instructions on Github,I found them pretty much direct and easy to follow.
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent