Suppose I have created ssh keys.The server has private key and I use a ubuntu machine which has public key to connect to server. Now my public key gets stolen and the hacker know the IP of server which has private key. Then can hacker be able to connect to server using the stolen public key using ssh command?
If no, then why?
My understanding is since the same public key is used by hacker, the server will never know from which machine the ssh request came from. So the server should will validate the public key and allow to login.
Please correct if I am wrong.
As written, the answer to your question is 'no, the hacker cannot connect to the server using the public key you have obtained from the server'. They would also need the user's private key or password.
For more completeness, in case the terminology has been confused:
There can be two sets of public+private keys used when you SSH to a server from your workstation.
The server has a private key, and an associated public key. You copy the public key from the server to your workstation (normally, your ssh client will do this for you when you first connect, and it will end up in a file called known_hosts in your ~/.ssh directory). If the hacker gets the server private key, they can pretend to be the server. If the hacker gets the server public key, they can only verify the identity of the server to themselves.
The workstation (i.e. you) may have a private key, and an associated public key. The private key will normally be in ~/.ssh/id_rsa or similar. The public key will likely be the same filename but with .pub on the end. The contents of the public key will be also be stored on the server in the file ~/.ssh/authorized_keys for the user on the server that the key authenticates. If the hacker gets this private key, they can pretend to be you. If the hacker gets this public key, they can only verify that a connection comes from you. It is possible to do ssh without this workstation-side public+private key, but you would instead be using a password to authenticate to the server rather than a key.
So, the first question you would ask yourself is whether you use a password or a key on the workstation to authenticate to the ssh server. Then whether the hacker has stolen the public key or the private key from either server or workstation.
If the hacker has either public key then this is not generally considered a problem (hence the name 'public').
However, if the hacker has either private key then it is a problem, and you should change that key (on either the server or your workstation). Depending on the key that they've potentially stolen, you will want to remove the server's public key from your workstation ~/.ssh/known_hosts file on your workstation, or your public key from the server (~/.ssh/authorized_keys).
Remember that if the hacker has the server private key, then anyone who has the associated public key in their known_hosts file will still trust the old private key (i.e. a server the hacker creates) even once you've changed the key on the real server, so you will want to make sure the known_hosts files are fixed everywhere. And if they've stolen your private key from the workstation then any server that has the associated public key in it's authorized_keys file will still trust the old key even once you've changed it on your workstation, so you will want to replace the public key on all servers that you use that private key on.
By definition, private keys are private (i.e. secret) and public key are public (i.e. not secret).
A hacker doesn't need to steal a machine's public key, they can simply ask for it. For example:
$ ssh-keyscan github.com
# github.com:22 SSH-2.0-babeld-408889af
# github.com:22 SSH-2.0-babeld-456f9bbd
github.com ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==
# github.com:22 SSH-2.0-babeld-408889af
github.com ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=
# github.com:22 SSH-2.0-babeld-408889af
github.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl
# github.com:22 SSH-2.0-babeld-408889af
$
Related
I was under the impression that the PEM file was just another public key as in SSH PubKeyAuthentication but I was completely wrong.
I didn't want to add the identity file in my ssh command each time, so I tried to do an ssh-copy-id into my azure vm so I can directly authenticate and log in with a simple ssh user#ip command
However, this command failed saying All keys were skipped because they already exist on the remote system. and when I checked /etc/ssh/sshd_config the PubKeyAuthentication line was commented out.
This led me to wonder, which line is enabling the IdentityFile/PEM key to be used to login?
Is it safe for me to enable PubKeyAuthentication on this public server?
Is PEM more secure?
In public key authentication, client has a private key that he uses to authenticate to server's public key.
There is no difference in security if you are using a private key (.ppk file) or a pem file to authenticate to your server.
I guess you are seeing something like this "#PubkeyAuthentication yes" in the sshd_config file, and this does not mean that it is commented out. It is a config file and this means that public key authentication has been enforced.
In short to answer your question, SSH with PEM file is no different from Public Key authentication (PKA). In PKA, you have the private key to yourself which you use to authenticate to the server's public key. With PEM file, it is nothing but the private key itself along with certificates. So, there is actually no such difference. You can convert a pem file to a .ppk file as well.
I am using Zabbix 4.0.
Trying to make a discovery rule for another remote linux server with SSH agent.
It asks for privatekey file and public key file. I understand it asks for privatekey file.
I put the private key file for remote server into the zabbix server .ssh director.
But why does zabbix also wants us to enter public key file. Privatekey file should be enough
to connect to remote server.
It is probably the public key of the server (aka hostkey), that is needed to verify that Zabbix is connecting to the legitimate server.
I have created a ssh key for my droplet at digital oceans. After few days I have deleted the key from security page and still I am able to ssh using putty with that key. Is it necessary to delete the key from authorized_keys file. If so, then what is the use of adding/deleting ssh keys to droplet on their above mentioned security page?
Question at digital ocean - https://www.digitalocean.com/community/questions/how-to-remove-ssh-keys-for-the-droplet
As the digital tutorial page says
"You can create new DigitalOcean droplets with an SSH key already set up on them by adding your computer’s SSH key to the control panel.".
To setup a ssh key for the droplet it is needed to add your newly created key to the droplet's control panel.
You are able to access the droplet even after you deleted the ssh from security page because now the ssh also resides inside your droplet's ~/.ssh/ folder(remote machine).
To authenticate using SSH keys, a user must have an SSH key pair on their local computer. On the remote server, the public key must be copied to a file within the user's home directory at ~/.ssh/authorized_keys. This file contains a list of public keys, one-per-line, that are authorized to log into this account.
When a client connects to the host, wishing to use SSH key authentication, it will inform the server of this intent and will tell the server which public key to use. The server then check its authorized_keys file for the public key, generate a random string and encrypts it using the public key.
So, it necessary to delete the key from authorized_keys file to stop ssh access to the remote machine.
After the droplet creation security page lists the keys just to show what all ssh keys you used for all your droplets.Deleting them from security page will not prohibit you from accessing your droplet.
Does the remote machine that I will be ssh'ing into require it's own private key to be generated so that I can ssh into it from a local machine.
Yes. It is called Host Key and it needs to exists before you ssh into the machine. It is used to validate the identity of the server and prevent Man in the Middle Attacks.
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).