Video by Learn Linux TV Be sure to check out their channel!

OpenSSH

• Run commands on a server through the terminal like you were standing right there
• Most Linux distributions have OpenSSH by default
• Uses port 22 by default

Installation

$ which ssh - Check if SSH is already installed

$ apt search openssh-client - Shows the SSH packaged the SSH utility comes from + will show if it’s installed on your device

Connecting

$ ssh user-name@ip-address - Allows you to connect with the username at the target IP address

• If you’ve never connected to the server before, you’ll get a prompt with a “fingerprint” asking if you’re sure you want to connect.

$ password prompt - Enter your password for that user-name at that server.

Running Commands

• If everything has gone successfully, you should be logged in and able to run commands on that server like you were using it directly.

CTRL + d - Disconnect from the server

Examining the SSH Files

• In your local .ssh folder, your known_hosts file will contain the fingerprints of servers you’ve connected to in the past.

  • It’s the fingerprint in this file that allows you to skip the “first time connecting to this server” prompt the next time you connect
  • This functionality also helps you avoid a “man-in-the-middle” attack, where they try to get you to connect to a host with the same IP address. The system will detect that the fingerprint has changed and prompt you again if you really want to connect if that’s the case.

• On the server, /var/log/auth.log contains a log of who (their IP address) accessed the server and when.

  • You need root access to get to the log file
  • Even if they can’t connect but attempt to, you should be able to see that in the log file

Simplifying Connections with a “config” File

• Lives in your .ssh folder
  • In the config file, structure each block as:

Host easier-to-remember-name   Hostname ip-address   Port port-number   User user-name or root

• Now when you connect, you can just do:

  • $ ssh easier-to-remember-name

• Now you don’t need to remember the host IP, Port, or Username when you want to connect

Public and Private Keys

• Use them for greater security and greater convenience
• Uses the key for authentication instead of a password
  • Can pair with disabling password-authentication to make it very difficult to access the server without the key

Creating an SSH Key

$ ssh-keygen - It will generate a RSA-type key by default - Make sure to input the file to save the key as, so you don’t accidentally overwrite an existing key - doing so may lock you out of a server - Enter a passphrase - Distinct from a password, in that it is only typed locally, and it allows you to start using the key the passphrase is assigned to. Without that, even if someone got access to the key, without a passphrase, they can’t use it

• The private key will be the file name (or default file name) you generated
  • DO NOT LET THIS ONE GET OUT
  • If it does, replace it on everything immediately
• The public key will be the file name.pub
  • Add this to the server end
  • Anyone can see this and your security won’t be compromised as long as they don’t have access to the private key as well.

Applying a Key Pair

The Long Way

• $ cat the public key
• Copy it to the clip board
• Connect to your server
• Navigate to, or create a .ssh directory
• Create or add the public key you copied into the authorized_keys file
  • You can store multiple public keys here, each go on their own line (they should only be one line long when you paste them in)
• The next time you connect to the server, you will be let in immediately without a password prompt
  • Unless you’ve set a passphrase. Then it will ask you for your passphrase to unlock use of the key
    • You can choose to always decrypt the key locally so you don’t have to enter the passphrase each time, but if someone else tries to use the key, they’ll have to enter the passphrase even if you select this option
  • The server compares its public key against your private key, which are mathematically linked, but not identical.

The Short Way

$ ssh-copy-id -i path-to-input-public-key username@IP-address - It will prompt you for your password for your username at that server

• If that’s successful, it will tell you how many keys were added. This will likely be just 1
• This command has created the authorized_keys file with the appropriate public key, just like we did manually in the long way

Managing SSH Keys

• Creating individual keys for each client to access a server helps minimize security risks. If that key falls into the wrong hands, and you gave it to every client, then someone can get into all of your clients
• The server may lock you out if you try to many keys, as will happen automatically when you have a ton of keys stored

$ ssh-keygen -t ed25519 -C "your-comment" - will create a key of type (-t) ed25519 - This type of key is both shorter and more secure than the default RSA type - Adds a comment (-C) of your choosing, otherwise it will default to “username@your-device” - Your comment can be anything and it won’t affect its function, but having a note about what it’s for can make managing your keys much easier

