2

One colleague has worked on a server, and written ssh root@xxx.xxx.xxx.xxx and the password in our documentation.

I just did ssh-keygen on my machine, and tried to do ssh -v root@xxx.xxx.xxx.xxx from my machine, but I got the following error.

Does anyone know how to fix it?

OpenSSH_7.6p1, LibreSSL 2.6.2
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 48: Applying options for *
debug1: Connecting to xxx.xxx.xxx.xxx port 22.
debug1: Connection established.
debug1: identity file /Users/softtimur/.ssh/id_rsa type 0
debug1: key_load_public: No such file or directory
debug1: identity file /Users/softtimur/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/softtimur/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/softtimur/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/softtimur/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/softtimur/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/softtimur/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/softtimur/.ssh/id_ed25519-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.6
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Ubuntu-10
debug1: match: OpenSSH_7.4p1 Ubuntu-10 pat OpenSSH* compat 0x04000000
debug1: Authenticating to xxx.xxx.xxx.xxx:22 as 'root'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:Pw4cFx5c2WGJzTwTL+gsx3AMHMEuT0sei1fz5oGCrac
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the ECDSA host key.
debug1: Found key in /Users/softtimur/.ssh/known_hosts:4
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:EL7hm5LvdVADZiv662nneDEeoLKy+etj8OT61eugu4Y /Users/softtimur/.ssh/id_rsa
debug1: Authentications that can continue: publickey
debug1: Trying private key: /Users/softtimur/.ssh/id_dsa
debug1: Trying private key: /Users/softtimur/.ssh/id_ecdsa
debug1: Trying private key: /Users/softtimur/.ssh/id_ed25519
debug1: No more authentication methods to try.
root@xxx.xxx.xxx.xxx: Permission denied (publickey).

Does anyone know how to fix this?

Edit 1:

In my local mac, curl ipecho.net/plain ; echo returns 175.169.13.102. I managed to open a console from the droplet of Digital Ocean of A, then I did ssh-keygen, then in the console, I did ssh-copy-id softtimur@175.169.13.102 which returned the follows; password was not asked.

I still cannot believe a server can write files to my local mac as if my local mac was a server...

enter image description here

SoftTimur
  • 1,377

2 Answers2

1

An example of a way to deploy the public-key authentication method is the following. Assume you have servers A (the server; the one you want to connect to) and B (the client; the one from whom you want to connect to A using the public key).

  1. On A, run the following command:

    ssh-keygen

    • This will generate a private-public key pair, if run without arguments, it will do so under ~/.ssh.

  2. On A, run:

    ssh-copy-id [user@]<Bs-IP-address>

    • This will copy the public key generated by A to B. It will do so in a file called ~/.ssh/authorized_keys.

    • If this does not work due to connectivity problems or you simply can't connect from point A to B, there's an alternative (manual) way of doing so. In your machine A, go to your ~/.ssh directory and find your public key file. This will probably be a file with the .pub extension. Open it and copy the content, and in B append/paste it into your ~/.ssh/authorized_keys file. Very important: This file has to be owned by the user, the group has to be the user's and have permissions 600. Otherwise it will not work. This is pretty much what ssh-copy-id does.

  3. From B, try to connect by SSH to A.

A few things to note:

  • The command in point 2 will deploy the public key to the remote user you're connecting to only. That means that if you deploy the key to the home of tom, a user whose username is jerry won't be able to use it. In short, the deployment is per-user.
  • If you're trying to deploy the key to connect to A with root, make sure the PermitRootLogin directive in /etc/ssh/sshd_config has either a value of yes or prohibit-password (preferably). If set to no, public method authentication will not work.
  • Never share a private key with anyone.
nKn
  • 5,832
0

The above answer (and the comments of its author) has some flaws: It mixes up roles of server and client. As this answer is (as judged by moderating co-members) diverging too much from the original to be accepted as a mere edit, it is posted here in its entirety:

A possible way to deploy the public-key authentication method is the following: Assume you have a SSH server A (the server that you want to connect to) and the SSH client B (the client; the system from which you want to connect to server A using public key authentication).

  1. Generate a personal public/private pair of keys on client B.

    • On B, run the following command:

      ssh-keygen

      • This will generate a personal private-public key pair on the client B, if run without arguments, the keys will be stored in ~/.ssh.

  2. Deploy your public key on the server A.

    • On B, run:

      ssh-copy-id [<user-on-A>@]<A's-IP-address>

      • This will copy your public key (generated by you on B in step 0) to A. It will do so in a file on A called ~/.ssh/authorized_keys. In order to authenticate to A during this process you have to provide other credentials, e.g. a username/password combination. (The server has to allow this login method.)

    • If you can't connect or login to server A that way, you can manually transfer your public key onto server A by whatever means that work for you. On the client B you find public key in a file probably ending in .pub in your ~/.ssh directory. The content (a line of plain ASCII text) has to be appended to the file ~/.ssh/authorized_keys on server A.

      Very important: This file has to be owned by the user, the group has to be the user's and have permissions 600. Otherwise it will not work. This is pretty much what ssh-copy-id does.

  3. From client B, try to connect by SSH to server A.

A few things to note:

  • The fact that you have been able to deploy one of your public keys to an account on server A (into its ~/.ssh/authorized_keysfile, that is), is enough prove for server A, that you will be allowed to login to that account by proving that you know the secret key (which stays on B) matching the public key. To put it simplified: During SSH public key authentication your client signs a challenge, the server verifies the signature using the public key.
  • If you're trying to deploy the key to connect to A with root, make sure the PermitRootLogin directive in /etc/ssh/sshd_config has either a value of yes or prohibit-password (preferably). If set to no, public method authentication will not work.
  • Don't share a private key with anyone.
x a
  • 107