Randy-Jordan/md
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

added ssh guide

Browse Source
This commit is contained in:
Randy Jordan 2024-11-03 16:06:31 -06:00
parent 588e211a81
commit c2dcee9cd9
Signed by: Randy-Jordan
GPG Key ID: D57FA29E3B54663E
7 changed files with 1533 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
README.md
View File

@ -13,8 +13,11 @@ This repository contains guides and notes written in markdown.
## Features / TODOS ## Features / TODOS
- [ ] SSH Server - [x] SSH Server
- [ ] Postgresql
- [ ] Gitea
- [ ] Nginx
- [ ] Solidworks
## Usage ## Usage
Each project or subject should have it's own folder with a descriptive name. It will contain a README file that is the subject of the folder. It will also contain a resources folder that contain media for the guides/notes.<br> Each project or subject should have it's own folder with a descriptive name. It will contain a README file that is the subject of the folder. It will also contain a resources folder that contain media for the guides/notes.<br>

88
ssh_server/README.md Normal file
View File

@ -0,0 +1,88 @@
# SSH Server
Walkthrough of setting up and securing SSH Server.
## Table of Contents
- [Step 1 - Upgrading the Server](#step-1---upgrading-the-server)
- [Step 2 - Creating a new User](#step-2---creating-a-new-user)
- [Step 3 - Removing Root Login](#step-3---removing-root-login)
- [Step 4 - Recommended - SSH Keys](#step-4---ssh-keys)
- [Step 5 - Copying The Public Key to the Sever](#step-5---copying-the-public-key-to-the-server)
- [Step 6 - Disabling Password Authentication](#step-6---disabling-password-authentication)
- [Step 7 - Setting up UFW](#step-7---setting-up-ufw)
- [Step 8 - Setting up Fail2ban](#step-8---setting-up-fail2ban)
- [Resources/Credits](#resources)
### Step 1 - Upgrading the Server.
First thing we should do is update and upgrade.
`sudo apt update`<br>
`sudo apt upgrade`<br>
`sudo apt autoremove`<br>
### Step 2 - Creating A New User.
Now we need to create a user so we can login via ssh.
`sudo useradd -m newusername`<br>
`sudo passwd newusername`<br>
### Step 3 - Removing Root Login.
Next we should remove root login.
`sed -i 's/^PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config`<br>
`sudo systemctl restart sshd`<br>
### Step 4 - Creating SSH Keys
While this step is optional it is highly recommended. If you skip this step, you must set-up fail2ban as per step 7. Here, the first goal is to create a key pair on the client machine, usually your computer.
`ssh-keygen`
Enter to save the key pair into the .ssh/ subdirectory in your home directory, or specify an alternate path. After you optionally may enter a secure passphrase, which is highly recommended. A passphrase adds an additional layer of security to prevent unauthorized users from logging in.
### Step 5 - Copying the Public Key to the Server.
The quickest way to copy your public key to the server is to use a utility called ssh-copy-id.
`ssh-copy-id username@remote_host`
If you don't have ssh-copy-id you can use cat and ssh to manually copy it.
`cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys`
### Step 6 - Disabling Password Authentication
Now with a non-root user and ssh keys we can finally disable password authentication for our ssh server.
`sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config`<br>
`sudo systemctl restart sshd`
### Step 7 - Setting up UFW
Install UFW, by default there are no rules set. We should allow SSH to prevent locking ourselves out.<br>
`sudo apt install ufw`<br>
`sudo ufw allow ssh`<br>
After confirming your have a rule to allow incoming SSH connections, you can enable the firewall with:<br>
`sudo ufw enable`<br>
### Step 8 - Setting up Fail2ban
If you didn't follow step 4, the next step is a must to prevent brute force password attacks on your server.
`sudo apt install fail2ban`
With fail2ban installed we should now set up our jail before we turn the service on. There are two jails, on gets updated by fail2ban, and the other (/etc/fail2ban/jail.local) is the one we configure.
[Here is an example SSH-Fail2ban Jail](./resources/jail.local)<br>
With our jail in place we can now enable fail2ban as service so it will run on startup.<br>
`sudo systemctl enable fail2ban.service`<br>
`sudo systemctl start fail2ban.service`<br>
`sudo systemctl status fail2ban.service`<br>
### Resources
I found these resources helpful.<br>
[Digital Ocean - SSH Essentials](./resources/DigitalOcean_SSH_Essentials.md)<br>
[Digital Ocean - SSH Keys](./resources/DigitalOcean_SSH_Keys.md)<br>
[Github - SSH Agent](./resources/Github_SSH_Agent.md)<br>
[Setting up UFW](./resources/UFW_Setup.md)

771
ssh_server/resources/DigitalOcean_SSH_Essentials.md Normal file
View File

@ -0,0 +1,771 @@
### [Introduction](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#introduction)
SSH is a secure protocol used as the primary means of connecting to Linux servers remotely. It provides a text-based interface by spawning a remote shell. After connecting, all commands you type in your local terminal are sent to the remote server and executed there.
In this cheat sheet-style guide, we will cover some common ways of connecting with SSH to achieve your objectives. This can be used as a quick reference when you need to know how to connect to or configure your server in different ways.
Deploy your frontend applications from GitHub using [DigitalOcean App Platform](https://www.digitalocean.com/products/app-platform). Let DigitalOcean focus on scaling your app.
## [How To Use This Guide](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#how-to-use-this-guide)
- Read the [SSH Overview section](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#ssh-overview) first if you are unfamiliar with SSH in general or are just getting started.
- Use whichever subsequent sections are applicable to what you are trying to achieve. Most sections are not predicated on any other, so you can use the following examples independently.
- Use the Contents menu on the left side of this page (at wide page widths) or your browser’s find function to locate the sections you need.
- Copy and paste the command-line examples given, substituting the `highlighted` values with your own values.
## [SSH Overview](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#ssh-overview)
The most common way of connecting to a remote Linux server is through SSH. SSH stands for Secure Shell and provides a safe and secure way of executing commands, making changes, and configuring services remotely. When you connect through SSH, you log in using an account that exists on the remote server.
### [How SSH Works](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#how-ssh-works)
When you connect through SSH, you will be dropped into a shell session, which is a text-based interface where you can interact with your server. For the duration of your SSH session, any commands that you type into your local terminal are sent through an encrypted SSH tunnel and executed on your server.
The SSH connection is implemented using a client-server model. This means that for an SSH connection to be established, the remote machine must be running a piece of software called an SSH daemon. This software listens for connections on a specific network port, authenticates connection requests, and spawns the appropriate environment if the user provides the correct credentials.
The user’s computer must have an SSH client. This is a piece of software that knows how to communicate using the SSH protocol and can be given information about the remote host to connect to, the username to use, and the credentials that should be passed to authenticate. The client can also specify certain details about the connection type they would like to establish.
### [How SSH Authenticates Users](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#how-ssh-authenticates-users)
Clients generally authenticate either using passwords (less secure and not recommended) or SSH keys, which are very secure.
Password logins are encrypted and are easy to understand for new users. However, automated bots and malicious users will often repeatedly try to authenticate to accounts that allow password-based logins, which can lead to security compromises. For this reason, we recommend always setting up SSH key-based authentication for most configurations.
SSH keys are a matching set of cryptographic keys which can be used for authentication. Each set contains a public and a private key. The public key can be shared freely without concern, while the private key must be vigilantly guarded and never exposed to anyone.
To authenticate using SSH keys, a user must have an SSH key pair on their local computer. On the remote server, the public key must be copied to a file within the user’s home directory at `~/.ssh/authorized_keys`. This file contains a list of public keys, one-per-line, that are authorized to log into this account.
When a client connects to the host, wishing to use SSH key authentication, it will inform the server of this intent and will tell the server which public key to use. The server then checks its `authorized_keys` file for the public key, generates a random string, and encrypts it using the public key. This encrypted message can only be decrypted with the associated private key. The server will send this encrypted message to the client to test whether they actually have the associated private key.
Upon receipt of this message, the client will decrypt it using the private key and combine the random string that is revealed with a previously negotiated session ID. It then generates an MD5 hash of this value and transmits it back to the server. The server already had the original message and the session ID, so it can compare an MD5 hash generated by those values and determine that the client must have the private key.
Now that you know how SSH works, we can begin to discuss some examples to demonstrate different ways of working with SSH
## [Generating and Working with SSH Keys](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#generating-and-working-with-ssh-keys)
This section will cover how to generate SSH keys on a client machine and distribute the public key to servers where they should be used. This is a good section to start with if you have not previously generated keys due to the increased security that it allows for future connections.
### [Generating an SSH Key Pair](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#generating-an-ssh-key-pair)
Generating a new SSH public and private key pair on your local computer is the first step towards authenticating with a remote server without a password. Unless there is a good reason not to, you should always authenticate using SSH keys.
A number of cryptographic algorithms can be used to generate SSH keys, including RSA, DSA, and ECDSA. RSA keys are generally preferred and are the default key type.
To generate an RSA key pair on your local computer, type:
```
Generating public/private rsa key pair.
Enter file in which to save the key (/home/demo/.ssh/id_rsa):
```
This prompt allows you to choose the location to store your RSA private key. Press `ENTER` to leave this as the default, which will store them in the `.ssh` hidden directory in your user’s home directory. Leaving the default location selected will allow your SSH client to find the keys automatically.
```
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
```
The next prompt allows you to enter a passphrase of an arbitrary length to secure your private key. By default, you will have to enter any passphrase you set here every time you use the private key, as an additional security measure. Feel free to press `ENTER` to leave this blank if you do not want a passphrase. Keep in mind though that this will allow anyone who gains control of your private key to login to your servers.
If you choose to enter a passphrase, nothing will be displayed as you type. This is a security precaution.
```
<p>Output</p>Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
8c:e9:7c:fa:bf:c4:e5:9c:c9:b8:60:1f:fe:1c:d3:8a root@here
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| + |
| o S . |
| o . * + |
| o + = O . |
| + = = + |
| ....Eo+ |
+-----------------+
```
This procedure has generated an RSA SSH key pair, located in the `.ssh` hidden directory within your user’s home directory. These files are:
- `~/.ssh/id_rsa`: The private key. DO NOT SHARE THIS FILE!
- `~/.ssh/id_rsa.pub`: The associated public key. This can be shared freely without consequence.
### [Generate an SSH Key Pair with a Larger Number of Bits](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#generate-an-ssh-key-pair-with-a-larger-number-of-bits)
SSH keys are 2048 bits by default. This is generally considered to be good enough for security, but you can specify a greater number of bits for a more hardened key.
To do this, include the `-b` argument with the number of bits you would like. Most servers support keys with a length of at least 4096 bits. Longer keys may not be accepted for DDOS protection purposes:
If you had previously created a different key, you will be asked if you wish to overwrite your previous key:
```
Overwrite (y/n)?
```
If you choose “yes”, your previous key will be overwritten and you will no longer be able to log in to servers using that key. Because of this, be sure to overwrite keys with caution.
### [Removing or Changing the Passphrase on a Private Key](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#removing-or-changing-the-passphrase-on-a-private-key)
If you have generated a passphrase for your private key and wish to change or remove it, you can do so easily.
**Note**: To change or remove the passphrase, you must know the original passphrase. If you have lost the passphrase to the key, there is no recourse and you will have to generate a new key pair.
To change or remove the passphrase, simply type:
```
Enter file in which the key is (/root/.ssh/id_rsa):
```
You can type the location of the key you wish to modify or press `ENTER` to accept the default value:
```
Enter old passphrase:
```
Enter the old passphrase that you wish to change. You will then be prompted for a new passphrase:
```
Enter new passphrase (empty for no passphrase):
Enter same passphrase again:
```
Here, enter your new passphrase or press `ENTER` to remove the passphrase.
### [Displaying the SSH Key Fingerprint](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#displaying-the-ssh-key-fingerprint)
Each SSH key pair share a single cryptographic “fingerprint” which can be used to uniquely identify the keys. This can be useful in a variety of situations.
To find out the fingerprint of an SSH key, type:
```
Enter file in which the key is (/root/.ssh/id_rsa):
```
You can press `ENTER` if that is the correct location of the key, else enter the revised location. You will be given a string which contains the bit-length of the key, the fingerprint, and account and host it was created for, and the algorithm used:
```
<p>Output</p>4096 8e:c4:82:47:87:c2:26:4b:68:ff:96:1a:39:62:9e:4e demo@test (RSA)
```
### [Copying your Public SSH Key to a Server with SSH-Copy-ID](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#copying-your-public-ssh-key-to-a-server-with-ssh-copy-id)
To copy your public key to a server, allowing you to authenticate without a password, a number of approaches can be taken.
If you currently have password-based SSH access configured to your server, and you have the `ssh-copy-id` utility installed, this is a simple process. The `ssh-copy-id` tool is included in many Linux distributions’ OpenSSH packages, so it very likely may be installed by default.
If you have this option, you can easily transfer your public key by typing:
This will prompt you for the user account’s password on the remote system:
```
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
demo@111.111.11.111's password:
```
After typing in the password, the contents of your `~/.ssh/id_rsa.pub` key will be appended to the end of the user account’s `~/.ssh/authorized_keys` file:
```
<p>Output</p>Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'demo@111.111.11.111'"
and check to make sure that only the key(s) you wanted were added.
```
You can now log in to that account without a password:
### [Copying your Public SSH Key to a Server Without SSH-Copy-ID](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#copying-your-public-ssh-key-to-a-server-without-ssh-copy-id)
If you do not have the `ssh-copy-id` utility available, but still have password-based SSH access to the remote server, you can copy the contents of your public key in a different way.
You can output the contents of the key and pipe it into the `ssh` command. On the remote side, you can ensure that the `~/.ssh` directory exists, and then append the piped contents into the `~/.ssh/authorized_keys` file:
You will be asked to supply the password for the remote account:
```
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
demo@111.111.11.111's password:
```
After entering the password, your key will be copied, allowing you to log in without a password:
### [Copying your Public SSH Key to a Server Manually](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#copying-your-public-ssh-key-to-a-server-manually)
If you do not have password-based SSH access available, you will have to add your public key to the remote server manually.
On your local machine, you can find the contents of your public key file by typing:
```
<p>Output</p>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test
```
You can copy this value, and manually paste it into the appropriate location on the remote server. You will have to log in to the remote server through other means (like the DigitalOcean web console).
On the remote server, create the `~/.ssh` directory if it does not already exist:
Afterwards, you can create or append the `~/.ssh/authorized_keys` file by typing:
You should now be able to log in to the remote server without a password.
## [Basic Connection Instructions](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#basic-connection-instructions)
The following section will cover some of the basics about how to connect to a server with SSH.
### [Connecting to a Remote Server](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#connecting-to-a-remote-server)
To connect to a remote server and open a shell session there, you can use the `ssh` command.
The simplest form assumes that your username on your local machine is the same as that on the remote server. If this is true, you can connect using:
If your username is different on the remoter server, you need to pass the remote user’s name like this:
Your first time connecting to a new host, you will see a message that looks like this:
```
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
```
Type `yes` to accept the authenticity of the remote host.
If you are using password authentication, you will be prompted for the password for the remote account here. If you are using SSH keys, you will be prompted for your private key’s passphrase if one is set, otherwise you will be logged in automatically.
### [Running a Single Command on a Remote Server](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#running-a-single-command-on-a-remote-server)
To run a single command on a remote server instead of spawning a shell session, you can add the command after the connection information, like this:
This will connect to the remote host, authenticate with your credentials, and execute the command you specified. The connection will immediately close afterwards.
### [Logging in to a Server with a Different Port](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#logging-in-to-a-server-with-a-different-port)
By default the SSH daemon on a server runs on port `22`. Your SSH client will assume that this is the case when trying to connect. If your SSH server is listening on a non-standard port (this is demonstrated in a later section), you will have to specify the new port number when connecting with your client.
You can do this by specifying the port number with the `-p` option:
To avoid having to do this every time you log in to your remote server, you can create or edit a configuration file in the `~/.ssh` directory within the home directory of your local computer.
Edit or create the file now by typing:
In here, you can set host-specific configuration options. To specify your new port, use a format like this:
~/.ssh/config
```
Host <mark>remote_alias</mark>
HostName <mark>remote_host</mark>
Port <mark>port_num</mark>
```
This will allow you to log in without specifying the specific port number on the command line.
### [Adding your SSH Keys to an SSH Agent to Avoid Typing the Passphrase](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#adding-your-ssh-keys-to-an-ssh-agent-to-avoid-typing-the-passphrase)
If you have a passphrase on your private SSH key, you will be prompted to enter the passphrase every time you use it to connect to a remote host.
To avoid having to repeatedly do this, you can run an SSH agent. This small utility stores your private key after you have entered the passphrase for the first time. It will be available for the duration of your terminal session, allowing you to connect in the future without re-entering the passphrase.
This is also important if you need to forward your SSH credentials (shown later).
To start the SSH Agent, type the following into your local terminal session:
```
<p>Output</p>Agent pid 10891
```
This will start the agent program and place it into the background. Now, you need to add your private key to the agent, so that it can manage your key:
```
Enter passphrase for /home/demo/.ssh/id_rsa:
Identity added: /home/demo/.ssh/id_rsa (/home/demo/.ssh/id_rsa)
```
You will have to enter your passphrase (if one is set). Afterwards, your identity file is added to the agent, allowing you to use your key to sign in without having to re-enter the passphrase again.
### [Forwarding your SSH Credentials to Use on a Server](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#forwarding-your-ssh-credentials-to-use-on-a-server)
If you wish to be able to connect without a password to one server from within another server, you will need to forward your SSH key information. This will allow you to authenticate to another server through the server you are connected to, using the credentials on your local computer.
To start, you must have your SSH agent started and your SSH key added to the agent (see earlier). After this is done, you need to connect to your first server using the `-A` option. This forwards your credentials to the server for this session:
From here, you can SSH in to any other host that your SSH key is authorized to access. You will connect as if your private SSH key were located on this server.
## [Server-Side Configuration Options](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#server-side-configuration-options)
This section contains some common server-side configuration options that can shape the way that your server responds and what types of connections are allowed.
### [Disabling Password Authentication](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#disabling-password-authentication)
If you have SSH keys configured, tested, and working properly, it is probably a good idea to disable password authentication. This will prevent any user from signing in with SSH using a password.
To do this, connect to your remote server and open the `/etc/ssh/sshd_config` file with root or sudo privileges:
Inside of the file, search for the `PasswordAuthentication` directive. If it is commented out, uncomment it. Set it to `no` to disable password logins:
/etc/ssh/sshd\_config
```
PasswordAuthentication no
```
After you have made the change, save and close the file. To implement the changes, you should restart the SSH service.
On Ubuntu/Debian:
On CentOS/Fedora:
Now, all accounts on the system will be unable to log in with SSH using passwords.
### [Changing the Port that the SSH Daemon Runs On](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#changing-the-port-that-the-ssh-daemon-runs-on)
Some administrators suggest that you change the default port that SSH runs on. This can help decrease the number of authentication attempts your server is subjected to from automated bots.
To change the port that the SSH daemon listens on, you will have to log in to your remote server. Open the `sshd_config` file on the remote system with root privileges, either by logging in with that user or by using `sudo`:
Once you are inside, you can change the port that SSH runs on by finding the `Port 22` specification and modifying it to reflect the port you wish to use. For instance, to change the port to `4444`, put this in your file:
/etc/ssh/sshd\_config
```
<mark>#</mark>Port 22
Port <mark>4444</mark>
```
Save and close the file when you are finished. To implement the changes, you must restart the SSH daemon.
On Ubuntu/Debian:
On CentOS/Fedora:
After the daemon restarts, you will need to authenticate by specifying the port number (demonstrated in an earlier section).
### [Limiting the Users Who can Connect Through SSH](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#limiting-the-users-who-can-connect-through-ssh)
To explicitly limit the user accounts who are able to log in through SSH, you can take a few different approaches, each of which involve editing the SSH daemon config file.
On your remote server, open this file now with root or sudo privileges:
The first method of specifying the accounts that are allowed to login is using the `AllowUsers` directive. Search for the `AllowUsers` directive in the file. If one does not exist, create it anywhere. After the directive, list the user accounts that should be allowed to login through SSH:
/etc/ssh/sshd\_config
```
AllowUsers <mark>user1</mark> <mark>user2</mark>
```
Save and close the file. Restart the daemon to implement your changes.
On Ubuntu/Debian:
On CentOS/Fedora:
If you are more comfortable with group management, you can use the `AllowGroups` directive instead. If this is the case, just add a single group that should be allowed SSH access (we will create this group and add members momentarily):
/etc/ssh/sshd\_config
```
AllowGroups <mark>sshmembers</mark>
```
Save and close the file.
Now, you can create a system group (without a home directory) matching the group you specified by typing:
Make sure that you add whatever user accounts you need to this group. This can be done by typing:
Now, restart the SSH daemon to implement your changes.
On Ubuntu/Debian:
On CentOS/Fedora:
### [Disabling Root Login](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#disabling-root-login)
It is often advisable to completely disable root login through SSH after you have set up an SSH user account that has `sudo` privileges.
To do this, open the SSH daemon configuration file with root or sudo on your remote server.
Inside, search for a directive called `PermitRootLogin`. If it is commented, uncomment it. Change the value to “no”:
/etc/ssh/sshd\_config
```
PermitRootLogin no
```
Save and close the file. To implement your changes, restart the SSH daemon.
On Ubuntu/Debian:
On CentOS/Fedora:
### [Allowing Root Access for Specific Commands](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#allowing-root-access-for-specific-commands)
There are some cases where you might want to disable root access generally, but enable it in order to allow certain applications to run correctly. An example of this might be a backup routine.
This can be accomplished through the root user’s `authorized_keys` file, which contains SSH keys that are authorized to use the account.
Add the key from your local computer that you wish to use for this process (we recommend creating a new key for each automatic process) to the root user’s `authorized_keys` file on the server. We will demonstrate with the `ssh-copy-id` command here, but you can use any of the methods of copying keys we discuss in other sections:
Now, log into the remote server. We will need to adjust the entry in the `authorized_keys` file, so open it with root or sudo access:
At the beginning of the line with the key you uploaded, add a `command=` listing that defines the command that this key is valid for. This should include the full path to the executable, plus any arguments:
/root/.ssh/authorized\_keys
```
command="<mark>/path/to/command arg1 arg2</mark>" ssh-rsa ...
```
Save and close the file when you are finished.
Now, open the `sshd_config` file with root or sudo privileges:
Find the directive `PermitRootLogin`, and change the value to `forced-commands-only`. This will only allow SSH key logins to use root when a command has been specified for the key:
/etc/ssh/sshd\_config
```
PermitRootLogin forced-commands-only
```
Save and close the file. Restart the SSH daemon to implement your changes.
On Ubuntu/Debian:
On CentOS/Fedora:
### [Forwarding X Application Displays to the Client](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#forwarding-x-application-displays-to-the-client)
The SSH daemon can be configured to automatically forward the display of X applications on the server to the client machine. For this to function correctly, the client must have an X windows system configured and enabled.
To enable this functionality, log in to your remote server and edit the `sshd_config` file as root or with sudo privileges:
Search for the `X11Forwarding` directive. If it is commented out, uncomment it. Create it if necessary and set the value to “yes”:
/etc/ssh/sshd\_config
```
X11Forwarding yes
```
Save and close the file. Restart your SSH daemon to implement these changes.
On Ubuntu/Debian:
On CentOS/Fedora:
To connect to the server and forward an application’s display, you have to pass the `-X` option from the client upon connection:
Graphical applications started on the server through this session should be displayed on the local computer. The performance might be a bit slow, but it is very helpful in a pinch.
## [Client-Side Configuration Options](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#client-side-configuration-options)
In the next section, we’ll focus on some adjustments that you can make on the client side of the connection.
### [Defining Server-Specific Connection Information](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#defining-server-specific-connection-information)
On your local computer, you can define individual configurations for some or all of the servers you connect to. These can be stored in the `~/.ssh/config` file, which is read by your SSH client each time it is called.
Create or open this file in your text editor on your local computer:
Inside, you can define individual configuration options by introducing each with a `Host` keyword, followed by an alias. Beneath this and indented, you can define any of the directives found in the `ssh_config` man page:
An example configuration would be:
~/.ssh/config
```
Host testhost
HostName <mark>your_domain</mark>
Port <mark>4444</mark>
User <mark>demo</mark>
```
You could then connect to `your_domain` on port `4444` using the username `demo` by simply typing:
You can also use wildcards to match more than one host. Keep in mind that later matches can override earlier ones. Because of this, you should put your most general matches at the top. For instance, you could default all connections to not allow X forwarding, with an override for `your_domain` by having this in your file:
~/.ssh/config
```
Host *
ForwardX11 no
Host testhost
HostName <mark>your_domain</mark>
ForwardX11 yes
Port <mark>4444</mark>
User <mark>demo</mark>
```
Save and close the file when you are finished.
### [Keeping Connections Alive to Avoid Timeout](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#keeping-connections-alive-to-avoid-timeout)
If you find yourself being disconnected from SSH sessions before you are ready, it is possible that your connection is timing out.
You can configure your client to send a packet to the server every so often in order to avoid this situation:
On your local computer, you can configure this for every connection by editing your `~/.ssh/config` file. Open it now:
If one does not already exist, at the top of the file, define a section that will match all hosts. Set the `ServerAliveInterval` to “120” to send a packet to the server every two minutes. This should be enough to notify the server not to close the connection:
~/.ssh/config
```
Host *
ServerAliveInterval 120
```
Save and close the file when you are finished.
### [Disabling Host Checking](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#disabling-host-checking)
By default, whenever you connect to a new server, you will be shown the remote SSH daemon’s host key fingerprint.
```
The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? yes
```
This is configured so that you can verify the authenticity of the host you are attempting to connect to and spot instances where a malicious user may be trying to masquerade as the remote host.
In certain circumstances, you may wish to disable this feature. **Note**: This can be a big security risk, so make sure you know what you are doing if you set your system up like this.
To make the change, the open the `~/.ssh/config` file on your local computer:
If one does not already exist, at the top of the file, define a section that will match all hosts. Set the `StrictHostKeyChecking` directive to `no` to add new hosts automatically to the `known_hosts` file. Set the `UserKnownHostsFile` to `/dev/null` to not warn on new or changed hosts:
~/.ssh/config
```
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
```
You can enable the checking on a case-by-case basis by reversing those options for other hosts. The default for `StrictHostKeyChecking` is `ask`:
~/.ssh/config
```
Host *
StrictHostKeyChecking no
UserKnownHostsFile /dev/null
Host testhost
HostName <mark>your_domain</mark>
StrictHostKeyChecking ask
UserKnownHostsFile /home/<mark>demo</mark>/.ssh/known_hosts
```
### [Multiplexing SSH Over a Single TCP Connection](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#multiplexing-ssh-over-a-single-tcp-connection)
There are situations where establishing a new TCP connection can take longer than you would like. If you are making multiple connections to the same machine, you can take advantage of multiplexing.
SSH multiplexing re-uses the same TCP connection for multiple SSH sessions. This removes some of the work necessary to establish a new session, possibly speeding things up. Limiting the number of connections may also be helpful for other reasons.
To set up multiplexing, you can manually set up the connections, or you can configure your client to automatically use multiplexing when available. We will demonstrate the second option here.
To configure multiplexing, edit your SSH client’s configuration file on your local machine:
If you do not already have a wildcard host definition at the top of the file, add one now (as `Host *`). We will be setting the `ControlMaster`, `ControlPath`, and `ControlPersist` values to establish our multiplexing configuration.
The `ControlMaster` should be set to “auto” in able to automatically allow multiplexing if possible. The `ControlPath` will establish the path to control socket. The first session will create this socket and subsequent sessions will be able to find it because it is labeled by username, host, and port.
Setting the `ControlPersist` option to `1` will allow the initial master connection to be backgrounded. The `1` specifies that the TCP connection should automatically terminate one second after the last SSH session is closed:
/.ssh/config
```
Host *
ControlMaster auto
ControlPath ~/.ssh/multiplex/%r@%h:%p
ControlPersist 1
```
Save and close the file when you are finished. Now, we need to actually create the directory we specified in the control path:
Now, any sessions that are established with the same machine will attempt to use the existing socket and TCP connection. When the last session exists, the connection will be torn down after one second.
If for some reason you need to bypass the multiplexing configuration temporarily, you can do so by passing the `-S` flag with `none`:
## [Setting Up SSH Tunnels](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#setting-up-ssh-tunnels)
Tunneling other traffic through a secure SSH tunnel is an excellent way to work around restrictive firewall settings. It is also a great way to encrypt otherwise unencrypted network traffic.
### [Configuring Local Tunneling to a Server](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#configuring-local-tunneling-to-a-server)
SSH connections can be used to tunnel traffic from ports on the local host to ports on a remote host.
A local connection is a way of accessing a network location from your local computer through your remote host. First, an SSH connection is established to your remote host. On the remote server, a connection is made to an external (or internal) network address provided by the user and traffic to this location is tunneled to your local computer on a specified port.
This is often used to tunnel to a less restricted networking environment by bypassing a firewall. Another common use is to access a “localhost-only” web interface from a remote location.
To establish a local tunnel to your remote server, you need to use the `-L` parameter when connecting and you must supply three pieces of additional information:
- The local port where you wish to access the tunneled connection.
- The host that you want your remote host to connect to.
- The port that you want your remote host to connect on.
These are given, in the order above (separated by colons), as arguments to the `-L` flag. We will also use the `-f` flag, which causes SSH to go into the background before executing and the `-N` flag, which does not open a shell or execute a program on the remote side.
For instance, to connect to `your_domain` on port 80 on your remote host, making the connection available on your local machine on port 8888, you could type:
Now, if you point your local web browser to `127.0.0.1:8888`, you should see whatever content is at `your_domain` on port `80`.
A more general guide to the syntax is:
Since the connection is in the background, you will have to find its PID to kill it. You can do so by searching for the port you forwarded:
```
<p>Output</p>1001 <mark>5965</mark> 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -L 8888:<mark>your_domain</mark>:80 username@remote_host
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
```
You can then kill the process by targeting the PID, which is the number in the second column of the line that matches your SSH command:
Another option is to start the connection _without_ the `-f` flag. This will keep the connection in the foreground, preventing you from using the terminal window for the duration of the forwarding. The benefit of this is that you can easily kill the tunnel by typing `CTRL-C`.
### [Configuring Remote Tunneling to a Server](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#configuring-remote-tunneling-to-a-server)
SSH connections can be used to tunnel traffic from ports on the local host to ports on a remote host.
In a remote tunnel, a connection is made to a remote host. During the creation of the tunnel, a _remote_ port is specified. This port, on the remote host, will then be tunneled to a host and port combination that is connected to from the local computer. This will allow the remote computer to access a host through your local computer.
This can be useful if you need to allow access to an internal network that is locked down to external connections. If the firewall allows connections _out_ of the network, this will allow you to connect out to a remote machine and tunnel traffic from that machine to a location on the internal network.
To establish a remote tunnel to your remote server, you need to use the `-R` parameter when connecting and you must supply three pieces of additional information:
- The port where the remote host can access the tunneled connection.
- The host that you want your local computer to connect to.
- The port that you want your local computer to connect to.
These are given, in the order above (separated by colons), as arguments to the `-R` flag. We will also use the `-f` flag, which causes SSH to go into the background before executing and the `-N` flag, which does not open a shell or execute a program on the remote side.
For instance, to connect to `your_domain` on port 80 on our local computer, making the connection available on our remote host on port `8888`, you could type:
Now, on the remote host, opening a web browser to `127.0.0.1:8888` would allow you to see whatever content is at `your_domain` on port `80`.
A more general guide to the syntax is:
Since the connection is in the background, you will have to find its PID to kill it. You can do so by searching for the port you forwarded:
```
<p>Output</p>1001 <mark>5965</mark> 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -R 8888:<mark>your_domain</mark>:80 username@remote_host
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
```
You can then kill the process by targeting the PID, which is the number in the second column, of the line that matches your SSH command:
Another option is to start the connection _without_ the `-f` flag. This will keep the connection in the foreground, preventing you from using the terminal window for the duration of the forwarding. The benefit of this is that you can easily kill the tunnel by typing `CTRL-C`.
### [Configuring Dynamic Tunneling to a Remote Server](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#configuring-dynamic-tunneling-to-a-remote-server)
SSH connections can be used to tunnel traffic from ports on the local host to ports on a remote host.
A dynamic tunnel is similar to a local tunnel in that it allows the local computer to connect to other resources _through_ a remote host. A dynamic tunnel does this by simply specifying a single local port. Applications that wish to take advantage of this port for tunneling must be able to communicate using the SOCKS protocol so that the packets can be correctly redirected at the other side of the tunnel.
Traffic that is passed to this local port will be sent to the remote host. From there, the SOCKS protocol will be interpreted to establish a connection to the desired end location. This set up allows a SOCKS-capable application to connect to any number of locations through the remote server, without multiple static tunnels.
To establish the connection, we will pass the `-D` flag along with the local port where we wish to access the tunnel. We will also use the `-f` flag, which causes SSH to go into the background before executing and the `-N` flag, which does not open a shell or execute a program on the remote side.
For instance, to establish a tunnel on port `7777`, you can type:
From here, you can start pointing your SOCKS-aware application (like a web browser), to the port you selected. The application will send its information into a socket associated with the port.
The method of directing traffic to the SOCKS port will differ depending on application. For instance, in Firefox, the general location is Preferences > Advanced > Settings > Manual proxy configurations. In Chrome, you can start the application with the `--proxy-server=` flag set. You will want to use the localhost interface and the port you forwarded.
Since the connection is in the background, you will have to find its PID to kill it. You can do so by searching for the port you forwarded:
```
<p>Output</p>1001 <mark>5965</mark> 0.0 0.0 48168 1136 ? Ss 12:28 0:00 ssh -f -N -D 7777 username@remote_host
1001 6113 0.0 0.0 13648 952 pts/2 S+ 12:37 0:00 grep --colour=auto 8888
```
You can then kill the process by targeting the PID, which is the number in the second column, of the line that matches your SSH command:
Another option is to start the connection _without_ the `-f` flag. This will keep the connection in the foreground, preventing you from using the terminal window for the duration of the forwarding. The benefit of this is that you can easily kill the tunnel by typing `CTRL-C`.
## [Using SSH Escape Codes to Control Connections](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#using-ssh-escape-codes-to-control-connections)
Even after establishing an SSH session, it is possible to exercise control over the connection from within the terminal. We can do this with something called SSH escape codes, which allow us to interact with our local SSH software from within a session.
### [Forcing a Disconnect from the Client-Side (How to Exit Out of a Stuck or Frozen Session)](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#forcing-a-disconnect-from-the-client-side-how-to-exit-out-of-a-stuck-or-frozen-session)
One of the most useful feature of OpenSSH that goes largely unnoticed is the ability to control certain aspects of the session from within.
These commands can be executed starting with the `~` control character within an SSH session. Control commands will only be interpreted if they are the first thing that is typed after a newline, so always press ENTER one or two times prior to using one.
One of the most useful controls is the ability to initiate a disconnect from the client. SSH connections are typically closed by the server, but this can be a problem if the server is suffering from issues or if the connection has been broken. By using a client-side disconnect, the connection can be cleanly closed from the client.
To close a connection from the client, use the control character (`~`), with a dot. If your connection is having problems, you will likely be in what appears to be a stuck terminal session. Type the commands despite the lack of feedback to perform a client-side disconnect:
The connection should immediately close, returning you to your local shell session.
### [Placing an SSH Session into the Background](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#placing-an-ssh-session-into-the-background)
One of the most useful feature of OpenSSH that goes largely unnoticed is the ability to control certain aspects of the session from within the connection.
These commands can be executed starting with the `~` control character from within an SSH connection. Control commands will only be interpreted if they are the first thing that is typed after a newline, so always press `ENTER` one or two times prior to using one.
One capability that this provides is to put an SSH session into the background. To do this, we need to supply the control character (`~`) and then execute the conventional keyboard shortcut to background a task (CTRL-z):
This will place the connection into the background, returning you to your local shell session. To return to your SSH session, you can use the conventional job control mechanisms.
You can immediately re-activate your most recent backgrounded task by typing:
If you have multiple backgrounded tasks, you can see the available jobs by typing:
```
<p>Output</p>[1]+ Stopped ssh <mark>username</mark>@<mark>some_host</mark>
[2] Stopped ssh <mark>username</mark>@<mark>another_host</mark>
```
You can then bring any of the tasks to the foreground by using the index in the first column with a percentage sign:
### [Changing Port Forwarding Options on an Existing SSH Connection](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#changing-port-forwarding-options-on-an-existing-ssh-connection)
One of the most useful feature of OpenSSH that goes largely unnoticed is the ability to control certain aspects of the session from within the connection.
These commands can be executed starting with the `~` control character from within an SSH connection. Control commands will only be interpreted if they are the first thing that is typed after a newline, so always press ENTER one or two times prior to using one.
One thing that this allows is for a user to alter the port forwarding configuration after the connection has already been established. This allows you to create or tear down port forwarding rules on-the-fly.
These capabilities are part of the SSH command line interface, which can be accessed during a session by using the control character (`~`) and “C”:
```
ssh&gt;
```
You will be given an SSH command prompt, which has a very limited set of valid commands. To see the available options, you can type `-h` from this prompt. If nothing is returned, you may have to increase the verbosity of your SSH output by using `~v` a few times:
```
Commands:
-L[bind_address:]port:host:hostport Request local forward
-R[bind_address:]port:host:hostport Request remote forward
-D[bind_address:]port Request dynamic forward
-KL[bind_address:]port Cancel local forward
-KR[bind_address:]port Cancel remote forward
-KD[bind_address:]port Cancel dynamic forward
```
As you can see, you can easily implement any of the forwarding options using the appropriate options (see the forwarding section for more information). You can also destroy a tunnel with the associated “kill” command specified with a “K” before the forwarding type letter. For instance, to kill a local forward (`-L`), you could use the `-KL` command. You will only need to provide the port for this.
So, to set up a local port forward, you may type:
Port `8888` on your local computer will now be able to communicate with the web server on the host you are connecting to. When you are finished, you can tear down that forward by typing:
## [Conclusion](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys#conclusion)
The above instructions should cover the majority of the information most users will need about SSH on a day-to-day basis. If you have other tips or wish to share your favorite configurations and methods, feel free to use the comments below.

219
ssh_server/resources/DigitalOcean_SSH_Keys.md Normal file
View File

@ -0,0 +1,219 @@
### [Introduction](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#introduction)
SSH, or secure shell, is an encrypted protocol used to administer and communicate with servers. When working with an Ubuntu server, chances are you will spend most of your time in a terminal session connected to your server through SSH.
In this guide, we’ll focus on setting up SSH keys for an Ubuntu 22.04 installation. SSH keys provide a secure way of logging into your server and are recommended for all users.
## [Step 1 — Creating the Key Pair](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#step-1-creating-the-key-pair)
The first step is to create a key pair on the client machine (usually your computer):
By default recent versions of `ssh-keygen` will create a 3072-bit RSA key pair, which is secure enough for most use cases (you may optionally pass in the `-b 4096` flag to create a larger 4096-bit key).
After entering the command, you should see the following output:
```
<p>Output</p>Generating public/private rsa key pair.
Enter file in which to save the key (/<mark>your_home</mark>/.ssh/id_rsa):
```
Press enter to save the key pair into the `.ssh/` subdirectory in your home directory, or specify an alternate path.
If you had previously generated an SSH key pair, you may see the following prompt:
```
<p>Output</p>/home/<mark>your_home</mark>/.ssh/id_rsa already exists.
Overwrite (y/n)?
```
If you choose to overwrite the key on disk, you will **not** be able to authenticate using the previous key anymore. Be very careful when selecting yes, as this is a destructive process that cannot be reversed.
You should then see the following prompt:
```
<p>Output</p>Enter passphrase (empty for no passphrase):
```
Here you optionally may enter a secure passphrase, which is highly recommended. A passphrase adds an additional layer of security to prevent unauthorized users from logging in. To learn more about security, consult our tutorial on [How To Configure SSH Key-Based Authentication on a Linux Server](https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server).
You should then see the output similar to the following:
```
<p>Output</p>Your identification has been saved in /<mark>your_home</mark>/.ssh/id_rsa
Your public key has been saved in /<mark>your_home</mark>/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:/hk7MJ5n5aiqdfTVUZr+2Qt+qCiS7BIm5Iv0dxrc3ks user@host
The key's randomart image is:
+---[RSA 3072]----+
| .|
| + |
| + |
| . o . |
|o S . o |
| + o. .oo. .. .o|
|o = oooooEo+ ...o|
|.. o *o+=.*+o....|
| =+=ooB=o.... |
+----[SHA256]-----+
```
You now have a public and private key that you can use to authenticate. The next step is to place the public key on your server so that you can use SSH-key-based authentication to log in.
## [Step 2 — Copying the Public Key to Your Ubuntu Server](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#step-2-copying-the-public-key-to-your-ubuntu-server)
The quickest way to copy your public key to the Ubuntu host is to use a utility called `ssh-copy-id`. Due to its simplicity, this method is highly recommended if available. If you do not have `ssh-copy-id` available to you on your client machine, you may use one of the two alternate methods provided in this section (copying via password-based SSH, or manually copying the key).
### [Copying the Public Key Using `ssh-copy-id`](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#copying-the-public-key-using-ssh-copy-id)
The `ssh-copy-id` tool is included by default in many operating systems, so you may have it available on your local system. For this method to work, you must already have password-based SSH access to your server.
To use the utility, you specify the remote host that you would like to connect to, and the user account that you have password-based SSH access to. This is the account to which your public SSH key will be copied.
The syntax is:
You may see the following message:
```
<p>Output</p>The authenticity of host '<mark>203.0.113.1</mark> (<mark>203.0.113.1</mark>)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? <mark>yes</mark>
```
This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type “yes” and press `ENTER` to continue.
Next, the utility will scan your local account for the `id_rsa.pub` key that we created earlier. When it finds the key, it will prompt you for the password of the remote user’s account:
```
<p>Output</p>/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
<mark>username</mark>@<mark>203.0.113.1</mark>'s password:
```
Type in the password (your typing will not be displayed, for security purposes) and press `ENTER`. The utility will connect to the account on the remote host using the password you provided. It will then copy the contents of your `~/.ssh/id_rsa.pub` key into a file in the remote account’s home `~/.ssh` directory called `authorized_keys`.
You should see the following output:
```
<p>Output</p>Number of key(s) added: 1
Now try logging into the machine, with: "ssh '<mark>username</mark>@<mark>203.0.113.1</mark>'"
and check to make sure that only the key(s) you wanted were added.
```
At this point, your `id_rsa.pub` key has been uploaded to the remote account. You can continue on to [Step 3](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#step-3-%E2%80%94-authenticating-to-your-ubuntu-server-using-ssh-keys).
### [Copying the Public Key Using SSH](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#copying-the-public-key-using-ssh)
If you do not have `ssh-copy-id` available, but you have password-based SSH access to an account on your server, you can upload your keys using a conventional SSH method.
We can do this by using the `cat` command to read the contents of the public SSH key on our local computer and piping that through an SSH connection to the remote server.
On the other side, we can make sure that the `~/.ssh` directory exists and has the correct permissions under the account we’re using.
We can then output the content we piped over into a file called `authorized_keys` within this directory. We’ll use the `>>` redirect symbol to append the content instead of overwriting it. This will let us add keys without destroying previously added keys.
The full command looks like this:
You may see the following message:
```
<p>Output</p>The authenticity of host '<mark>203.0.113.1</mark> (<mark>203.0.113.1</mark>)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? <mark>yes</mark>
```
This means that your local computer does not recognize the remote host. This will happen the first time you connect to a new host. Type `yes` and press `ENTER` to continue.
Afterwards, you should be prompted to enter the remote user account password:
```
<p>Output</p><mark>username</mark>@<mark>203.0.113.1</mark>'s password:
```
After entering your password, the content of your `id_rsa.pub` key will be copied to the end of the `authorized_keys` file of the remote user’s account. Continue on to [Step 3](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#step-3-%E2%80%94-authenticating-to-your-ubuntu-server-using-ssh-keys) if this was successful.
### [Copying the Public Key Manually](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#copying-the-public-key-manually)
If you do not have password-based SSH access to your server available, you will have to complete the above process manually.
We will manually append the content of your `id_rsa.pub` file to the `~/.ssh/authorized_keys` file on your remote machine.
To display the content of your `id_rsa.pub` key, type this into your local computer:
You will see the key’s content, which should look something like this:
```
<p>Output</p>ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test
```
Access your remote host using whichever method you have available.
Once you have access to your account on the remote server, you should make sure the `~/.ssh` directory exists. This command will create the directory if necessary, or do nothing if it already exists:
Now, you can create or modify the `authorized_keys` file within this directory. You can add the contents of your `id_rsa.pub` file to the end of the `authorized_keys` file, creating it if necessary, using this command:
In the above command, substitute the `public_key_string` with the output from the `cat ~/.ssh/id_rsa.pub` command that you executed on your local system. It should start with `ssh-rsa AAAA...`.
Finally, we’ll ensure that the `~/.ssh` directory and `authorized_keys` file have the appropriate permissions set:
This recursively removes all “group” and “other” permissions for the `~/.ssh/` directory.
If you’re using the **root** account to set up keys for a user account, it’s also important that the `~/.ssh` directory belongs to the user and not to **root**:
In this tutorial our user is named sammy but you should substitute the appropriate username into the above command.
We can now attempt passwordless authentication with our Ubuntu server.
## [Step 3 — Authenticating to Your Ubuntu Server Using SSH Keys](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#step-3-authenticating-to-your-ubuntu-server-using-ssh-keys)
If you have successfully completed one of the procedures above, you should be able to log into the remote host _without_ providing the remote account’s password.
The basic process is the same:
If this is your first time connecting to this host (if you used the last method above), you may see something like this:
```
<p>Output</p>The authenticity of host '<mark>203.0.113.1</mark> (<mark>203.0.113.1</mark>)' can't be established.
ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.
Are you sure you want to continue connecting (yes/no)? <mark>yes</mark>
```
This means that your local computer does not recognize the remote host. Type “yes” and then press `ENTER` to continue.
If you did not supply a passphrase for your private key, you will be logged in immediately. If you supplied a passphrase for the private key when you created the key, you will be prompted to enter it now (note that your keystrokes will not display in the terminal session for security). After authenticating, a new shell session should open for you with the configured account on the Ubuntu server.
If key-based authentication was successful, continue on to learn how to further secure your system by disabling password authentication.
## [Step 4 — Disabling Password Authentication on Your Server](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#step-4-disabling-password-authentication-on-your-server)
If you were able to log into your account using SSH without a password, you have successfully configured SSH-key-based authentication to your account. However, your password-based authentication mechanism is still active, meaning that your server is still exposed to brute-force attacks.
Before completing the steps in this section, make sure that you either have SSH-key-based authentication configured for the **root** account on this server, or preferably, that you have SSH-key-based authentication configured for a non-root account on this server with `sudo` privileges. This step will lock down password-based logins, so ensuring that you will still be able to get administrative access is crucial.
**Note:** If you provided an SSH key when creating your DigitalOcean droplet, password authentication may have been automatically disabled. You can still verify this by reading on.
Once you’ve confirmed that your remote account has administrative privileges, log into your remote server with SSH keys, either as **root** or with an account with `sudo` privileges. Then, open up the SSH daemon’s configuration file:
Inside the file, search for a directive called `PasswordAuthentication`. This line may be commented out with a `#` at the beginning of the line. Uncomment the line by removing the `#`, and set the value to `no`. This will disable your ability to log in via SSH using account passwords:
/etc/ssh/sshd\_config
```
. . .
PasswordAuthentication no
. . .
```
Save and close the file when you are finished by pressing `CTRL+X`, then `Y` to confirm saving the file, and finally `ENTER` to exit nano. To actually activate these changes, we need to restart the `sshd` service:
As a precaution, open up a new terminal window and test that the SSH service is functioning correctly before closing your current session:
Once you have verified your SSH service is functioning properly, you can safely close all current server sessions.
The SSH daemon on your Ubuntu server now only responds to SSH-key-based authentication. Password-based logins have been disabled.
## [Conclusion](https://www.digitalocean.com/community/tutorials/how-to-set-up-ssh-keys-on-ubuntu-22-04#conclusion)
You should now have SSH-key-based authentication configured on your server, allowing you to sign in without providing an account password.
If you’d like to learn more about working with SSH, take a look at our [SSH Essentials Guide](https://www.digitalocean.com/community/tutorials/ssh-essentials-working-with-ssh-servers-clients-and-keys).

82
ssh_server/resources/Github_SSH_Agent.md Normal file
View File

@ -0,0 +1,82 @@
After you've checked for existing SSH keys, you can generate a new SSH key to use for authentication, then add it to the ssh-agent.
## [About SSH key passphrases](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#about-ssh-key-passphrases)
You can access and write data in repositories on GitHub.com using SSH (Secure Shell Protocol). When you connect via SSH, you authenticate using a private key file on your local machine. For more information, see "[About SSH](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/about-ssh)."
When you generate an SSH key, you can add a passphrase to further secure the key. Whenever you use the key, you must enter the passphrase. If your key has a passphrase and you don't want to enter the passphrase every time you use the key, you can add your key to the SSH agent. The SSH agent manages your SSH keys and remembers your passphrase.
If you don't already have an SSH key, you must generate a new SSH key to use for authentication. If you're unsure whether you already have an SSH key, you can check for existing keys. For more information, see "[Checking for existing SSH keys](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/checking-for-existing-ssh-keys)."
If you want to use a hardware security key to authenticate to GitHub, you must generate a new SSH key for your hardware security key. You must connect your hardware security key to your computer when you authenticate with the key pair. For more information, see the [OpenSSH 8.2 release notes](https://www.openssh.com/txt/release-8.2).
## [Generating a new SSH key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key)
You can generate a new SSH key on your local machine. After you generate the key, you can add the public key to your account on GitHub.com to enable authentication for Git operations over SSH.
**Note:** GitHub improved security by dropping older, insecure key types on March 15, 2022.
As of that date, DSA keys (`ssh-dss`) are no longer supported. You cannot add new DSA keys to your personal account on GitHub.com.
RSA keys (`ssh-rsa`) with a `valid_after` before November 2, 2021 may continue to use any signature algorithm. RSA keys generated after that date must use a SHA-2 signature algorithm. Some older clients may need to be upgraded in order to use SHA-2 signatures.
1. Open Terminal.
2. Paste the text below, replacing the email used in the example with your GitHub email address.
```shell
ssh-keygen -t ed25519 -C "your_email@example.com"
```
**Note:** If you are using a legacy system that doesn't support the Ed25519 algorithm, use:
```shell
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
```
This creates a new SSH key, using the provided email as a label.
```shell
> Generating public/private ALGORITHM key pair.
```
When you're prompted to "Enter a file in which to save the key", you can press **Enter** to accept the default file location. Please note that if you created SSH keys previously, ssh-keygen may ask you to rewrite another key, in which case we recommend creating a custom-named SSH key. To do so, type the default file location and replace id\_ALGORITHM with your custom key name.
3. At the prompt, type a secure passphrase. For more information, see "[Working with SSH key passphrases](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/working-with-ssh-key-passphrases)."
```shell
> Enter passphrase (empty for no passphrase): [Type a passphrase] > Enter same passphrase again: [Type passphrase again]
```
## [Adding your SSH key to the ssh-agent](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#adding-your-ssh-key-to-the-ssh-agent)
Before adding a new SSH key to the ssh-agent to manage your keys, you should have checked for existing SSH keys and generated a new SSH key.
## [Generating a new SSH key for a hardware security key](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent#generating-a-new-ssh-key-for-a-hardware-security-key)
If you are using macOS or Linux, you may need to update your SSH client or install a new SSH client prior to generating a new SSH key. For more information, see "[Error: Unknown key type](https://docs.github.com/en/authentication/troubleshooting-ssh/error-unknown-key-type)."
1. Insert your hardware security key into your computer.
2. Open Terminal.
3. Paste the text below, replacing the email address in the example with the email address associated with your account on GitHub.
**Note:** If the command fails and you receive the error `invalid format` or `feature not supported,` you may be using a hardware security key that does not support the Ed25519 algorithm. Enter the following command instead.
```shell
ssh-keygen -t ecdsa-sk -C "your_email@example.com"
```
4. When you are prompted, touch the button on your hardware security key.
5. When you are prompted to "Enter a file in which to save the key," press Enter to accept the default file location.
6. When you are prompted to type a passphrase, press **Enter**.
```shell
> Enter passphrase (empty for no passphrase): [Type a passphrase] > Enter same passphrase again: [Type passphrase again]
```
7. Add the SSH public key to your account on GitHub. For more information, see "[Adding a new SSH key to your GitHub account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)."

358
ssh_server/resources/UFW_Setup.md Normal file
View File

@ -0,0 +1,358 @@
### [Introduction](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#introduction)
UFW, or Uncomplicated Firewall, is an interface to `iptables` that is geared towards simplifying the process of configuring a firewall. While `iptables` is a solid and flexible tool, it can be difficult for beginners to learn how to use it to properly configure a firewall. If you’re looking to get started securing your network, and you’re not sure which tool to use, UFW may be the right choice for you.
This tutorial will show you how to set up a firewall with UFW on Ubuntu v18.04 and above.
## [Prerequisites](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#prerequisites)
If you are using Ubuntu version 16.04 or below, we recommend you upgrade to a more latest version since Ubuntu no longer provides support for these versions. This [collection of guides](https://www.digitalocean.com/community/tutorial-collections/ubuntu-lts-upgrades) will help you in upgrading your Ubuntu version.
To follow this tutorial, you will need:
- A server running Ubuntu, along with a non-root user with `sudo` privileges. For guidance on how to set these up, please choose your distribution from [this list and follow our Initial Server Setup Guide](https://www.digitalocean.com/community/tutorial_collections/initial-server-setup).
- UFW is installed by default on Ubuntu. If it has been uninstalled for some reason, you can install it with `sudo apt install ufw`.
## [Setup Ubuntu firewall with UFW](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#setup-ubuntu-firewall-with-ufw)
1. [Enable IPv6](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-1-making-sure-ipv6-is-enabled)
2. [Set Up Default Policies](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-2-setting-up-default-policies)
3. [Allow SSH Connections](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-3-allowing-ssh-connections)
4. [Enabling UFW](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-4-enabling-ufw)
5. [Allow Any Other Required Connections](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-5-allowing-other-connections)
6. [Denying Connections](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-6-denying-connections)
7. [Deleting Firewall Rules](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-7-deleting-rules)
8. [Check UFW Status and Rules](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-8-checking-ufw-status-and-rules)
9. [How to Disable or Reset Firewall on Ubuntu](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-9-disabling-or-resetting-ufw-optional)
## [Step 1 — Making Sure IPv6 is Enabled](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-1-making-sure-ipv6-is-enabled)
In recent versions of Ubuntu, IPv6 is enabled by default. In practice that means most firewall rules added to the server will include both an IPv4 and an IPv6 version, the latter identified by `v6` within the output of UFW’s status command. To make sure IPv6 is enabled, you can check your UFW configuration file at `/etc/default/ufw`. Open this file using `nano` or your favorite command line editor:
Then make sure the value of `IPV6` is set to `yes`. It should look like this:
/etc/default/ufw excerpt
Save and close the file. If you’re using `nano`, you can do that by typing `CTRL+X`, then `Y` and `ENTER` to confirm.
When UFW is enabled in a later step of this guide, it will be configured to write both IPv4 and IPv6 firewall rules.
## [Step 2 — Setting Up Default Policies](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-2-setting-up-default-policies)
If you’re just getting started with UFW, a good first step is to check your default firewall policies. These rules control how to handle traffic that does not explicitly match any other rules.
By default, UFW is set to deny all incoming connections and allow all outgoing connections. This means anyone trying to reach your server would not be able to connect, while any application within the server would be able to reach the outside world. Additional rules to allow specific services and ports are included as exceptions to this general policy.
To make sure you’ll be able to follow along with the rest of this tutorial, you’ll now set up your UFW default policies for incoming and outgoing traffic.
To set the default UFW incoming policy to `deny`, run:
```
<p>Output</p>Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)
```
To set the default UFW outgoing policy to `allow`, run:
```
<p>Output</p>Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)
```
These commands set the defaults to deny incoming and allow outgoing connections. These firewall defaults alone might suffice for a personal computer, but servers typically need to respond to incoming requests from outside users. We’ll look into that next.
## [Step 3 — Allowing SSH Connections](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-3-allowing-ssh-connections)
If you were to enable your UFW firewall now, it would deny all incoming connections. This means that you’ll need to create rules that explicitly allow legitimate incoming connections — SSH or HTTP connections, for example — if you want your server to respond to those types of requests. If you’re using a cloud server, you will probably want to allow incoming SSH connections so you can connect to and manage your server.
### [Allowing the OpenSSH UFW Application Profile](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#allowing-the-openssh-ufw-application-profile)
Upon installation, most applications that rely on network connections will register an application profile within UFW, which enables users to quickly allow or deny external access to a service. You can check which profiles are currently registered in UFW with:
```
<p>Output</p>Available applications:
OpenSSH
```
To enable the OpenSSH application profile, run:
```
<p>Output</p>Rule added
Rule added (v6)
```
This will create firewall rules to allow all connections on port `22`, which is the port that the SSH daemon listens on by default.
### [Allowing SSH by Service Name](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#allowing-ssh-by-service-name)
Another way to configure UFW to allow incoming SSH connections is by referencing its service name: `ssh`.
```
<p>Output</p>Rule added
Rule added (v6)
```
UFW knows which ports and protocols a service uses based on the `/etc/services` file.
### [Allowing SSH by Port Number](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#allowing-ssh-by-port-number)
Alternatively, you can write the equivalent rule by specifying the port instead of the application profile or service name. For example, this command works the same as the previous examples:
```
<p>Output</p>Rule added
Rule added (v6)
```
If you configured your SSH daemon to use a different port, you will have to specify the appropriate port. For example, if your SSH server is listening on port `2222`, you can use this command to allow connections on that port:
```
<p>Output</p>Rule added
Rule added (v6)
```
Now that your firewall is configured to allow incoming SSH connections, you can enable it.
## [Step 4 — Enabling UFW](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-4-enabling-ufw)
Your firewall should now be configured to allow SSH connections. To verify which rules were added so far, even when the firewall is still disabled, you can use:
```
<p>Output</p>Added user rules (see 'ufw status' for running firewall):
ufw allow OpenSSH
```
After confirming your have a rule to allow incoming SSH connections, you can enable the firewall with:
```
<p>Output</p>Command may disrupt existing ssh connections. Proceed with operation (y|n)? y
Firewall is active and enabled on system startup
```
You will receive a warning that says the command may disrupt existing SSH connections. You already set up a firewall rule that allows SSH connections, so it should be fine to continue. Respond to the prompt with `y` and hit `ENTER`.
The firewall is now active. Run the `sudo ufw status verbose` command to see the rules that are set. The rest of this tutorial covers how to use UFW in more detail, like allowing or denying different kinds of connections.
## [Step 5 — Allowing Other Connections](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-5-allowing-other-connections)
At this point, you should allow all of the other connections that your server needs to respond to. The connections that you should allow depend on your specific needs. You already know how to write rules that allow connections based on an application profile, a service name, or a port; you already did this for SSH on port `22`. You can also do this for:
- HTTP on port 80, which is what unencrypted web servers use, using `sudo ufw allow http` or `sudo ufw allow 80`
- HTTPS on port 443, which is what encrypted web servers use, using `sudo ufw allow https` or `sudo ufw allow 443`
- Apache with both HTTP and HTTPS, using `sudo ufw allow ‘Apache Full’`
- Nginx with both HTTP and HTTPS, using `sudo ufw allow ‘Nginx Full’`
Don’t forget to check which application profiles are available for your server with `sudo ufw app list`.
There are several other ways to allow connections, aside from specifying a port or known service name. We’ll see some of these next.
### [Specific Port Ranges](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#specific-port-ranges)
You can specify port ranges with UFW. Some applications use multiple ports, instead of a single port.
For example, to allow X11 connections, which use ports `6000`\-`6007`, use these commands:
When specifying port ranges with UFW, you must specify the protocol (`tcp` or `udp`) that the rules should apply to. We haven’t mentioned this before because not specifying the protocol automatically allows both protocols, which is OK in most cases.
### [Specific IP Addresses](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#specific-ip-addresses)
When working with UFW, you can also specify IP addresses within your rules. For example, if you want to allow connections from a specific IP address, such as a work or home IP address of `203.0.113.4`, you need to use the `from` parameter, providing then the IP address you want to allow:
```
<p>Output</p>Rule added
```
You can also specify a port that the IP address is allowed to connect to by adding `to any port` followed by the port number. For example, If you want to allow `203.0.113.4` to connect to port `22` (SSH), use this command:
```
<p>Output</p>Rule added
```
### [Subnets](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#subnets)
If you want to allow a subnet of IP addresses, you can do so using [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#:~:text=CIDR%20notation%20is%20a%20compact,bits%20in%20the%20network%20mask.) to specify a netmask. For example, if you want to allow all of the IP addresses ranging from `203.0.113.1` to `203.0.113.254` you could use this command:
```
<p>Output</p>Rule added
```
Likewise, you may also specify the destination port that the subnet `203.0.113.0/24` is allowed to connect to. Again, we’ll use port `22` (SSH) as an example:
```
<p>Output</p>Rule added
```
### [Connections to a Specific Network Interface](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#connections-to-a-specific-network-interface)
If you want to create a firewall rule that only applies to a specific network interface, you can do so by specifying “allow in on” followed by the name of the network interface.
You may want to look up your network interfaces before continuing. To do so, use this command:
```
<p>Output Excerpt</p>2: <mark>eth0</mark>: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state
. . .
3: <mark>eth1</mark>: &lt;BROADCAST,MULTICAST&gt; mtu 1500 qdisc noop state DOWN group default
. . .
```
The highlighted output indicates the network interface names. They are typically named something like `eth0` or `enp3s2`.
So, if your server has a public network interface called `eth0`, you could allow HTTP traffic (port `80`) to it with this command:
```
<p>Output</p>Rule added
Rule added (v6)
```
Doing so would allow your server to receive HTTP requests from the public internet.
Or, if you want your MySQL database server (port `3306`) to listen for connections on the private network interface `eth1`, for example, you could use this command:
```
<p>Output</p>Rule added
Rule added (v6)
```
This would allow other servers on your private network to connect to your MySQL database.
## [Step 6 — Denying Connections](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-6-denying-connections)
If you haven’t changed the default policy for incoming connections, UFW is configured to deny all incoming connections. Generally, this simplifies the process of creating a secure firewall policy by requiring you to create rules that explicitly allow specific ports and IP addresses through.
However, sometimes you will want to deny specific connections based on the source IP address or subnet, perhaps because you know that your server is being attacked from there. Also, if you want to change your default incoming policy to **allow** (which is not recommended), you would need to create **deny** rules for any services or IP addresses that you don’t want to allow connections for.
To write **deny** rules, you can use the commands previously described, replacing **allow** with **deny**.
For example, to deny HTTP connections, you could use this command:
```
<p>Output</p>Rule added
Rule added (v6)
```
Or if you want to deny all connections from `203.0.113.4` you could use this command:
```
<p>Output</p>Rule added
```
In some cases, you may also want to block outgoing connections from the server. To deny all users from using a port on the server, such as port `25` for SMTP traffic, you can use `deny out` followed by the port number:
```
<p>Output</p>Rule added
Rule added (v6)
```
This will block all outgoing SMTP traffic on the server.
## [Step 7 — Deleting Rules](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-7-deleting-rules)
Knowing how to delete firewall rules is just as important as knowing how to create them. There are two different ways to specify which rules to delete: by rule number or by its human-readable denomination (similar to how the rules were specified when they were created).
### [Deleting a UFW Rule By Number](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#deleting-a-ufw-rule-by-number)
To delete a UFW rule by its number, first you’ll want to obtain a numbered list of all your firewall rules. The UFW status command has an option to display numbers next to each rule, as demonstrated here:
```
<p>Numbered Output:</p>Status: active
To Action From
-- ------ ----
[ 1] 22 ALLOW IN 15.15.15.0/24
[ 2] 80 ALLOW IN Anywhere
```
If you decide that you want to delete rule number **2**, the one that allows port 80 (HTTP) connections, you can specify it in a UFW delete command like this:
```
<p>Output</p>Deleting:
allow 80
Proceed with operation (y|n)? y
Rule deleted
```
This will prompt for a confirmation then delete rule 2, which allows HTTP connections. Note that if you have IPv6 enabled, you would want to delete the corresponding IPv6 rule as well.
### [Deleting a UFW Rule By Name](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#deleting-a-ufw-rule-by-name)
Instead of using rule numbers, you may also refer to a rule by its human readable denomination, which is based on the type of rule (typically `allow` or `deny`) and the service name or port number that was the target for this rule, or the application profile name in case that was used. For example, if you want to delete an `allow` rule for an application profile called `Apache Full` that was previously enabled, you can use:
```
<p>Output</p>Rule deleted
Rule deleted (v6)
```
The `delete` command works the same way for rules that were created referencing a service by its name or port. For example, if you previously set a rule to allow HTTP connections with `sudo ufw allow http`, this is how you could delete said rule:
```
<p>Output</p>Rule deleted
Rule deleted (v6)
```
Because service names are interchangeable with port numbers when specifying rules, you could also refer to the same rule as `allow 80`, instead of `allow http`:
```
<p>Output</p>Rule deleted
Rule deleted (v6)
```
When deleting UFW rules by name, both IPv4 and IPv6 rules are deleted if they exist.
## [Step 8 — Checking UFW Status and Rules](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-8-checking-ufw-status-and-rules)
At any time, you can check the status of UFW with this command:
If UFW is disabled, which it is by default, you’ll see something like this:
```
<p>Output</p>Status: inactive
```
If UFW is active, which it should be if you followed Step 3, the output will say that it’s active and it will list any rules that are set. For example, if the firewall is set to allow SSH (port `22`) connections from anywhere, the output might look something like this:
```
<p>Output</p>Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN Anywhere
```
Use the `status` command if you want to check how UFW has configured the firewall.
## [Step 9 — Disable or Reset Firewall](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#step-9-disable-or-reset-firewall)
If you decide you don’t want to use the UFW firewall, you can deactivate it with this command:
```
<p>Output</p>Firewall stopped and disabled on system startup
```
Any rules that you created with UFW will no longer be active. You can always run `sudo ufw enable` if you need to activate it later.
If you already have UFW rules configured but you decide that you want to start over, you can use the reset command:
```
<p>Output</p>Resetting all rules to installed defaults. This may disrupt existing ssh
connections. Proceed with operation (y|n)? y
Backing up 'user.rules' to '/etc/ufw/user.rules.20210729_170353'
Backing up 'before.rules' to '/etc/ufw/before.rules.20210729_170353'
Backing up 'after.rules' to '/etc/ufw/after.rules.20210729_170353'
Backing up 'user6.rules' to '/etc/ufw/user6.rules.20210729_170353'
Backing up 'before6.rules' to '/etc/ufw/before6.rules.20210729_170353'
Backing up 'after6.rules' to '/etc/ufw/after6.rules.20210729_170353'
```
This will disable UFW and delete any rules that were previously defined. This should give you a fresh start with UFW. Keep in mind that the default policies won’t change to their original settings, if you modified them at any point.
Deploy your frontend applications from GitHub using [DigitalOcean App Platform](https://www.digitalocean.com/products/app-platform). Let DigitalOcean focus on scaling your app.
## [Conclusion](https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-with-ufw-on-ubuntu#conclusion)
Your firewall is now configured to allow (at least) SSH connections. Be sure to allow any other incoming connections that your server requires, while limiting any unnecessary connections, so your server will be functional and secure.
To learn about more common [UFW configurations](https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands), check out the [UFW Essentials: Common Firewall Rules and Commands](https://www.digitalocean.com/community/tutorials/ufw-essentials-common-firewall-rules-and-commands) tutorial.

10
ssh_server/resources/jail.local Normal file
View File

@ -0,0 +1,10 @@
[sshd]
enabled = true
filter = sshd
port = ssh
backend = systemd
logpath = /var/log/auth.log
maxretry = 3
findtime = 300
bantime = 360000
ignoreip = 127.0.0.1