Cannot login without password even with SSH key

Question

I have 2 shell accounts ont 2 different hosts:

• shell A: shell I want to login using a SSH key (server-A.com)
• shell B: shell I'm using to login to A without a password but using SSH key (server-B.com)

I emailed the server-A.com sysadmin who gave me the bellow tutorial URLs.

I've done the following:

• Created a private/public SSH key on server-A.com using ssh-keygen -t rsa -C [email protected] and put the private key on server-B.com in ~/.ssh/server-B.com
• I ran chmod 700 ~/.ssh/ and chmod 600 ~/.ssh/server-B.com

• I added server-A.com public key to to ~/.ssh/authorized_keys on server-B.com

  $ cat ~/.ssh/server-B.com.pub >> ~/.ssh/authorized_keys     # on server-B.com
  

• I've checked ~/.ssh/config (no) and /etc/ssh/ssh_config which contained the following (other # comment lines not printed)

  #   PasswordAuthentication yes
  SendEnv LANG LC_*
  HashKnownHosts yes
  GSSAPIAuthentication yes
  

  From shell B:

  $ ssh-keygen -f "/home/username/.ssh/known_hosts" -R server-A.com
  

NOTE: I followed the tutorials on https://kb.iu.edu/d/aews and https://www.digitalocean.com/docs/droplets/how-to/add-ssh-keys/create-with-openssh/.

What went wrong?

Answer 1

You only need the private key on B to log into A. Don't generate the key on the remote A system. A remote system does not need to know your private identity.

You are wanting to log into the A system from B. This means that the ~/.ssh/authorized_keys on the A system should contain the public key (to allow you to enter). The B system does not need this file locally for you to log into A.

Note that you will have to make sure that the ~/.ssh on both hosts has 700 permissions and that the files within has 600 permissions (including ~/.ssh/authorized_keys on A).

Also, to actually use the key in the file ~/.ssh/server-B.com on B to log into A, you would have to use ssh as

ssh -i ~/.ssh/server-B.com  [email protected]

Alternatively, start an ssh-agent and add the key to it:

eval "$( ssh-agent )"
ssh-add ~/.ssh/server-B.com

ssh [email protected]

And/or, add an entry in ~/.ssh/config on B for the A system like

Host A
    User a-user
    Hostname server-A.com
    IdentityFile %d/.ssh/server-B.com

and then use

ssh A

You could also just use the default name of the key file, unless you have other private keys already.

Answer 2

Well, you didn't get everything wrong, only part.

To use client authentication by publickey (crypto) in SSH:

• you must have the privatekey file on the client -- your B.

  Best practice is to generate the key on the client. What you did, generate on the server and copy, is not recommended, but will work.

  Best practice is to use the standard filenames (depending on 'type' aka algorithm) on the client -- ~/.ssh/id_rsa for RSA (in v2), ~/.ssh/id_ecdsa for ECDSA, etc. ssh-keygen would do this by default if run on the client. Using a different name like you did means that you must specify the filename every time you run ssh, like ssh -i ~/.ssh/server-B.com user@host [command...], or else set up your config file to specify this as your IdentityFile (either globally or for the particular host).

  The privatekey file must be inaccessible by other users. AFAICS your chmod's got that right.

• you put the publickey in ~/.ssh/authorized_keys ON THE SERVER -- your A.

  Using cat >> is generally good, as it retains any existing content and appends the new line. If there are existing lines that (you are certain) are obsolete -- for keys, or users, that are no longer in use or authorized -- you may want to delete them to keep things tidy, but it isn't necessary.

  And the authorized_keys file must be unwritable by other users. This may or may not be the default on your system; if not, use chmod in the same way as you did for the keyfile.

• removing the entry for the server (A) from the known_hosts file on client (B) is needed only when the server key is changed, or obsoleted. It is unrelated to client authentication. Doing so unnecessarily, if you aren't careful to manually check the server key fingerprint when next asked, may provide an opening for an attacker to intercept, steal, and alter your data.

So, if you fix authorized_keys on the server (A) and run ssh -i ~/.ssh/server-B.com user@serveraname on the client (B), and if asked verify the server fingerprint, it should work. If it doesn't, run with several -v options as commented by Haxiel to get details. In particular if it doesn't seem to see the specified keyfile (aka identityfile), recheck the permissions with ls -l.

Answer 3

There should be a publickey authentication option on the host in the file /etc/ssh/sshd_config. Uncomment and set to yes

Ensure you are editing /etc/ssh/sshd_config on the host, not /etc/ssh/ssh_config. The second files is for clients only

If needed, contact the admin of host A