0

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 username@server-A.com 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?

  • Running your ssh commands with the -vvv option will provide a lot of debugging information that can narrow down the problem. – Haxiel Mar 9 at 4:34
0

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.

0

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  a-user@server-A.com

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

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

ssh a-user@A-system.com

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.

0

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

  • The fact that the admin on A gives them a tutorial should be evidence enough that public key authentication is a valid method already. – Kusalananda Mar 9 at 10:00
  • @Kusalananda from what I saw, they were editing the wrong file. Although it may be valid, unless there is a typo, they will never get it enabled. They said they are editing ssh_config, not sshd_config – linuxandria Mar 9 at 12:47
  • The user clearly does not have access to the sshd_config on the A host. In any case neither ssh_config nor sshd_config should need any edits on either system. – Kusalananda Mar 9 at 12:59
  • @Kusalananda well, in that case, there is probably no way to get keys up and running. If the entry is wrong (which to me looks like it is) there is no way to fix it without contacting the server admin – linuxandria Mar 9 at 13:03
  • checking ~/.ssh/authorized_keys I realised that it was ~/.ssh/authorized_keys.temp as I renamed to keep a backup while doing other operations and forgot to rename it back. this is my mistake, sorry for that and tank's for your help – user2901196 Apr 7 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.