diff --git a/docs/guides/file_sharing/sftp.md b/docs/guides/file_sharing/sftp.md index 28fa24fdfa..46db24c5a8 100644 --- a/docs/guides/file_sharing/sftp.md +++ b/docs/guides/file_sharing/sftp.md @@ -1,5 +1,5 @@ --- -title: Secure Server - sftp +title: Secure server - `sftp` author: Steven Spencer contributors: Ezequiel Bruni, Ganna Zhyrnova tested_with: 8.5, 8.6, 9.0 @@ -11,22 +11,24 @@ tags: - web - multisite --- -# Secure server - SFTP with SSH lock down procedures + + +## (with SSH lock down procedures) ## Introduction -When the SSH protocol itself is secure, it may seem strange to have a document dedicated to the "secure" use of SFTP (a part of openssh-server package). But most system administrators do not want to open SSH to everyone to implement SFTP for everyone. This document describes implementing a change root (**chroot**) jail for SFTP while limiting SSH access. +When the SSH protocol itself is secure, it might seem strange to have a document dedicated to the "secure" use of `sftp` (a part of openssh-server package). But most system administrators do not want to open SSH to everyone to implement `sftp` for everyone. This document describes implementing a change root (**chroot**) jail for `sftp` while limiting SSH access. -Many documents deal with creating an SFTP chroot jail, but most do not consider a use case where the user might be accessing a web directory on a server with many websites. This document deals with that. If that is not your use case, you can quickly adapt these concepts to different situations. +Many documents deal with creating an `sftp` chroot jail, but most do not consider a use case where the user might be accessing a web directory on a server with many websites. This document deals with that. If that is not your use case, you can quickly adapt these concepts to different situations. -The author also feels that it is necessary when making the chroot jail document for SFTP to also discuss the other things that you should do as a system administrator to minimize the target that you offer to the world via SSH. For this reason, division of this document is in four parts: +The author also feels that it is necessary when making the chroot jail document for `sftp` to discuss the other things needed as a system administrator to minimize the target that you offer to the world by using SSH. For this reason, division of this document is in four parts: 1. The first deals with the general information that you will use for the entire document. 2. The second deals with the chroot setup. If you stop there that is totally up to you. 3. The third part deals with setting up public/private key SSH access for your system administrators and turning off remote password-based authentication. 4. This document's fourth and last section deals with turning off remote root logins. -All of these steps will allow you to offer secure SFTP access for your customers while minimizing the possibility that a bad actor will compromise port 22 (the one reserved for SSH access). +These steps offer secure `sftp` access for your customers while minimizing the possibility that a bad actor will compromise port 22 (the one reserved for SSH access). !!! Note "chroot jails for beginners:" @@ -34,25 +36,21 @@ All of these steps will allow you to offer secure SFTP access for your customers From there on, that process or program can *only* access that folder and its subfolders. -!!! tip "Updates for Rocky Linux 8.x and 9.x" - - This document has been updated to include new changes in version 8.6 that will make this procedure even safer. If you are using 8.6 or newer, or any version of 9.x, this procedure should work for you. The sections specific to Rocky Linux 8.5 have been removed, as the current release of 8 (8.8 at the time of the rewrite) should be where any version of 8.x is after updating packages. - ## Part 1: General information ### Assumptions and conventions Assumptions are that: -- you are comfortable executing commands at the command line. -- you can use a command line editor, such as `vi` (used here), `nano`, `micro`, etc. -- you understand basic Linux commands used for adding groups and users, or can follow along well. -- your multisite website is like this: [Apache Multisite](../web/apache-sites-enabled.md) -- you have already installed `httpd` (Apache) on the server. +- You are comfortable executing commands at the command line +- You can use a command line editor, such as `vi` (used here), `nano`, `micro`, and so on +- You understand basic Linux commands used for adding groups and users, or can follow along well +- Your multisite website is similar to this: [Apache Multisite](../web/apache-sites-enabled.md) +- You have already installed `httpd` (Apache) on the server !!! note - You can apply these concepts to any server set up and any web daemon. While we are assuming Apache here, you can also use this for Nginx. + You can apply these concepts to any server set up and any web daemon. While the assumption here is Apache, you can also use this for Nginx. ### Sites, users, administrators @@ -84,7 +82,7 @@ dnf install openssh-server #### Directories -The directory path structure will be `/var/www/sub-domains/[ext.domainname]/html` and the `html` directory in this path will be the chroot jail for the SFTP user. +The directory path structure will be `/var/www/sub-domains/[ext.domainname]/html` and the `html` directory in this path will be the chroot jail for the `sftp` user. Creating the configuration directories: @@ -130,7 +128,7 @@ vi /etc/httpd/sites-available/com.site1 !!! note - The example only uses the HTTP protocol. Any real website would need the HTTPS protocol configuration, SSL certificates, and possibly more. + The example only uses the HTTP protocol. Any real website would need the HTTPS protocol configuration, SSL/TLS certificates, and possibly more. ```bash @@ -205,7 +203,7 @@ systemctl enable --now httpd ### User creation -For our example environment, the assumption is that none of the users exist yet. Start with your administrative users. Note that at this point in your process, you can still log in as the root user to add the other users and set them up the way you want. When the users are setup and tested, you can remove root logins. +For this example environment, the assumption is that none of the users exist yet. Start with your administrative users. Note that at this point in your process, you can still log in as the root user to add the other users and set them up the way you want. When the users are setup and tested, you can remove root logins. #### Administrators @@ -214,9 +212,9 @@ useradd -g wheel ssimpson useradd -g wheel lblakely ``` -By adding our users to the group "wheel" you give them `sudo` access. +By adding your users to the group "wheel" you give them `sudo` access. -You still need a password for `sudo` access. There are ways around this, but none are all that secure. Frankly, if you have problems with security using `sudo` on your server, then you have much bigger problems with your entire setup. Set the two administrative passwords with secure passwords: +You still need a password for `sudo` access. Set the two administrative passwords with secure passwords: ```bash passwd ssimpson @@ -239,9 +237,9 @@ Test access to the server with `ssh` for your two administrative users. You shou You will be ready for the next step if this works for all administrative users. -#### Web users (SFTP) +#### Web users (`sftp`) -You need to add our web users. That `../html` directory structure already exists, so you do not want to create it when adding the user, but you *do* want to specify it. You also do not want any login other than with SFTP so you need to use a shell that denies logins. +You need to add your web users. That `../html` directory structure already exists, so you do not want to create it when adding the user, but you *do* want to specify it. You also do not want any login other than with `sftp` so you need to use a shell that denies logins. ```bash useradd -M -d /var/www/sub-domains/com.site1/html -g apache -s /usr/sbin/nologin mybroken @@ -258,7 +256,7 @@ Breaking down those commands a bit: **Note:** For an Nginx server, you would use `nginx` as the group. -Our SFTP users still need passwords. Setup a secure password for each now. You have already seen the command output above: +Your `sftp` users still need passwords. Setup a secure password for each now. You have already seen the command output earlier: ```bash passwd mybroken @@ -275,7 +273,7 @@ passwd myfixed cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak ``` -You need to make one change to the `/etc/ssh/sshd_config` file. You are going to build a template to make your web directory changes outside of the configuration file and script the additions you are going to need. +You need to make one change to the `/etc/ssh/sshd_config` file. You are going to build a template to make your web directory changes outside of the configuration file and script the additions you need. First, make the manual change you need: @@ -300,7 +298,7 @@ Subsystem sftp internal-sftp Save and exit the file. -The `sftp-server` and `internal-sftp` are part of OpenSSH. The `internal-sftp`, while not too different from the `sftp-server`, simplifies configurations using `ChrootDirectory` to force a different file system root on clients. That is why you use `internal-sftp`. +The `sftp-server` and `internal-sftp` are part of OpenSSH. The `internal-sftp`, while not too different from the `sftp-server`, simplifies configuration by using `ChrootDirectory` to force a different file system root on clients. That is why you use `internal-sftp`. ### The template and script @@ -337,9 +335,9 @@ mkdir /usr/local/sbin/templates #### The script and `sshd_config` changes -With the releases of Rocky Linux 8.6 and 9.0, a new option for the `sshd_config` file allows for drop-in configurations. This is a **GREAT** change. This means that you will make a single additional change to the `sshd_config` file, and our script will build out sftp changes in a separate configuration file. This new change makes things even safer. Safety is good!! +With recent releases of Rocky Linux, a new option for the `sshd_config` file allows for drop-in configurations. This is a **GREAT** change. This means that you will make a single additional change to the `sshd_config` file, and your script will build out `sftp` changes in a separate configuration file. This new change makes things even safer. -Because of the changes allowed for the `sshd_config` file in Rocky Linux 8.6 and 9.0, our script will use a new drop-in configuration file: `/etc/ssh/sftp/sftp_config`. +Your script will use a new drop-in configuration file: `/etc/ssh/sftp/sftp_config`. To start with, create that directory: @@ -347,25 +345,25 @@ To start with, create that directory: mkdir /etc/ssh/sftp ``` -Now make a backup copy of the `sshd_config`: +Make a backup copy of the `sshd_config`: ```bash cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak ``` -And finally edit the `sshd_config` file, scroll to the very bottom of the file, and add this line: +Finally edit the `sshd_config` file, scroll to the very bottom of the file, and add this line: ```bash Include /etc/ssh/sftp/sftp_config ``` -Save your changes and exit the file. You will need to restart `sshd` but our script will do that for us after you update `sftp_config` file, so create the script and run it. +Save your changes and exit the file. You will need to restart `sshd` but your script will do that for you after you update `sftp_config` file, so create the script and run it. ```bash vi /usr/local/sbin/webuser ``` -And put this code in it: +Add this code to the file: ```bash #!/bin/bash @@ -431,11 +429,11 @@ And put this code in it: !!! tip - If you take a look at the script above, you will note the changing of the delimiter that `sed` uses by default from `/` to `,`. `sed` allows you to use any single-byte character as a delimiter. What you are searching for in the file has a bunch of "/" characters in it, and you would have had to escape each one (add a "\" in front of them) to search and replace these strings. Changing the delimiter makes this infinitely easier to do because it eliminates the need to do those escapes. + If you examine the script above, you will note the changing of the delimiter that `sed` uses by default from `/` to `,`. `sed` allows you to use any single-byte character as a delimiter. What you are searching for in the file has a bunch of "/" characters in it, and you would have had to escape each one (add a "\" in front of them) to search and replace these strings. Changing the delimiter makes this infinitely easier to do because it eliminates the need to do those escapes. -A couple of things are notable about the script and about an SFTP chroot in general. First, you prompt for the needed information and echo it back to the user for verification. If you answer "N" to the confirmation question, the script bails and does nothing. The script for 8.5 makes a backup of `sshd_config` (`/etc/ssh/sshd_config.bak`) the way it was prior to our running of the script. The 8.6 or 9.0 script does the same for the `sftp_config` file (`/etc/ssh/sftp/sftp_config.bak`). In this way, if you make errors in an entry, you can restore the appropriate backup file and restart `sshd` to get things working again. +A couple of things are notable about the script and about an `sftp` chroot in general. First, you prompt for the needed information and echo it back to the user for verification. If you answer "N" to the confirmation question, the script bails and does nothing. The script makes a backup copy of the `sftp_config` file (`/etc/ssh/sftp/sftp_config.bak`). In this way, if you make errors in an entry, you can restore the appropriate backup file and restart `sshd` to get things working again. -The SFTP chroot requires that the path given in the `sshd_config` has root ownership. For this reason, you do not need the `html` directory added to the end of the path. Once the user authenticates, the chroot will switch the user's home directory, in this case the `../html` directory, to whichever domain you are entering. Your script has appropriately changed the owner of the `../html` directory to the sftpuser and the apache group. +The `sftp` chroot requires that the path given in the `sshd_config` has root ownership. For this reason, you do not need the `html` directory added to the end of the path. Once the user authenticates, the chroot will switch the user's home directory, in this case the `../html` directory, to whichever domain you are entering. Your script has appropriately changed the owner of the `../html` directory to the `sftpuser` and the `apache` group. Make the script executable: @@ -443,11 +441,11 @@ Make the script executable: chmod +x /usr/local/sbin/webuser ``` -Run the script for our two test domains. +Run the script for your two test domains. -### Testing SSH denial and SFTP access +### Testing SSH denial and `sftp` access -First, test with `ssh` from another machine to our host machine as one of the SFTP users. You should receive this after entering a password: +First, test with `ssh` from another machine to your host machine as one of the `sftp` users. You should receive this after entering a password: ```bash This service allows sftp connections only. @@ -455,32 +453,32 @@ This service allows sftp connections only. #### Graphical tool testing -If you *do* receive that message, the next thing is to test SFTP access. For ease of testing, you can use a graphical FTP application that supports SFTP such as Filezilla. In such cases, your fields will look something like this: +If you *do* receive that message, the next thing is to test `sftp` access. For ease of testing, you can use a graphical FTP application that supports `sftp` such as Filezilla. In such cases, your fields will be similar to this: - **Host:** sftp://hostname_or_IP_of_the_server - **Username:** (Example: myfixed) -- **Password:** (the password of the SFTP user) -- **Port:** If you use SSH and SFTP on the default port 22, enter that port +- **Password:** (the password of the `sftp` user) +- **Port:** If you use SSH and `sftp` on the default port 22, enter that port -Once filled in, you can click the "Quickconnect" (Filezilla) button and you will connect to the `../html` directory of the appropriate site. Double-click on the "html" directory to put yourself inside it and try to drop a file into the directory. If you are successful, everything is working correctly. +Once filled in, you can click the "Quickconnect" (Filezilla) button and you will connect to the `../html` directory of the appropriate site. Double-click the "html" directory to put yourself inside it and try to drop a file into the directory. If you are successful, everything is working correctly. #### Command line tool testing You can do all of this from the command line on a machine with SSH installed (most Linux installations). Here is a brief overview of the command line method for connection and a few options: -- sftp username (Example: myfixed@ hostname or IP of the server: sftp myfixed@192.168.1.116) +- `sftp` username (Example: myfixed@ hostname or IP of the server: sftp myfixed@192.168.1.116) - Enter the password when prompted -- cd html (change to the html directory) -- pwd (should show that you are in the html directory) -- lpwd (should show your local working directory) -- lcd PATH (should change your local working directory to something you want to use) -- put filename (will copy a file to `..html` directory) +- `cd html` (change to the html directory) +- `pwd` (should show that you are in the html directory) +- `lpwd` (should show your local working directory) +- `lcd` PATH (should change your local working directory to something you want to use) +- `put filename` (will copy a file to `..html` directory) -For an exhaustive list of options and more, view the [SFTP manual page](https://man7.org/linux/man-pages/man1/sftp.1.html). +For an exhaustive list of options and more, view the [`sftp` manual page](https://man7.org/linux/man-pages/man1/sftp.1.html). ### Web test files -For our dummy domains, you want to create a couple of `index.html` files that you can populate the `../html` directory with. When created, you need to put them in the directory for each domain with the SFTP credentials for that domain. These files are simplistic. You just want something to verify that your sites are up and running and that SFTP is working as expected. Here is an example of this file. You can change it if you want to: +For your test domains, you want to create a couple of `index.html` files that you can populate the `../html` directory with. When created, you need to put them in the directory for each domain with the `sftp` credentials for that domain. These files are simplistic. You just want something to verify that your sites are up and running and that `sftp` is working as expected. Here is an example of this file. You can change it if you want to: ```html @@ -499,7 +497,7 @@ For our dummy domains, you want to create a couple of `index.html` files that yo ### Web tests -You need to change the *hosts* file on your workstation to test that these files show up and load as expected. For Linux that will be `sudo vi /etc/hosts` and add in the IP and host names you are testing with like this: +You need to change the *hosts* file on your workstation to test that these files show up and load as expected. For Linux that will be `sudo vi /etc/hosts` and add in the IP and host names you are testing with: ```bash 127.0.0.1 localhost @@ -523,7 +521,7 @@ Open your web browser and ensure that your `index.html` file for each domain dis Note that you will use concepts discussed in the document [SSH Public and Private Keys](../security/ssh_public_private_keys.md) here, but also improving on it. If you are new to the process, read that article before continuing. -### Creating the public/private key pairs +### Creating the public and private key pairs From one of the administrative user's workstations command line, (Example: lblakely) do the following: @@ -538,25 +536,25 @@ Generating public/private rsa key pair. Enter file in which to save the key (/home/lblakely/.ssh/id_rsa): ``` -Hit enter to create the private key in the location shown. This will give you this dialog: +Hit ++enter++ to create the private key in the location shown. This will give you this dialog: ```text Enter passphrase (empty for no passphrase): ``` -You will need to decide personally whether you need a passphrase for this step. The author always just hits enter here. +You will need to decide personally whether you need a passphrase for this step. The author always just hits ++enter++ here. ```text Enter same passphrase again: ``` -Repeat whatever passphrase you entered earlier or enter for none. +Repeat whatever passphrase you entered earlier or ++enter++ for none. -At this point the public and private keys exist. Repeat this step for our other system administrator example user. +At this point the public and private keys exist. Repeat this step for your other system administrator example user. -### Transferring the public key to the SFTP server +### Transferring the public key to the `sftp` server -The next step is to export our key to the server. In reality, a system administrator responsible for managing multiple servers will transfer their public key to all the servers they are responsible for. +The next step is to export your key to the server. In reality, a system administrator responsible for managing multiple servers will transfer their public key to all the servers they are responsible for. The user can send the key to the server securely with `ssh-id-copy` when created: @@ -568,18 +566,18 @@ The server will prompt for the user's password one time, and copy the key into * ```bash Number of key(s) added: 1 +``` -Now try logging into the machine, with: "ssh 'lblakely@192.168.1.116'" +Try logging into the machine, with: "ssh 'lblakely@192.168.1.116'" and check to make sure that only the key(s) you wanted were added. -``` If you are able to login with this account, repeat the process with the other administrator. ### Allowing ONLY key-based logins -If everything has worked out as planned and our keys for our administrators are now in place on the SFTP server, you need to turn off password authentication on the server. For safety sake, ensure you have two connections to the server to reverse any changes if you have unintended consequences. +If everything has worked out as planned and your keys for your administrators are now in place on the `sftp` server, you need to turn off password authentication on the server. For safety sake, ensure you have two connections to the server to reverse any changes if you have unintended consequences. -To accomplish this step, you need to change the `sshd_config` again, and just like before, you want to make a backup of the file first: +To accomplish this step, you need to change the `sshd_config` again, and just as before, you want to make a backup of the file first: ```bash cp -f /etc/ssh/sshd_config /etc/ssh/sshd_config.bak @@ -609,7 +607,7 @@ Public key authentication is on by default, but ensure that it is by removing th #PubkeyAuthentication yes ``` -So that it reads: +So it reads: ```text PubkeyAuthentication yes @@ -623,19 +621,19 @@ Save your changes. Cross your fingers, and restart `sshd`: systemctl restart sshd ``` -Attempting to login as one of your administrative users to the server using their keys should work just like before. If not, restore your backup, ensure you have followed all of the steps, and try again. +Attempting to login as one of your administrative users to the server with their keys should work as before. If not, restore your backup, ensure you have followed all the steps, and try again. ## Part 4: Turn off remote root login -You have functionally done that already. If you attempt to login with the root user to the server now, you will get the following: +You have functionally done that already. If you try to login with the root user to the server now, you will get the following: ```bash root@192.168.1.116: Permission denied (publickey,gssapi-keyex,gssapi-with-mic). ``` -But you want to ensure that someone cannot create a public/private key for the root user and access the server that way. To do this, you will need one final step. You will make that change...You guessed it! ... in the `sshd_config` file. +Still, you want to ensure that someone cannot create a public and private key for the root user and access the server that way. To do this, you will need one final step. You will make that change in the `sshd_config` file. -Just like every other step here when changing the `sshd_config` file, you want to make a backup copy of the file before continuing: +Just as earlier, you want to make a backup copy of the file before continuing: ```bash cp -f /etc/ssh/sshd_config /etc/ssh/sshd_config.bak @@ -665,7 +663,7 @@ Save, quit out of the file, and restart `sshd`: systemctl restart sshd ``` -A login as the root user remotely over `ssh` will get the same denial message as before, but will **still** not be able to access the server even if they have a public/private key pair for root. +A login as the root user remotely over `ssh` will get the same denial message as before, but will **still** not be able to access the server even if they have a public and private key pair for root. ## Addendum: New system administrators @@ -675,7 +673,7 @@ Not discussed yet is what happens when adding another system administrator. `ssh This solution assumes physical access to the server and that the server is physical hardware and not virtual (container or VM): -- Add the user to the "wheel" group on the SFTP server +- Add the user to the "wheel" group on the `sftp` server - Have the user generate his SSH public and private keys - Using a USB drive, copy the public key to the drive and physically walk it over to the server and install it manually in the new system administrators `/home/[username]/.ssh` directory @@ -683,16 +681,16 @@ This solution assumes physical access to the server and that the server is physi This solution is prone to human error, but since it is not done often, it would probably be OK if carefully done: -- Add the user to the "wheel" group on the SFTP server +- Add the user to the "wheel" group on the `sftp` server - Have another system administrator who already has key based authentication, temporarily turn on "PasswordAuthentication yes" in the `sshd_config` file and restart `sshd` -- Have the new system administrator run `ssh-copy-id` using their password to copy the ssh key to the server. +- Have the new system administrator run `ssh-copy-id` using their password to copy the SSH key to the server. ### Solution three - script the process -This process uses a system administrator that already has key-based access and a script that must run with `bash [script-name]` to accomplish the same thing as "Solution Two" above: +This process uses a system administrator that already has key-based access and a script that must run with `bash [script-name]` to accomplish the same thing as "Solution Two" earlier: -- manually edit the `sshd_config` file and remove the remarked-out line that looks like this: `#PasswordAuthentication no`. This line is documenting the process of turning password authentication off, but it will get in the way of the script below, because our script will look for the first occurrence of `PasswordAuthentication no` and later the first occurrence of `PasswordAuthentication yes`. If you remove this one line, our script will work fine. -- create a script on the SFTP server called "quickswitch", or whatever you want to call it. The contents of this script would look like this: +- Manually edit the `sshd_config` file and remove the remarked-out line that looks like this: `#PasswordAuthentication no`. This line is documenting the process of turning password authentication off, but it will get in the way of the script below, because your script will look for the first occurrence of `PasswordAuthentication no` and later the first occurrence of `PasswordAuthentication yes`. If you remove this one line, the script will work fine. +- Create a script on the `sftp` server called "quickswitch", or whatever you want to call it. The contents of this script would look like this: ```bash #!/bin/bash @@ -709,10 +707,10 @@ read yn echo "Changes reversed" ``` -Script explanation: You do not make this script executable. The reason is that you do not want it to run accidentally. The script runs (as noted above) like this: `bash /usr/local/sbin/quickswitch`. This script makes a backup copy of the `sshd_config` file just like all of our other examples above. It then edits the `sshd_config` file in place and searches for the *FIRST* occurrence of `PasswordAuthentication no` and changes it to `PasswordAuthentication yes` then restarts `sshd` and waits for the script user to hit ++enter++ before continuing. The system administrator running the script would be in communication with the new system administrator, and once that new system administrator runs `ssh-copy-id` to copy his key to the server, the system administrator who is running the script hits enter and that reverses the change. +Script explanation: You do not make this script executable. The reason is that you do not want it to run accidentally. The script runs (as noted) with this: `bash /usr/local/sbin/quickswitch`. This script makes a backup copy of the `sshd_config` file. It then edits the `sshd_config` file in place and searches for the *FIRST* occurrence of `PasswordAuthentication no` and changes it to `PasswordAuthentication yes` then restarts `sshd` and waits for the script user to hit ++enter++ before continuing. The system administrator running the script would be in communication with the new system administrator. When that new system administrator runs `ssh-copy-id` to copy his key to the server, the system administrator who is running the script hits ++enter++ and that reverses the change. In short, many ways exist for adding another system administrator after the implementation of SSH lock down procedures. ## Conclusion -This document is extensive. It will make a multisite web server more secure and less prone to attack vectors over SSH when turning on SFTP for customer access. SFTP is much more secure than FTP, even if you use a really *GOOD* FTP server and have them set up as securely as possible as noted in this [document on VSFTPD](secure_ftp_server_vsftpd.md). By implementing *all* of the steps in this document, you can feel comfortable opening up port 22 (SSH) to your public zone and still know that your environment is secure. +This document is extensive. It will make a multisite web server more secure and less prone to attack vectors over SSH when turning on `sftp` for customer access. `sftp` is much more secure than FTP, even if you use a really *GOOD* FTP server and have them set up as securely as possible as noted in this [document on VSFTPD](secure_ftp_server_vsftpd.md). By implementing *all* of the steps in this document, you can feel comfortable opening up port 22 (SSH) to your public zone and still know that your environment is secure.