SSH stands for Secure Shell, and it's a network protocol whose primary purpose is to allow you to securely connect to a system over a network. You can connect via SSH using your username and password, however SSH also allows you to authenticate by using a key. To allow key authentication, be sure that PubKeyAuthentication is set to yes, in the /etc/ssh/sshd_config file. You can generate an SSH key using the ssh-keygen command. When you execute this command, it will ask you to enter a passphrase. You can also simply hit enter and not use a passphrase on your key. The advantage of using a passphrase is that if someone were to gain access to your key they would have to know the passphrase to the key before they could use it. The downside to using a passphrase is that it makes automation difficult in cases where you want to automate an unattended SSH connection. The ssh-keygen command creates two files. One is the private key and the other is the public key. By default, these are stored in the .ssh sub-directory of your home directory. If you use the ssh-keygen defaults, they will be named id_rsa and id_rsa.pub. It's important that you protect your private key. The public key is stored on the system you wish to connect to. Use the ssh-copy-id command to copy the public key to a remote system. This command will upend the public key to the .ssh/authorized_keys file on the remote host. Now you'll be able to authenticate using your SSH key. If you want to disable log-ins using this key pair, simply remove the public key from the authorized keys file on the remote host itself. If you want to enforce the use of keys for authentication, then set password authentication to no in the etc/ssh/sshd_config file. This protects you against brute force attacks because even if an attacker knows the account password, SSH will not allow them to connect with that password. When you create a new account on the system, you have the user create an SSH key pair and then have them share that public key with you. They can keep the private key to themselves. You don't need that. That is their private key. Then you install that public key into their .ssh/authorized keys file which will allow them to connect to the system. If you want to disable root log in, set PermitRootLogin to no in the sshd_config file. If you only want to allow SSH connections from root with keys, set permit root log in to without dash password. You can also restrict SSH access for other users. If you want to specify which users are allowed to connect via SSH, use the AllowUsers directive and list the allowed users separated by a space following the AllowUsers directive. You can also control SSH access by Linux group. Use the AllowGroups directive followed by a group or a list of space separated groups. Now only members of those groups will be allowed to log in via SSH. You can do the reverse, which is to list specific users or groups that will be denied. Use the DenyUsers and DenyGroups directors for this type of configuration. SSH can be used to forward TCP connections. Let's say my SQL databases running on server one and it's bound to the loop back address on port 3306. Connections from the outside world to port 3306 will not be accepted because my SQL is not listening on the outside network interfaces for connections. You can have SSH forward connections from a port on your local system to a port on or through the remote system. In this example, I could run SSH space-L space 3306 colon 127 .0.0.1 colon 3306 space server one. Now I could use my SQL client to connect to port 3306 on my local system, and that connection would be forwarded via SSH to server one and delivered to port 3306 on the IP of 127.0.0.1 which is the loop back address of server one. The advantages to this are one that I can use a client on my local machine to access the remote machine, and two, that traffic is encrypted by SSH. That might be okay if that's what you want to allow. However, the downside is that now there is a connection from the outside world into that server on port 3306. Unless the machine that is connected via SSH is using a local firewall, someone else could connect a port 3306 on that system and end up getting access to the database on the remote server. You can also afford TCP connections through a system. For example, let's forward all the local traffic on port 8080 to google.com port 80 through server one. To do that, I would run SSH space -L 8080 colon google.com colon 80 space server one. Now Google thinks that connections are originating from server one, even though they are actually originating from another system. You can even take this a step further. Let's forward all of our web browser traffic through server one. To do that and use the -D option to enable dynamic port forwarding. Here I just simply run SSH space-D provide a port number 8080 in this case, and then the server I want to connect to which is server one. Now, configure your web browser to user socks proxy. Use your local system address or 127.0.0.1 in port 8080. Now, all of your web browsing traffic gets tunneled through server one. Again, if there is no local firewall on your system, then other people can connect through it and that traffic will be funneled to the outside world through server one. You can even use SSH to forward connections from the remote system back to your local system. For example, to make server one, listen on port 2222 and then forward all that traffic back to my local system on port 22, I would run ssh space -R 2222 colon 127.0.0.1:22. If I leave this SSH session running, I could go home or to a coffee shop or wherever and connect to the server on port 2222 which would then tunnel that connection back to my original system in the office on port 22 and I could log into my machine. From there, I would have a shell and I would be on the local network inside my company's firewall. This is another reason why you should use a local firewall on your Linux systems. This scenario assumes that connections from the outside world destined for port 2222 make it to the server, and that that server is not blocking port 2222 either. As you can see, allowing TCP forwarding is definitely a security concern. To disable TCP port forwarding, set allow TCP forwarding to no. If you decide to allow TCP forwarding, at least make sure to set gateway ports to no. This setting controls whether or not remote hosts are allowed to connect to ports forwarded for the client. Setting gateway ports to no, blocks those remote connections to the forwarded ports.