I did a write-up on setting up passwordless ssh negotiation and was going to post it in this thread. But, as may be evident from reading the thread, it turns out I was functioning under some misconceptions that would have resulted, were I to have posted that original write-up, in the promotion of certain erroneous conceptions concerning the task at hand. So what I've decided to do is to provide a link to a write-up someone else did, one that offers a pretty good explanation, with examples, of setting up passwordless ssh negotiation. I then offer some of my own observations on performing this task and suggest a few of what seem to me advisable modifications. Hence, the following.
https://www.tecmint.com/ssh-password...-5-easy-steps/ provides a pretty good guide for setting up truly passwordless ("truly passwordless" meaning you are not prompted to enter any passphrase) ssh negotiation that even us dimwits should be able easily to follow. I should mention that the method described there is frowned upon by computer security proponents. As I understand it, it's frowned upon because the resulting private key that resides on your computer will not be encrypted because you did not protect it with a passphrase when the key was created--see step 1. b. of that tutorial ("empty passphrase"). Meaning that anyone who can get access to your files can simply cat your private key to a file or to stdout, thereby enabling them to steal it and compromise the security having a key pair is supposed to provide. I would only add to those directives that, if you've already generated a key pair and encrypted it with a passphase, then to get the truly passwordless method described there to work, you'll need to remove the passphrase by issuing a command like ssh-keygen -p /path/to/private/key.
If your dimwittery does not extend too far into the realm of computer encryption and you share the security concerns of those who recommend against creating keys that are unprotected by a passphrase, you should protect your keys with a passphrase and use a utility like keychain so as to set up what I would characterize as semi-passwordless ssh negotiation. Using that tool, you will need to enter the passphrase you used to encrypt your private key only once each session (for most of us, that will mean each time you boot your computer). This is what I did for my systems, adding a line something like
Code:
eval $(keychain --eval --quiet id_ed25519 id_rsa ~/.keys/my_custom_key)
to the appropriate file (.bashrc or .bash_profile, depending on distro) as advised on the Arch wiki (see
https://wiki.archlinux.org/index.php/SSH_keys#Keychain)
The only other thing I would add here is some information on how I set this up on my little LAN, where I am often ssh'ing from one or other of 3 computers into another on the same LAN. For my scheme, I created on each computer keys that were alternately named--according to host name in my case. I also took the additional crucial step of crafting appropriate .ssh/config files on each machine so as to make initial set up and, later, initiation of sessions, more comprehensible.
In order to do that, when I was asked for a name and location for each key pair I was generating on the different machines, I specified a more identifiable name than the default (id_rsa was the default in my case)--for example involving a host name such as machine1, as in /home/user/.ssh/machine1.rsa. Be aware that, if you use a name other than the default, you will need to either initiate your ssh session using the -i switch and stipulating the full path to the alternately-named private key, or you will need to edit your .ssh/config file to indicate the path. In the example I've just provided, the public key that needs to be copied to the remote server will be named machine1.rsa.pub.
Since I have 3 or 4 machines from/to which I need to ssh on a regular basis, and since the difficulties I have with conceptualizing client/server scenarios are further exacerbated with the introduction of the encryption element, I prefer to name my keys in ways that help me to better distinguish which keys relate to which machine. Thus, I would want to end up with key pairs named something like home.rsa/home.rsa.pub on one machine, office.rsa/office.rsa.pub on another, laptop.rsa/laptop.rsa.pub on yet another, and so forth. Since issuing these modified names from the command line in the form ssh -i ~/.ssh/office.rsa user@remote is rather unwieldy, I modified/created the .ssh/config file on each machine in order to better automate the negotiation process. That can be done in the following way (note that the following step is necessary in order for this type of semi-passwordless ssh session to be initiated: the system
must be able to find the renamed id_rsa file or you will be stuck with username/password logins or, should you have disable those types of logins, might even wind up being locked out of your remote system).
On the local machine--in this example, my laptop--using a series of commands from within the .ssh directory such as
Code:
echo "Host office" >> config
echo "Hostname office" >> config
echo "IdentityFile ~/.ssh/laptop.rsa" >> config
allowed me, once I had copied over laptop.rsa.pub to the remote machine (host name "office") and cat'd it to ~/.ssh/authorized_keys on that remote computer, to ssh to that remote machine by simply issuing
Or even just
, should my username on the remote machine be the same as the username on the local machine. Note further that the IdentityFile being placed in .ssh/config is the one located on the local machine.
I apologize. I really wanted to make this guide as simple as possible--so that even I could, on a quick skim, readily understand and implement it. But the matters touched on are so complex and recondite that what I've come up with is the simplest presentation I could manage at the moment.