• Choosing a name that helps you systematically keep track of your keys can be really beneficial
  • Make sure you include the full file path to make sure the keys end up in the right place
    • e.g. /home/username/.ssh/your-logical-key-name
    • they recommend the “ClientName_id_KeyType” formate
  • Use a passphrase so that even if the key fell into the wrong hands, a malicious actor couldn’t take over their whole server or anything

Caching the Passphrase with the SSH Agent

• Will unlock the key for every connection until you close the terminal window

Starting the SSH Agent

• Especially useful to know when in a server without a GUI
  • Some people will want their key cached on a server known as a “bastard host”, and it’s there that they’ll start all of their ssh connections, rather than their own device

$ ps aux | grep ssh-agent - Won’t find anything if ssh-agent is not running

$ eval "$(ssh-agent)" - Begins the ssh-agent + displays the process id (pid)

$ ps aux | grep ssh-agent - Run this again, and we’ll see the agent running at the pid it displayed before - If you disconnect from this terminal, the ssh-agent will stop, so add your key before closing anything

$ ssh-add path-to-**private**-key - To store the private key with the ssh-agent - You will be prompted for your passphrase - But after this time, you won’t be prompted for your passphrase again until you close your terminal window

Configuring OpenSSH

• Configuring the server-side $ which sshd - Checks whether the server-side component is installed
  • This daemon runs in the background to accept ssh connections

$ systemctl status sshd - Allows you to view sshd’s status (Active? Running? Enabled to start as soon as the server starts?) - Can restart sshd with $ systemctl restart sshd - Can stop sshd with $ systemctl stop sshd - This will not terminate existing connections, but it will prevent you from reconnecting - Can start sshd with $ systemctl start sshd - Good to check the status again to make sure before disconnecting

$ systemctl enable sshd or $ systemctl enable ssh (for ubuntu/debian)

Host Keys

• In /etc/ssh
  • Don’t delete the hostkeys!
  • But if you’re cloning the server, you don’t want the same hostkeys on multiple servers, so make sure you regenerate the keys on the new server instead of using the same ones

Server-Side Configuration

• In sshd_config
  • You can change the port number
    • Un-comment the line, change the number to what you want
    • Slightly improves the security of the server by avoiding bots online that are scanning for the default port 22
      • A determined malicious actor who really wants to find the port number can do so quickly, but it helps avoid the automated scanning
  • You can set PermitRootLogin to no
    • Only do this if you have another user that you can log in as, or you’ll lock yourself out of the server!!!
    • But if you are set up to do this, changing this option to no can help keep you safe from malicious actors trying to log in as root
  • You can set PasswordAuthentication to no
    • Only set this to no if you already have the ssh key set up and functioning
    • But setting this to no hugely increases the security of the server
  • Save your changes
• Restart sshd to apply the changes to the configuration file
  • DO NOT DISCONNECT YET or you may be locked out if there was an error
  • Create a new terminal tab, and try to log in again normally first
    • Make sure you are connecting to the proper port with -p ### if you ended up changing the port in the configuration file earlier

Trying to Log In without a Key

• If you’ve disabed password authentication and try to log in without a key, it will display:
  • Permission denied (publickey).
  • Can’t brute-force the password if password login isn’t even allowed!

Troubleshooting

• A “timeout” error may mean that port 22 is not listening on the host end, or that the firewall on that side of things has blocked you
  • Will not say it’s “blocked” as that would let a malicious actor know that there is indeed a real server there
  • By saying “nothing” it’s unclear what’s going on, which slightly increases security
• The .ssh directory should only have permissions for you
  • If the group or other have permissions, you will probably get blocked and be unable to use ssh, because an ssh directory with permissions beyond your username is highly suspicious
  • If your public key permissions are not -rw-r--r-- OR
  • Your private key permissions are not -rw------- you may not be able to access ssh, as the system will detect that that is highly suspicious
    • This is true both on the client end but also on the host end
• If a user can’t connect, you can tail the log file while they try to connect and see which errors it’s throwing
  • You will also be able to see the username they’re trying to log in with
  • You can get blocked if you type in the wrong password too many times $ journalctl -fu ssh OR $ journalctl -fu sshd is another way of tailing the log file
  • Use the ssh version for Debian, Ubuntu, and other Debian-based distributions