2

I'm fairly new to the Linux world and I'm setting up an Ubuntu server 16.04.

I was able to generate keys using ssh-keygen and saved the key in /home/ther4nd0moo/.ssh/id_rsa

I then used ssh-copy-id ther4nd0moo@my_ip and made sure that the authorized_keys file is in the right place.

When I use ssh -v ther4nd0moo@my_ip on a different computer, some weird things pop up (to me at least)

OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 10.0.0.189 [10.0.0.189] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/edgar/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/edgar/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/edgar/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/edgar/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/edgar/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/edgar/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/edgar/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/edgar/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.0.0.189:22 as 'need206'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
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:YzQwUoOherHwxOOhzEhue7ecx+OMi0FpmIcSONi8X1o
debug1: Host '10.0.0.189' is known and matches the ECDSA host key.
debug1: Found key in /home/edgar/.ssh/known_hosts:3
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/edgar/.ssh/id_rsa
debug1: Trying private key: /home/edgar/.ssh/id_dsa
debug1: Trying private key: /home/edgar/.ssh/id_ecdsa
debug1: Trying private key: /home/edgar/.ssh/id_ed25519
debug1: No more authentication methods to try.
Permission denied (publickey).

What's bugging me is how it's looking for the identity file and private key at /home/edgar/ (edgar being my name that I put in when installing the server). In an attempt to solve this, copied the key contents from /home/ther4nd0mmoo/.ssh and created the folder /home/edgar/.ssh which is probably why it has the message Found key in /home/edgar/.ssh/known_hosts:3 but I still can't access the server.

I tried ssh -i /home/ther4nd0moo/.ssh/id_rsa ther4nd0moo@my_ip and my terminal says that it is not accessible: No such file or directory

Am I doing something wrong?

Zanna
  • 70,465
ther4nd0moo
  • 23
  • 1
  • 4

1 Answers1

3

SSH keys work by having a Private key on your local machine, and a corresponding Public key on the remote machine.

So - when you ran ssh-keygen, you created 2 keys: the Private (~/.ssh/id_rsa) and the Public (~/.ssh/id_rsa.pub).

You need to copy the contents of the Pubic key file (~/.ssh/id_rsa.pub) from your Local machine, into the ~/.ssh/authorizedkeys file on the Remote machine. Just add it to a new line.

If you are logging into your Remote machine from a DIFFERENT Local machine, then you'll need to either copy the id_rsa file from the original machine to the 2nd Local machine, or (better) create another private/public key-pair for the 2nd Local machine, and then copy the Public key for the 2nd machine to your Remote server.

The Remote server can have any number of Public keys in ~/.ssh/authorizedkeys, and it's good practise (I believe) to have a different key-pair for each of your Local machines.

If you need to ssh from the REMOTE machine to another machine (say if you have to ssh back from the Remote machine to your laptop), then you would setup the REMOTE machine with it's own private/public key-pair, and copy the Remote machine's Public key to the Laptop's ~/.ssh/authorizedkeys file.

Think of it like this: Every machine can have a doorkey (the private key), and every other machine has a keyhole (the authorizedkeys file) - if another machine has a keyhole setting that your key fits into, you can gain access. To work in the reverse direction, you need to setup another key and keyhole settings. (probably not very well explained - but I hope it helps!).

The ssh-copy-id command is basically just a short cut command to save doing it manually.

I personally prefer to copy the public key manually just because I like doing things the hard way. ;)

Zanna
  • 70,465
JamesBB
  • 198
  • THANK YOU SO MUCH!

    I didn't understand that I needed the key in my laptop! It makes a lot of sense now that my laptop needs the "key" to the server.

    – ther4nd0moo Mar 31 '17 at 08:25
  • The easiest way I've found is to temporarily allow password logins, and then follow the exact procedure you followed in your question (generate keys, ssh-copy-id) but from the REMOTE machine, ie the one you'll be using to log in to the server. That copies your key into the relevant authoriszed_keys file, and you can then try to log in via the key before disabling password authentication again – Will Mar 31 '17 at 09:00
  • Definitely! I'll be using that when I have other computers that need access to the server. – ther4nd0moo Mar 31 '17 at 09:05