From one day to another, our company server started to ask me for my SSH password.

First thing that I checked was to see if my key was inside .ssh/authorized_keys on the server. My key was inside, nothing changed. Also in /etc/ssh/sshd_config nothing has changed.

Then I tried to do this procedure on freshly installed Ubuntu16 server. After completing these 5 steps, new server asked me again for SSH password.

The ssh-copy-id command has finally accomplished keyless SSH login, but I have noticed that that .ssh/authorized_keys has three lines: one starting with ssh-dss and 2x starting with ssh-rsa

Now I remember that 5 steps procedure from the link above has worked in the past with only one key.

Has something changed recently? Why procedure from above does not work anymore?

Edit: Since ssh-copy-id copies altogether 3 keys to .ssh/authorized_keys those keys can be found in following files:




so I deleted line by line from remote's .ssh/authorized_keys file

deleted ~/.ssh/id_dsa line - auto login succeeded

deleted ~/.ssh/id_rsa.pub line - auto login succeeded

deleted ~/.ssh/sshkey.pub line - auto login not succeeded - asked for password

Only content from ~/.ssh/sshkey.pub is necessary. Why SSH is comparing sshkey.pub and not id_rsa.pub like in the example from online tutorial?

  • Certainly not because of any fundamental changes to authorized_keys file or I would have woken up one day to find myself locked out of a whole bunch of machines.
    – B Layer
    Jan 24, 2018 at 11:21
  • what kind of key, and how many bits? the server you're having problems with may have higher standards, possibly due to an upgrade of sshd. 1024 bit RSA used to be considered acceptable. nowadays 2048 or 4096 bit are required.
    – cas
    Jan 24, 2018 at 11:33
  • also, please add the output of ssh -v your-remote-server to your question.
    – cas
    Jan 24, 2018 at 11:36
  • Do you still have the 640 flags on authorized_keys or something more restrictive (600)?
    – xenoid
    Jan 24, 2018 at 11:55

1 Answer 1


It seems that ssh-copy-id is merely a convenience function. It checks whether the keys were already exported to the machine, it creates .ssh directory if necessary, but basically it just adds public keys to .ssh/authorized_keys. ssh-copy-id is a shell script (in openssh), so you can read its code (vi `which ssh-copy-id` ) in the end:

[ "$DRY_RUN" ] || printf '%s\n' "$NEW_IDS" | \
  ssh "$@" "exec sh -c 'cd ; umask 077 ; mkdir -p .ssh && { [ -z "'`tail -1c .ssh/authorized_keys 2>/dev/null`'" ] || echo >> .ssh/authorized_keys ; } && cat >> .ssh/authorized_keys || exit 1 ; if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh .ssh/authorized_keys ; fi'" \
  || exit 1

During authentication only authorized_keys are checked. From openssh documentation:

The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The client proves that it has access to the private key and the server checks that the corresponding public key is authorized to accept the account.

I hope this answers your question title "ssh-copy-id versus manual copy id_rsa.pub". This file ~/.ssh/sshkey.pub I don't have, so I hope you solved the problems with your setup yourself. Anyway, yes, you can just manually copy the public key to authorized_keys not using ssh-copy-id.

UPD: in 2020 (OpenSSH 8.2) RSA SHA-1 keys became deprecated. Alternatives should be used (see the link).

  • 1
    Note that the actual RSA algorithm is not getting deprecated, just the use of SHA1 hash function that was originally specified to be used with it. With older versions of OpenSSH, ssh-keygen -t rsa would have created a rsa-sha1 key, which is now being deprecated. New versions will instead generate rsa-sha2-512 keys by default. By specifying -t rsa-sha2-256 you can get a reduced-length version if necessary for performance, or with -t rsa-sha1 you can get a classic RSA key that is now being deprecated, if you absolutely need one. The default name for the key will still be id_rsa[.pub]
    – telcoM
    Sep 28, 2021 at 8:36
  • @telcoM thank you, I fixed my update! That was written wrongly in the link I found. In the current formulation this update may make little sense. However, I decided to leave that here, because I faced this problem with RSA keys on exactly one machine (connecting to exactly one server). I solved this problem by updating autossh on the server. Sep 28, 2021 at 12:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .