I am working with win 7 and git bash as well as an amazon EC2 instance. I tried to log into my instance:
$ ssh -i f:mykey.pem ubuntu#ec2-52-10-**-**.us-west-2.compute.amazonaws.com
###########################################################
# 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 a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
71:00:d7:d8:a------------------26.
Please contact your system administrator.
Add correct host key in /m/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /m/.ssh/known_hosts:27
ECDSA host key for ec2-52-10-**-**.us-west-2.compute.amazonaws.com has changed and you have request
ed strict checking.
Host key verification failed.
Logging in like this has worked fine in the past, but this problem started after I rebooted my EC2 instance. How can I get this working again?
edit:
$ ssh -i f:tproxy.pem ubuntu#ec2-52-10-**-**.us-west-2.compute.amazonaws.com
ssh: connect to host ec2-52-10-**-**.us-west-2.compute.amazonaws.com port 22: Bad file number
tried again:
The authenticity of host 'ec2-52-10-**-**.us-west-2.compute.amazonaws.com (52.10.**-**)' can't be
established.
ECDSA key fingerprint is d6:c4:88:-----------fd:65.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added 'ec2-52-10-**-**.us-west-2.compute.amazonaws.com,52.10.**-**' (ECDSA) t
o the list of known hosts.
Permission denied (publickey).
what should I do now?
The hostname has a new ssh key, so ssh tells you something has changed.
The hint is here:
Offending ECDSA key in /m/.ssh/known_hosts:27
If you're sure the server on the other side is authentic, you should delete line 27 in /m/.ssh/known_hosts.
This error says that something has been changed since your last login to this server and that the server you try to ssh to, might not be the server you think it is.
One thing to be aware of...
When you create an EC2 instance, No fixed IP assigned to this instance.
When you start this instance, it will get (dynamic) IP number and a DNS name which will be based on that IP.
If you shutdown the instance and start it again few hours later, it might get a new IP and a new DNS name.
If you are still trying to access the old DNS name/IP, you are actually trying to access a server that might not belong to you.
This will end with the same error msg as you had.
(It can happen because you pointed a DNS entry to the old IP, or you are using scripts that try to access the old DNS name/IP, or you just repeating the ssh command from your history...)
If this is the case, the solution is to use Elastic IP.
You can assign Elastic IP to your server, and this will force it to keep its IP address between reboots.
Elastic IP is free while your (attached) server is up.
But it will cost you some minor fees when the attached server is down.
This is done to make sure you are not "reserving" IP while not using/need it
In BeanStalk environment, the issue is that it refers to the key from known_hosts for the respective IP. But it has changed. So using the same key would not work.
Removing the key for the IP from ~/.ssh/known_hosts and then connecting by ssh would work.
(Basically, when the entry is not there in ~/.ssh/known_hosts it will create a new one, and thus resolve the conflict)
Type the following command to set the permissions. Replace ~/mykeypair.pem with the location and file name of your key pair private key file.
chmod 400 ~/mykeypair.pem
In your case mykeypair.pem is tproxy.pem
I was facing the same issue and after making pem file private it was fixed.
Here is some more information on SSH Key Permissions
Related
I have a server that I need to connect to sometimes. It has a public IP, but the IP is renewed quite often. To combat that, I have a script that will update a DNS record to map ssh.myurl.com to my new IP.
This setup works, but once the IP changes, I get the error:
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Then I have to delete the key from my client, using ssh-keygen -R ssh.myurl.com, and it works again.
But this seems redundant, as I can't really see how this adds any security. Can I configure this setup so that it always trusts this connection?
The setup is using ProxyJump if that would change anything.
I've created public and private keys, and added the public key to the Bitbucket repository.
These private/public key pair is available in the .ssh folder of the user account I hope to clone to.
Attempting to clone with SSH produces a connection refused:
This lead me to believe that either the Bitbucket project/server is not configured for ssh, or maybe this is a firewall/port issue for my companies network. However, port 7999 and port 22 are open.
This lead me to investigate other means of cloning with ssh, but over http as described here (just in case if port 22 or 7999 was blocked): https://support.atlassian.com/bitbucket-cloud/docs/troubleshoot-ssh-issues/
To do this I modified my ssh config as follows:
Doing this allowed me to atleast establish a connection with bitbucket, but it acts as if the request was bad:
This lead me to believe that maybe i signed the cert incorrectly so I attempted a flavor of this: https://unix.stackexchange.com/questions/503851/how-to-generate-a-certificate-file-which-to-be-used-with-ssh-config
To add the certificatefile provided in the ssh config. It sounded like I would need to add that public key of the private key used to sign the user key (that generated the certificate). However, I won't have access to the private key for the cert available on the bitbucket server.
Separately, I was able to grab the public cert from altssh.bitbucket.di2e.net:443 and I did try using this, but still got a bad request... This probably doesn't make sense to use since this is in PEM format, but I figured it was worth a try..
openssl s_client connect altssh.bitbucket.di2e.net:443 < /dev/null | sed -ne '/-BEGIN CERTIFICATE/,/END CERTIFICATE/p' > public.crt
I'm wondering if I've incorrectly signed the user key with the cert key, but would like advise on best steps to do this.
Thanks!
Come to find out the bitbucket proxy server I was trying to connect to was not configured to handle altssh.bitbucket.di2e.net which caused the connection over :443 to get dropped.
Root of the issue was a combination of corporate firewall blocking 7999 to external (wasn't blocked internally), as well as /etc/ssh/sshd_config on the remote machine I was attempting to clone to not being configured to AllowAgentForwarding
We have a kubernetes cluster with multiple worker nodes. The only difference between the nodes are the ip addresses and hostnames. I used to ssh into all of them, and there is no problem at all.
I understand that there are a lot of similar questions related to this warning, but I don't think any of them is the same as mine. In detail, recently, this warning shows when ssh into one of the worker nodes occationally. That is to say, sometimes I can ssh into the machine successfully, but some times see this warning. This is the full warning message:
###########################################################
# 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 a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:95IISBgdGFLH2SEeU+E6YO+S9qnfEXfJqblNqfY/SFE.
Please contact your system administrator.
Add correct host key in /home/xxx/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/xxx/.ssh/known_hosts:55
remove with:
ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R "10.210.10.12"
RSA host key for 10.210.10.12 has changed and you have requested strict checking.
Host key verification failed.
These are what I have done so far:
Check the MAC address of the machine with arp -a command, and it is the targeted machine.
Remove the 55th line of known_hosts. But after sometime, it happens again.
Re-plug the cable, can ssh in for a while, and after sometime, it also happens again.
Any idea?
Thanks in advance.
From your question, I understand that you've removed the 55th line without understanding why. That line contained the previous host identification of the 10.210.10.12 machine. Why did you do that? The goal of the warning is to warn you about something suspicious, and you should aim to figure out what happened before dismissing the warning.
Checking the MAC is a good idea, but MAC addresses can be spoofed far easier than SSH host id's. It doesn't tell you much. A changed MAC would be a bad sign, but this does not tell you much. You need to figure out what happened, and so far you've found nothing.
If your company has a security team, contact them. If not, get assistance.
After days of struggle, finall work it out. Turns out that the Supermicro motherboard will takes up an IP address for IPMI, which is also 10.210.10.12.
I am trying to use knife from my laptop to connect to a newly configured Chef server hosted on AWS. I know what is listed below is the right direction for me but I'm not sure how to go about this exactly.
If you are not able to connect to the server using the hostname ip-xx-x-x-xx.ec2.internal
you will have to update the certificate on the server to use the correct hostname.
I had this same problem. The problem is that EC2 instances place their private ip into their hostname file. Which causes chef to self assign certs to the internal ip. When you do knife ssl check you'll probably get an error message that looks like this:
ERROR: The SSL cert is signed by a trusted authority but is not valid for the given hostname
ERROR: You are attempting to connect to: 'ec2-x-x-x-x.us-west-2.compute.amazonaws.com'
ERROR: The server's certificate belongs to 'ip-y-y-y-y.us-west-2.compute.internal'
connecting to the public IP is correct however you'll continue to get this error if you don't configure your chef server to use your public dns when signing the cert.
EDIT: Chef's documentation used to have steps to correct this issue, but since the time I initially answered this question they have removed those steps from their tutorial. The following steps worked for me with Chef 12, Ubuntu 16 on an ec2 instance.
ssh onto your chef server
open your hostname file with the following command sudo vim /etc/hostname
remove the line containing you internal ip and replace it with your public ip and save the file.
reboot the server with sudo reboot
run sudo chef-server-ctl reconfigure (this signs a new certificate, among other things)
Go back to your workstation and use knife ssl fetch followed by knife ssl check and you should be good to go.
What you could ALSO do, is just complete steps 1 - 4 before you even install chef onto the server.
Update public IP on Chef Server
run chef-server-ctl reconfigure on Server (No reboot needed)
Update the knife.rb on Workstation with new IP address
run 'knife ssl fetch' on the Chef Workstation
This should resolve the issue, to confirm run 'knife client list'
You can't connect to an internal IP (or DNS that points to an internal IP) from outside AWS. Those are nonroutable IP addresses.
Instead, connect to the public IP of the instance, if you have one.
I set up an ec2 instance. In the security group, I opened up SSH 'tcp' port 80 for 0.0.0.0/0 (all open for testing purposes). I associated the instance with a private key. I downloaded the key and passed it while ssh-ing, but the RSA isn't authenticating. Any ideas?
ssh -i mykey.pem root#mydnsinfo.amazonaws.com
The authenticity of host 'mydns.amazonaws.com(IP)' can't be established.
RSA key finger print is FINGERPRINT
Are you sure you want to continue connecting (yes/no)?
Thank you in advance!!!
This is normal. Your SSH complains about the unknown host key. It always does when connecting to the new host for the first time. Just answer yes, connect and try again.
It should not complain for the second time.
The private key that you downloaded is for your 'root' account not for the whole host.
Securely configured EC2 instances will include the server SSH key fingerprint in the console output that you can access over SSL before you try to connect over SSH. Then when you connect over SSH you need to make sure the fingerprint matches the console. You MUST do this to be able to securely connect to public EC2 instances.
Public EC2 instances generate new server SSH key on each boot. This means that unless you do what I described above, you will be faced with unknown host key warning a lot, and if you ignore that warning you will be throwing security out of the door; you just never know where you will be connecting to.