![]() ![]() Now that your remote host and SSH client are configured with the public and private keys respectively, you should be set to login. Here’s a screenshot from Emtec’s ZOC to help you get the idea. The steps for this will vary from client to client. Maybe you’d rather store it on an encrypted thumb drive you keep in your pocket when you’re away from your desk. ssh folder, but it doesn’t have to be there. The most common place to store your private key is in your home directory in the. That will consist of configuring a specific terminal session to use the private key file, so you’re likely storing it locally somewhere.įor instance, if your client is running on your laptop, you’ll have a copy of that private key on your laptop as well. ![]() In your SSH client, configure the session to authenticate to the Ubuntu box with your username and the private key. If there is no ~/.ssh/authorized_keys file, create one and copy the contents of the public key into it. The ~ represents the home directory of the Linux user account you want to authenticate as using the keypair. On the remote host, append the text of the public key file to ~/.ssh/authorized_keys. The SSH client aka terminal software needs access to your private key. The hosts you want to authenticate to get a copy of your public key. Putting your keys in the right places means two sorts of places. You can use them anywhere you like, as long as you’ve put them in the right places. These files are not tied to a specific username or host. Think of these files as two friends that work together for, in our use case, SSH authentication. This is the one you’ll copy to remote hosts. Don’t leave it lying around in an unsecured S3 bucket, for example. You should be able to find them in ~/.ssh/ assuming a *nix sort of box such as those running a Linux distro or MacOS. When ssh-keygen completes, you’ll end up with 2 files. But for any sort of environment where the remote host should be properly protected from nefarious ne’er-do-wells, use a passphrase. For home lab environments, I suppose that’s just fine. Perhaps you want to use a key pair to avoid the tedious step of typing in a password to authenticate. If you do assign a passphrase to the private key, you’ll be prompted for the passphrase when using the private key to authenticate to a server. If you don’t define a passphrase, anyone who gets a copy of your private key–it’s just a file, after all–will be able to use it to authenticate against any server which has your public key. Give your private key a passphrase when prompted. However, be careful not to overwrite your existing key pair if the one you already have is important to you. I have not memorized all of the parameters (and hope never to do so). Plumb the depths of the ssh-keygen command and its sundry parameters as implemented on Ubuntu 18.04 here. Execute the command that follows as a bare minimum–you might want to make larger keys depending on your personal level of paranoia by adding -b. ![]() Microsoft offers instructions for Windows users here. MacOS also has ssh-keygen available in a terminal session. Create The Key PairĬreate a public-private key pair from a host with the ssh-keygen tool. What follows is a quick reference for those interested in using a public-private key pair to authenticate to a remote SSH host. The truth of the matter is, “It depends.™” The presence of this how-to should not imply that key pair authentication is decidedly more secure than a password. I have no strong opinion regarding your security posture when using one vs. simple password authentication when logging into an SSH host. The more pedantic in the tech community argue about the merits of public-private key authentication vs. This post originally appeared on the Packet Pushers’ Ignition site on February 18, 2020.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |