skip to Main Content

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.

2

Answers


  1. 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.

    Login or Signup to reply.
  2. 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
    $
    
    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search