Connecting to a Linux server using ssh is a very common thing to do. It's also very secure. By using ssh keys, however, you can further secure your Linux server from things like brute force attacks at your ssh port. Once you have ssh keys set up from any/all workstations that you're going to connect from, you can then change the config on the server to disable password authentication. When PasswordAuthentication is disabled, someone attempting to log in via ssh won't be able to get in unless they have a pre-configured key - even if they use the correct combination of username and password. First things first, let's set the two machine names for this article. This article assumes each machine is running some flavor of Linux. If you're attempting to generate a key in Windows, we'll have to hope someone replies with instructions in a comment since I don't have a Windows machine to test on. Workstation hostname: w1 Server hostname: s1 Open a termal on w1 as the user you will be using to connect to s1. Generate your ssh key by typing the following: Code: ssh-keygen Next, unless you want to enter a passphrase, you'll likely want to hit enter a few times to accept the default answers... you'll get output similar to this: Code: [email protected]:~$ ssh-keygen Generating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Created directory '/home/user/.ssh'. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: SHA256:NCHasOAxyQXtSvi5bUjAmuK3CwnbqbEE2ufDqUB6FIo [email protected] The key's randomart image is: +---[RSA 2048]----+ | .=.o . . | | .o+.= . . | |..o.o . o | |=o.o. . . | |EB.o . S | |O**. | |*=*=.. | |.B++* | |o o+o. | +----[SHA256]-----+ Congrats! You've just created your ssh key! Next, let's see your public key - cat the file ~/.ssh/id_rsa.pub to take a look: Code: cat ~/.ssh/id_rsa.pub ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxaYddE93v3PXyGKt74gDNZ3NX8ejIOSwGQgkKvQ0Cb7qvszfGf+edzRn55ph45Tro3FF1jGppdh/SVHfif8t8mE0s0TQllx+sdbmjI316S6/olMcVMSfBsycBPKcLQ1M1FFNiVDjPMIIpB1HxiJNRh5HTbYoaFdf7aGy87N/sh7lIK2HHjHAGM0fClAaptiAI38HJ6AHXFwo57rZqZ4UHE3mjB4KpAQu0FmykTVfvWXjRywt+rZxf8Z3/A/CiG4q7hzrixpGfScgWF/xPOPtedH3DT823AiJXIdFvoDp/4tSjk4susFawGyKqW8vAYSCoRT2BFMwKpHvsaasDwQlv [email protected] Moving along, ssh into your server (s1) and see if there's an .ssh directory already. If there is no .ssh directory in your home directory, create it and set its permissions: (on s1 now) Code: mkdir ~/.ssh/ chmod 700 ~/.ssh/ Next, if it doesn't exist, create the authorized_keys file within the .ssh directory and paste in the id_rsa.pub from above (no extra whitespace please!). You also want to make sure you change the permissions (chmod) of that file afterwards: Code: chmod 600 ~/.ssh/authorized_keys If you cat the authorized_keys file, it should show your pasted key at the bottom there. Now, attempt to ssh in from w1 to s1 again. It should let you right in without prompting you for a password. (log in to hide this advertisement) Set up keys on any other workstations you have by following the instructions above. Each key (id_rsa.pub) will be pasted under the previous one in the authorized_keys file. You can put comments above your various keys if you like so you know which machine they belong to by putting a hash in front of it: Code: # John's key added by Rob April 17th 2017 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxaYddE93v3PXyGKt74gDNZ3NX8ejIOSwGQgkKvQ0Cb7qvszfGf+edzRn55ph45Tro3FF1jGppdh/SVHfif8t8mE0s0TQllx+sdbmjI316S6/olMcVMSfBsycBPKcLQ1M1FFNiVDjPMIIpB1HxiJNRh5HTbYoaFdf7aGy87N/sh7lIK2HHjHAGM0fClAaptiAI38HJ6AHXFwo57rZqZ4UHE3mjB4KpAQu0FmykTVfvWXjRywt+rZxf8Z3/A/CiG4q7hzrixpGfScgWF/xfAEhr3HOZT823AiJXIdFvoDp/4tSjk4susFawGyKqW8vAYSCoRT2BFMwKpHvsaasDwQlv [email protected] # Larry's key added by Rob May 2nd 2017 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCxaYddE93v3PXyGKt74gDNZ3NX8ejIOSwGQgkKvQ0Cb7qvszfGf+edzRn55ph45Tro3FF1jGppdh/SVHfif8t8mE0s0TQllx+sdbmjI316S6/olMcVMSfBsycBPKcLQ1M1FFNiVDjPMIIpB1HxiJNRh5HTbYoaFdf7aGy87N/sh7lIK2HHjHAGM0fClAaptiAI38HJ6AHXFwo57rZqZ4UHE3mjB4KpAQu0FmykTVfvWXjRywt+rZxf8Z3/A/CiG4q7hzrixpGfScdfk442OPteAHOZT823AiJXIdFvoDp/4tSjk4susFawGyKqW8vAYSCoRT2BFMwKpHvsaasDwQlv [email protected] Now, let's secure your server a bit by allowing just keyed logins! Once you've tested all of your keys, log back into s1 and edit your sshd_config file. Modify this line: (/etc/ssh/sshd_config most likely) Code: PasswordAuthentication yes to this: Code: PasswordAuthentication no Then, restart ssh: Code: service sshd restart or: Code: /etc/init.d/sshd restart or: Code: systemctl restart sshd.service Now, the only way anyone is sshing into that server is by using a key. You'll still see login failures but won't have to worry so much about them as long as they're via ssh (and most will be).