This section (apparently a candidate for merging with GnuPG#gpg-agent) is out of date since GnuPG 2.1 and no longer works as instructed due to the deprecation of GPG_AGENT_INFO. See https://wiki.archlinux.org/index.php/GnuPG#GPG_AGENT_INFO —This unsigned comment is by Logankoester (talk) 24 February 2015 08:55. Please sign your posts with ~~~~!
there should be a note about kwallet5 not supporting PGP, for now
- Are you sure it is the case? Can you provide some source, a bug report or something? For now we have SSH keys#Store SSH keys with Kwallet linking to KDE_Wallet#Using_the_KDE_Wallet_to_store_ssh_keys which only has a vague, unsourced "May have a bug" accuracy template. Neitsab (talk) 11:21, 21 October 2015 (UTC)
With two factor authentication (crypto keys **and** password). I achieve that pam_tally increments by 2 the user errors every time I login. So surely there is an error in the suggested configuration--Xan (talk) 12:00, 30 June 2015 (UTC)
PuTTY elliptic curve support
The development snapshots for the PuTTY SSH suite  now support elliptic curve SSH keys, including ECSDA and ED25519. It may be a good idea to update the note in SSH_keys#ECDSA to mention that this is now an option. Jwegner (talk) 04:48, 6 January 2016 (UTC)
SSH public key passphrase
Starting ssh-agent as a wrapper
In this section, there is a note which says that you "can" add eval$(ssh-agent) to your .xinitrc.
When using ssh-agent as a wrapper to startx, I have noticed that if I have both -- the alias as well as the eval statement in .xinitrc, it spawns 2 ssh-agent processes. I believe this is a leftover note from earlier when we didn't have the section titled "ssh-agent".
Can someone confirm and I will remove that note from the "ssh-agent as a wrapper section", because the way it stands today seems to indicate that you need to do both -- the alias to startx as well as add the eval statement to xinitrc in order for it to work when that is not the case.
/etc/ssh/sshd_config -- quick help for ssh-copy-id
Many people find this article via google because ssh-copy-id did not work for them. Like this is only mildly helpful.
Many of the above expect to find straight, succint info, which is given right here:
1. You do not want to enter a strong password to ssh into your remote webserver, so you use keyfiles (/home/YOU/.ssh/id_rsa.pub) instead.
2. You ran ssh-keygen OK.
3. Then you ran ssh-copy-id with error and ssh with error as well. So you cannot (immediately) ssh into your webserver anymore. :-(
4. Even on (Jessie) debian to debian systems, ssh-copy-id often breaks. (see google for proof)
5. ssh-copy-id performs a very simple task which is easy to do manually instead using fish and midnight commander (mc): you need to copy or append your local file /home/YOU/.ssh/id_rsa.pub to the remote file /root/.ssh/authorized_keys . It can be done with cp ./key1 ./authorized_keys as remote root in /root/.ssh/ or in case of multiple keys cat ./newkey >> ./authorized_keys
6. also run chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys in the remote root shell.
7. But this will only work if the remote sshd is set up properly to begin with. Your local ssh talks to the remote sshd. Use ssh -vvv to bughunt. Verify that the remote server /etc/ssh/sshd_config allows password-less ssh by switching from no to yes etc. e.g.:
RSAAuthentication yes # applies to protocol version 1 only
PubkeyAuthentication yes # this one being germaine
# For this to work you will also need host keys in /etc/ssh_known_hosts
8. That's it. reboot or sshd restart usually is not necessary. You now can log in without a password. So you might disable passwords on the remote webserver now to mitigate remote passwords attacks. But passwords are still helpful if you lose the keyfile or do not have it at hand on a different local machine. In any case you can force the use of passwords, e.g. for testing with
ssh -o "PasswordAuthentication yes " -o " PubkeyAuthentication no " email@example.com
- This page deals with SSH keys in general, not only ssh-copy-id. The topic in question is described in the third section and troubleshooting naturally belongs to the end. Satisfying some specific search results or users of other Linux distributions is not the primary concern here and definitely not a sole reason to move something to the start of the page. As for your configuration sample, all options are either irrelevant (see e.g. ) or default. Closing. -- Lahwaacz (talk) 16:03, 10 February 2017 (UTC)