When trying to connect via PuTTY with SSH, I get the following warning:
The server's host key is not cached in the registry. You have no
guarantee that the server is the computer you think it is. The
server's rsa2 key fingerprint is: ssh-rsa 1024
cc:2v:25:73:c8:a6:59:7e:b8:23:2d:13:3e:66:9b:b9 If you trust this
host, enter "y" to add the key to PuTTY's cache and carry on
connecting. If you want to carry on connecting just once, without
adding the key to the cache, enter "n". If you do not trust this host,
press Return to abandon the connection. Store key in cache? (y/n)
Connection abandoned.
The issue is, the fingerprint shown in the warning message is not the fingerprint to the key that I want to use. How do I change it?
The issue is, the fingerprint shown in the warning message is not the fingerprint to the key that I want to use. How do I change it?
That should not be. That is fingerprint of the key that belongs to the server you are connecting to.
Related
I have heard that SSH does not need certificates.
But for RSA authentication of SSH , it should make sure that public key belong to the server and it can be done with certificates.
But it does not use certificates.
So how does it do?
No. It does NOT NEED them, but it CAN use them (but they are different then the certificates used in SSL! for various reasons). Certificates help only to delegate the verification to some certificate authority. To verify the public key, you just need to get the public key using "secure" channel.
So how you can verify the public key of the server you are connecting to?
There are several possibilities. The server admin will send you using different secure channel the public key of fingerprint of the public key. They can look like this:
Public key: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
You can store this one directly in your ~/.ssh/known_hosts prefixed with the server name and space.
Fingerprint SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1A bitbucket.org (RSA)
When you connect to the server for the first time, you are asked similar question:
The authenticity of host 'bitbucket.org (104.192.143.3)' can't be established.
RSA key fingerprint is SHA256:zzXQOXSRBEiUtuE8AikJYKwbHaxvSc0ojez9YXaGp1A.
Are you sure you want to continue connecting (yes/no)?
Then it is your responsibility to verify that the fingerprint is the same as the one you got from your admin.
If you don't do that, you are in danger that somebody redirected your connection to some malicious server and you are connecting somewhere completely else. The host keys are unique and this attacker would have different key (and therefore different fingerprint) unless he already compromised the original server (and then you are screwed already).
There is also possibility to add the host keys to the SSHFP DNS record, which will eliminate the burden above (you should have DNSSEC, otherwise the DNS records can be modified the same way as your direct connection). For this to work, you need to turn it on in your ssh_config using VerifyHostKeyDNS options.
And what about the certificates?
SSH can use certificates. This is common in company environment, where you are already given a known_hosts file configured with the certificate authority, which is used to sign all the host keys (and usually also the clients authentication keys). In that case, you don't need anything from above and connecting to local infrastructure "just works". Note, these certificates are not X509 as used in SSL/TLS PKI. For more info about these certificates, see manual page for ssh-keygen, which explains that in detail.
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
I want to access to a server (hosted in Lonex) trough SSH (for file handling). For this I use PuTTY. To do so safely, I use Pagent, it needs a public and a private key.
In the server, under the ssh folder in the root directory there are two files:
id_rsa - which has the private key.
id_rsa.pub - which has a public key.
Given this information, if posible, I would like to generate the necessary files for Pagent.
What I have tried:
Using PuTTYgen to import/load a local copy of the file id_rsa. This successfully generated the the .ppk file needed for Pagent. I referred to the .ppk file in connection -> ssh -> auth. In this .ppk file appears the public and the private key. But when I use PuTTY to connect, having the generated .ppk added to Pagent, an alert prompts stating that I do not have the server's host key cached in the registry and then shows the server's rsa key fingerprint, which I know to not be the right one from the one shown in Pagent. The fact that this alert prompts tells me that my Pagrent key is not correct. Am I correct?
Comments:
- Given that the host already has a public/private key pair I believe I should generate a local private key given the same public key from the host. I could not accomplished this (I read about ssh-keygen commands but I did not find out how to get what I wanted done).
- The ISP suggested that everything I need is in this link: http://sourceforge.net/apps/trac/sourceforge/wiki/SSH%20keys#KeyGeneration:PuTTY
I could not find the use to it given that I do not have a form where I should place a public key generated locally by me and also the fact that it does not consider the situation where I already have a public key generated in the host.
- I asked the ISP if it was possible to add a public key generated locally by me to the authorized_keys2 file and they told me no due to the fact that it is a shared hosting.
Your question really boils down to this:
The fact that this alert prompts tells me that my Pagrent key is not
correct. Am I correct?
No; this is not correct. Your agent (Pageant) is likely set up correctly. As you said,
an alert prompts stating that I do not have the server's host key
cached in the registry and then shows the server's rsa key
fingerprint,
That prompt is for the server's host key, not your user's private key. Pageant only caches your user's private key, not the host's public key (or public key fingerprint). Pageant's purpose is to hold your private key so that the server can identify you; the purpose of the prompt that you saw was for PuTTY to allow you to verify that the server that you're connecting to is really the server you meant to connect to (i.e. that you're not connecting to an attacker's machine).
I use dsa key with passphrase to login via ssh into CentOS 6 remote server. Unfortunately I forgot the passphrase.
Is there a way to reset or retrieve passsphrase?
I still do have access to root of remote server through webmin.
no, the keyfile itself does not hold any data that would aid you in breaking/recovering (quite the same) the encryption. if you did not back up the information otherwise, you cannot recover it.
you however simply install a new key.
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.