One place for hosting & domains

      An Overview of Linode's Cloud Manager for Classic Manager Users


      Updated by Linode

      Contributed by
      Linode

      Linode’s Classic Manager will be retired on January 31, 2020. At that time, all users will be migrated to the new Cloud Manager when logging in to manage your infrastructure on Linode.

      There have been substantial updates to Cloud Manager since it was introduced back in 2014. Cloud Manager has many new features, including an updated look-and-feel, modern user-interface, mobile support, and easy access to our recently released products. It’s also implemented solely atop our public APIv4.

      Development work for Cloud Manager will continue beyond January 31, 2020. As always, your feedback for Cloud Manager or any other aspect of our platform is welcome at [email protected]

      Note

      We will continue to support APIv3 and the APIv3-based CLI beyond January 31, 2020.

      In this Guide

      If you are a Classic Manager user, this guide will provide an overview of the features and services available in Linode’s Cloud Manager. Some of the topics that will be discussed are:

      • An introduction to each section of the Cloud Manager, including links to related guides throughout our documentation library.
      • Specific features that you may need help finding due to differences in location between Classic Manager and Cloud Manager
      • Settings that might make your overall Cloud Manager experience better

      Linodes

      The Linodes section of Cloud Manager allows you to create and manage your Linodes. Each Linode instance in Cloud Manager includes:

      • Summary information about your Linode, like CPU usage, IPv4 and IPv6 traffic, and Disk IO
      • Access to any of your Linode’s attached Volumes and the ability to create a Volume
      • Networking information and features, including the ability to add IPv4 and IPv6 addresses, IP transfer and IP sharing
      • The ability to resize your Linode, boot your Linode into Rescue Mode, and rebuild your Linode
      • Access to Linode’s Backup service
      • An Activity Feed that displays any relevant events related to this Linode
      • Settings that allow you to update your Linode’s label, reset your Linode’s root password, manage system usage email notifications, manage Watchdog (Linode’s automatic reboot feature), and delete your Linode
      • An area to manage and create disks and configuration profiles
      • Cross data center migrations

      Find Your Disks

      In Classic Manager, Disks were located in the Linode Dashboard tab. In the Cloud Manager, Disks are now in the Disks/Configs tab of the Linode.

      1. Click the Linodes link in the sidebar menu and select the Linode whose disks you’d like to see.

      2. Then click the Disks/Configs tab. The disks are located in the Disks panel. Here you can add a disk, or for each individual disk, you can click the more options ellipses to get a drop down menu which will allow you to choose options such as Rename, Resize, Imagize, Clone, and Delete.

        Location of Cloud Manager Disks

      Reboot Your Linode

      You can reboot a Linode from two places within the Cloud manager.

      1. From your Linodes listing page, click the More Options Ellipses and select Reboot.

        Cloud Manager Linode List Menu Reboot Option

        If you have more than one Configuration Profile, a panel will appear to allow you to select which Configuration to boot. Select a Config and click the Submit button. Otherwise, a confirmation dialog will appear.

        Cloud Manager Reboot Detail Panel

      2. You can also reboot your Linode from within any Linode detail screen by clicking on the Status Icon. A drop down menu will appear, select Reboot.

        Cloud Manager Linode Detail Menu Reboot Option

        Again, if you have more than one Configuration Profile, a panel will appear to allow you to select which Configuration to boot. Select a Config and click the Submit button. Otherwise, a confirmation dialog will appear.

      Delete a Public IP Address

      You can delete public IP addresses in both Classic and Cloud managers. In Classic Manager, this was done under the Remote Access tab from the Linode you wished to modify. In Cloud Manager it is done in the Networking tab.

      1. Click Linodes from the sidebar menu.

      2. Choose the Linode you wish to modify to enter the Linode detail screen. Then, click on the Networking tab. Your IPv4 and IPv6 addresses will be listed here.

      3. Next to the public IPv4 address you wish to delete, click on the more options ellipses. Select the option to Delete IP from the drop down menu.

        Cloud Manager Delete a Public IP Address

      4. A confirmation popup will appear where you can confirm the operation.

        Note

        You must have at least one public IP on a Linode. If you attempt to delete the last public IP on a Linode you will receive an error message after you confirm the deletion.

      Volumes

      The Volumes section of Cloud Manager gives you access to Linode’s Block Storage service. To learn how to create, and manage Block Storage volumes using Cloud Manager, see our How to Use Block Storage with Your Linode guide.

      Find Volumes

      In Classic Manager, Volumes were found within a Linode’s Dashboard tab. In Cloud Manager, Volumes are their own top-level menu item in the sidebar.

      Cloud Manager Volumes

      Note

      Object Storage

      The Object Storage section of Cloud Manager gives you access to Linode’s Object Storage service which is a globally-available, S3-compatible method for storing and accessing data. The Object Storage service is not available in Classic Manager.

      To learn how to begin using Object Storage, view our How to Use Linode Object Storage guide. To access all available Object Storage guides, see the Object Storage section of our documentation site.

      NodeBalancers

      Linode’s NodeBalancers service provides load balancing for your applications and services ensuring that they are highly available for users. To learn how to get started with NodeBalancers using Cloud Manager, see our Getting Started with NodeBalancers guide.

      Domains (DNS Manager)

      The DNS Manager allows you to control and manage your domains. In Cloud Manager, the DNS Manager is located in the Domains link in the sidebar.

      Cloud Manager Domains

      For more information on Cloud Manager’s DNS Manager, see the following guides:

      Zone Files

      Cloud Manager does not include the Check Zone and Zone File features, since it automatically ensures that your Domain’s zone file does not contain any errors:

      • When creating a Zone File for a Domain, the Linode API v4 checks for any errors that may exist. If an error is found, the Cloud Manager will respond with the corresponding error. This means that the Cloud Manager will not allow you to create an invalid zone file.

      • Once your Domain and corresponding Zone File is created, you can use the dig command to further verify that each domain record contains the information you expect, for example:

        dig example.com
        dig example.com MX
        

        See the Use dig to Perform Manual DNS Queries guide for more details on the dig command.

      Longview

      The Longview section of Cloud Manager gives you access to Linode’s system data graphing service. It tracks metrics for CPU, memory, and network bandwidth, both aggregate and per-process, and it provides real-time graphs that can help expose performance problems. The Longview service offers both free and paid plan tiers.

      Longview is still being actively developed to reach parity with Classic Manager. To get started using Longview in Cloud Manager, see the Understanding Linode Longview guide.

      One-Click Apps

      The One-Click Apps section of Cloud Manager gives you access to apps that make it easy to deploy and configure software on a Linode. Some popular One-Click Apps are WordPress, Minecraft, and GitLab. We are actively adding new and useful One-Click apps. When a One-Click App is deployed, a new Linode is created and the appropriate software is installed with the configurations you provide. One-Click Apps are not available in Classic Manager.

      See How to Use Linode’s One-Click Apps to get started using One-Click Apps in Cloud Manager.

      Kubernetes

      The Kubernetes section of Cloud Manager gives you access to our managed Kubernetes service, the Linode Kubernetes Engine (LKE). LKE is a fully-managed container orchestration engine for deploying and managing containerized applications and workloads. LKE combines Linode’s ease of use and simple pricing with the infrastructure efficiency of Kubernetes. LKE is not available in Classic Manager.

      To get started using LKE, see our Tutorial for Deploying and Managing a Cluster with Linode Kubernetes Engine.

      StackScripts

      StackScripts provide Linode users with the ability to automate the deployment of custom systems on top of our default Linux distribution images. StackScripts are usually Bash scripts, stored in the Linode Cloud Manager, and can be accessed when you deploy a Linode. Linodes deployed with a StackScript run the script as part of the first boot process.

      To get started using StackScripts in Cloud Manager, see the Automate Deployment with StackScripts guide.

      Find StackScripts

      In Classic Manager, access to StackScripts was found under the Linodes tab. In Cloud Manager, StackScripts are their own top-level menu item in the sidebar.

      Cloud Manager StackScripts

      Images

      The Images section of Cloud Manager gives you access to Linode Images which allow you to take snapshots of your disks, and then deploy them to any Linode under your account. This can be useful for bootstrapping a master image for a large deployment, or retaining a disk for a configuration that you may not need running, but wish to return to in the future.

      To get started using Images with Cloud Manager, see Linode Images.

      Find Images

      In Classic Manager, access to image management was found in the Linodes tab. In Cloud Manager, Images are their own top-level menu item in the sidebar.

      Cloud Manager Images

      Account (Management and Billing)

      The Account section of Cloud Manager allows you to manage your account’s billing information and users, and to configure various account-wide settings.

      You can manage the following account and billing settings in the Account section of Cloud Manager:

      Find Credit Remaining

      In the Cloud Manager, to find the amount of available credit that you have:

      1. Click on the Account link from the sidebar menu.

      2. On the right hand side of the screen you’ll see the Billing Information section. If you have credit stored on your account, it’ll appear in green under the Current Balance field.

      Credits Listed under Current Balance

      Printing an Invoice

      In Cloud Manager you can download a printable PDF of your invoice from your list of invoices or from within an individual invoice.

      1. Navigate to your Account by clicking on Account in the sidebar.

      2. Click on the Recent Invoices menu item in the Billing section. This will expand to show you a list of your recent invoices. Each invoice has a Download PDF link next to it.

        Cloud Manager Download Invoice from Recent Invoices List

      3. You can also click on any invoice to view it within the Cloud Manager. At the top of the invoice there is a Download PDF button.

        Cloud Manager Download Invoice from Detail View

      Import Display Groups

      If you have used the Display Groups feature in the Classic Manager, you can import your Display Groups to the Cloud Manager as tags:

      1. Navigate to the Account page in the sidebar links menu, then click on the Settings tab.

      2. Expand the panel labeled Import Display Groups as Tags and then click Import Display Groups:

        Cloud Manager Import Display Groups

      3. A form will appear that lists your Display Groups and asks you to confirm the import action. To proceed, click the Import Display Groups Now button in this form.

        Note

        Importing your Display Groups is a one-time operation. If you don’t have any Display Groups configured in the Classic Manager this feature will not appear in the Cloud Manager.

      Password Management

      The Cloud Manager does not support forcing password expirations. Forcing password resets on a schedule is bad practice from a security perspective. Current security research indicates that forced password changes do more harm than good. If you want to force password resets for users of your Linode account, we recommend using a password manager for this purpose.

      My Profile

      The My Profile section of Cloud Manager provides access to various settings related to your Linode account’s profile. This area of Cloud Manager contains access to the following features and settings:

      API Keys / API Tokens

      API Keys from Classic Manager do not transfer. This means that if you have keys generated in Classic, you will not see them in Cloud Manager. In Cloud Manager, API Keys are called API Tokens (personal access tokens) and can be used for a variety of different uses.

      1. To generate a new personal access token, navigate to your profile by clicking on your username and select My Profile from the drop down menu. Then click on the API Tokens tab.

        Cloud Manager Add a Personal Access Token

      2. Click Add a Personal Access Token. A panel will display allowing you to give this token a label and choose the access rights you want users authenticated with the new token to have.

        Cloud Manager Add a Personal Access Token Panel

      3. When you have finished, click Submit to generate a new Personal Access Token. Copy the token and save it to a secure location before closing the popup. You will not be able to view this token through the Cloud Manager after closing the popup.

      Manage Email Event Notifications

      Email event notifications alert you when new events such as booting, shutting down, or updates to a Linode occur on your account. You can enable or disable email event notifications using the Cloud Manager.

      In Classic Manager email events notifications were managed in the Notifications tab under my profile. In Cloud Manager this is done in the Settings tab from My Profile.

      Cloud Manager Notification Settings

      User Interface Enhancements

      Compact Mode and Dark Mode

      Cloud Manager by default uses more whitespace on the screen. However, there is a Compact Mode which compresses this extra space and allows more information to be displayed on the screen. This setting is located at the bottom left hand corner of the screen when the gear icon is clicked. This is also where you can toggle on Dark Mode.

      Compact Mode Enabled

      Accessibility

      The Linode Cloud Manager has been built with accessibility in mind. Currently, the Cloud Manager is actively being developed to achieve WCAG 2.0 Level AA.

      We have received a lot of helpful feedback from our users regarding accessibility. While we have addressed a lot of your feedback, this is still a work in progress and will be iterated upon with time. Please contact [email protected] with any comments or requests regarding accessibility.

      Next Steps

      See the following guides for more features of Cloud Manager:

      If you still need help finding features in or using Cloud Manager, please contact Linode Support.

      This guide is published under a CC BY-ND 4.0 license.



      Source link

      How to Add and Delete Users on Ubuntu 18.04


      Introduction

      Adding and removing users on a Linux system is one of the most important system administration tasks to familiarize yourself with. When you create a new system, you are often only given access to the root account by default.

      While running as the root user gives you complete control over a system and its users, it is also dangerous and can be destructive. For common system administration tasks, it is a better idea to add an unprivileged user and carry out those tasks without root privileges. You can also create additional unprivileged accounts for any other users you may have on your system. Each user on a system should have their own separate account.

      For tasks that require administrator privileges, there is a tool installed on Ubuntu systems called sudo. Briefly, sudo allows you to run a command as another user, including users with administrative privileges. In this guide we will cover how to create user accounts, assign sudo privileges, and delete users.

      Prerequisites

      To follow along with this guide, you will need:

      Adding a User

      If you are signed in as the root user, you can create a new user at any time by typing:

      If you are signed in as a non-root user who has been given sudo privileges, you can add a new user by typing:

      Either way, you will be asked a series of questions. The procedure will be:

      • Assign and confirm a password for the new user
      • Enter any additional information about the new user. This is entirely optional and can be skipped by hitting ENTER if you don’t wish to utilize these fields.
      • Finally, you’ll be asked to confirm that the information you provided was correct. Enter Y to continue.

      Your new user is now ready for use. You can now log in using the password that you entered.

      If you need your new user to have access to administrative functionality, continue on to the next section.

      Granting a User Sudo Privileges

      If your new user should have the ability to execute commands with root (administrative) privileges, you will need to give the new user access to sudo. Let’s examine two approaches to this problem: adding the user to a pre-defined sudo user group, and specifying privileges on a per-user basis in sudo’s configuration.

      Adding the New User to the Sudo Group

      By default, sudo on Ubuntu 18.04 systems is configured to extend full privileges to any user in the sudo group.

      You can see what groups your new user is in with the groups command:

      Output

      newuser : newuser

      By default, a new user is only in their own group which adduser creates along with the user profile. A user and its own group share the same name. In order to add the user to a new group, we can use the usermod command:

      The -aG option here tells usermod to add the user to the listed groups.

      Specifying Explicit User Privileges in /etc/sudoers

      As an alternative to putting your user in the sudo group, you can use the visudo command, which opens a configuration file called /etc/sudoers in the system’s default editor, and explicitly specify privileges on a per-user basis.

      Using visudo is the only recommended way to make changes to /etc/sudoers, because it locks the file against multiple simultaneous edits and performs a sanity check on its contents before overwriting the file. This helps to prevent a situation where you misconfigure sudo and are prevented from fixing the problem because you have lost sudo privileges.

      If you are currently signed in as root, type:

      If you are signed in as a non-root user with sudo privileges, type:

      Traditionally, visudo opened /etc/sudoers in the vi editor, which can be confusing for inexperienced users. By default on new Ubuntu installations, visudo will instead use nano, which provides a more convenient and accessible text editing experience. Use the arrow keys to move the cursor, and search for the line that looks like this:

      /etc/sudoers

      root    ALL=(ALL:ALL) ALL
      

      Below this line, add the following highlighted line. Be sure to change newuser to the name of the user profile that you would like to grant sudo privileges:

      /etc/sudoers

      root    ALL=(ALL:ALL) ALL
      newuser ALL=(ALL:ALL) ALL
      

      Add a new line like this for each user that should be given full sudo privileges. When you are finished, you can save and close the file by hitting CTRL+X, followed by Y, and then ENTER to confirm.

      Testing Your User’s Sudo Privileges

      Now, your new user is able to execute commands with administrative privileges.

      When signed in as the new user, you can execute commands as your regular user by typing commands as normal:

      You can execute the same command with administrative privileges by typing sudo ahead of the command:

      You will be prompted to enter the password of the regular user account you are signed in as.

      Deleting a User

      In the event that you no longer need a user, it is best to delete the old account.

      You can delete the user itself, without deleting any of their files, by typing the following command as root:

      If you are signed in as another non-root user with sudo privileges, you could instead type:

      If, instead, you want to delete the user’s home directory when the user is deleted, you can issue the following command as root:

      • deluser --remove-home newuser

      If you’re running this as a non-root user with sudo privileges, you would instead type:

      • sudo deluser --remove-home newuser

      If you had previously configured sudo privileges for the user you deleted, you may want to remove the relevant line again by typing:

      Or use this if you are a non-root user with sudo privileges:

      root    ALL=(ALL:ALL) ALL
      newuser ALL=(ALL:ALL) ALL   # DELETE THIS LINE
      

      This will prevent a new user created with the same name from being accidentally given sudo privileges.

      Conclusion

      You should now have a fairly good handle on how to add and remove users from your Ubuntu 18.04 system. Effective user management will allow you to separate users and give them only the access that they are required to do their job.

      For more information about how to configure sudo, check out our guide on how to edit the sudoers file here.



      Source link

      How To Set Up vsftpd for a User’s Directory on Debian 10


      Introduction

      FTP, short for File Transfer Protocol, is a network protocol that was once widely used for moving files between a client and server. It has since been replaced by faster, more secure, and more convenient ways of delivering files. Many casual internet users expect to download directly from their web browser with https, and command-line users are more likely to use secure protocols such as the scp or SFTP.

      FTP is still used to support legacy applications and workflows with very specific needs. If you have a choice of what protocol to use, consider exploring the more modern options. When you do need FTP, however, vsftpd is an excellent choice. Optimized for security, performance, and stability, vsftpd offers strong protection against many security problems found in other FTP servers and is the default for many Linux distributions.

      In this tutorial, you’ll configure vsftpd to allow a user to upload files to their home directory using FTP, with login credentials secured by SSL/TLS.

      Prerequisites

      To follow along with this tutorial you will need:

      • A Debian 10 server, and a non-root user with sudo privileges. You can learn more about how to create a user with these privileges in our Initial Server Setup with Debian 10 guide.

      Step 1 — Installing vsftpd

      Let’s start by updating our package list and installing the vsftpd daemon:

      • sudo apt update
      • sudo apt install vsftpd

      When the installation is complete, copy the configuration file so you can start with a blank configuration, and save the original as a backup:

      • sudo cp /etc/vsftpd.conf /etc/vsftpd.conf.orig

      With a backup of the configuration in place, we’re ready to configure the firewall.

      Step 2 — Opening the Firewall

      Let’s check the firewall status to see if it’s enabled. If it is, we’ll ensure that FTP traffic is permitted so firewall rules don’t block our tests. This guide assumes that you have UFW installed, following Step 4 in the initial server setup guide.

      Check the firewall status:

      In this case, only SSH is allowed through:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6)

      You may have other rules in place or no firewall rules at all. Since only SSH traffic is permitted in this case, we’ll need to add rules for FTP traffic.

      Let's open ports 20 and 21 for FTP, port 990 for when we enable TLS, and ports 40000-50000 for the range of passive ports we plan to set in the configuration file:

      • sudo ufw allow 20/tcp
      • sudo ufw allow 21/tcp
      • sudo ufw allow 990/tcp
      • sudo ufw allow 40000:50000/tcp

      Check the firewall status:

      Your firewall rules should now look like this:

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 990/tcp ALLOW Anywhere 20/tcp ALLOW Anywhere 21/tcp ALLOW Anywhere 40000:50000/tcp ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 20/tcp (v6) ALLOW Anywhere (v6) 21/tcp (v6) ALLOW Anywhere (v6) 990/tcp (v6) ALLOW Anywhere (v6) 40000:50000/tcp (v6) ALLOW Anywhere (v6)

      With vsftpd installed and the necessary ports open, let's move on to creating a dedicated FTP user.

      Step 3 — Preparing the User Directory

      We will create a dedicated FTP user, but you may already have a user in need of FTP access. We'll take care to preserve an existing user’s access to their data in the instructions that follow. Even so, we recommend that you start with a new user until you've configured and tested your setup.

      First, add a test user called sammy:

      Assign a password when prompted. Feel free to press ENTER through the other prompts.

      FTP is generally more secure when users are restricted to a specific directory. vsftpd accomplishes this with chroot jails. When chroot is enabled for local users, they are restricted to their home directory by default. However, because of the way vsftpd secures the directory, it must not be writable by the user. This is fine for a new user who should only connect via FTP, but an existing user may need to write to their home folder if they also have shell access.

      In this example, rather than removing write privileges from the home directory, let's create an ftp directory to serve as the chroot and a writable files directory to hold the actual files.

      Create the ftp folder:

      • sudo mkdir /home/sammy/ftp

      Set its ownership:

      • sudo chown nobody:nogroup /home/sammy/ftp

      Remove write permissions:

      • sudo chmod a-w /home/sammy/ftp

      Verify the permissions:

      • sudo ls -la /home/sammy/ftp

      Output

      total 8 4 dr-xr-xr-x 2 nobody nogroup 4096 Aug 24 21:29 . 4 drwxr-xr-x 3 sammy sammy 4096 Aug 24 21:29 ..

      Next, let's create the directory for file uploads and assign ownership to the user:

      • sudo mkdir /home/sammy/ftp/files
      • sudo chown sammy:sammy /home/sammy/ftp/files

      A permissions check on the ftp directory should return the following:

      • sudo ls -la /home/sammy/ftp

      Output

      total 12 dr-xr-xr-x 3 nobody nogroup 4096 Aug 26 14:01 . drwxr-xr-x 3 sammy sammy 4096 Aug 26 13:59 .. drwxr-xr-x 2 sammy sammy 4096 Aug 26 14:01 files

      Finally, let's add a test.txt file to use when we test:

      • echo "vsftpd test file" | sudo tee /home/sammy/ftp/files/test.txt

      Now that we've secured the ftp directory and allowed the user access to the files directory, let's modify our configuration.

      Step 4 — Configuring FTP Access

      We're planning to allow a single user with a local shell account to connect with FTP. The two key settings for this are already set in vsftpd.conf. Start by opening the config file to verify that the settings in your configuration match those below:

      • sudo nano /etc/vsftpd.conf

      /etc/vsftpd.conf

      . . .
      # Allow anonymous FTP? (Disabled by default).
      anonymous_enable=NO
      #
      # Uncomment this to allow local users to log in.
      local_enable=YES
      . . .
      

      Next, let's enable the user to upload files by ensuring that the write_enable setting is uncommented and set to YES:

      /etc/vsftpd.conf

      . . .
      write_enable=YES
      . . .
      

      We’ll also uncomment the chroot to prevent the FTP-connected user from accessing any files or commands outside the directory tree:

      /etc/vsftpd.conf

      . . .
      chroot_local_user=YES
      . . .
      

      Let's also add a user_sub_token to insert the username in our local_root directory path so our configuration will work for this user and any additional future users. Add these settings anywhere in the file:

      /etc/vsftpd.conf

      . . .
      user_sub_token=$USER
      local_root=/home/$USER/ftp
      

      Let's also limit the range of ports that can be used for passive FTP to make sure enough connections are available:

      /etc/vsftpd.conf

      . . .
      pasv_min_port=40000
      pasv_max_port=50000
      

      Note: In Step 2, we opened the ports that we set here for the passive port range. If you change the values, be sure to update your firewall settings.

      To allow FTP access on a case-by-case basis, let's set the configuration so that users only have access when they are explicitly added to a list, rather than by default:

      /etc/vsftpd.conf

      . . .
      userlist_enable=YES
      userlist_file=/etc/vsftpd.userlist
      userlist_deny=NO
      

      userlist_deny toggles the logic: When it is set to YES, users on the list are denied FTP access. When it is set to NO, only users on the list are allowed access.

      When you're done making the changes, save the file and exit the editor.

      Finally, let's add our user to /etc/vsftpd.userlist. Use the -a flag to append to the file:

      • echo "sammy" | sudo tee -a /etc/vsftpd.userlist

      Check that it was added as you expected:

      Output

      sammy

      Restart the daemon to load the configuration changes:

      • sudo systemctl restart vsftpd

      With the configuration in place, we can move on to testing FTP access.

      Step 5 — Testing FTP Access

      We've configured the server to allow only the user sammy to connect via FTP. Let's make sure that this works as expected.

      Anonymous users should fail to connect: We've disabled anonymous access. Let's test that by trying to connect anonymously. If our configuration is set up properly, anonymous users should be denied permission. Open another terminal and run the following command. Be sure to replace 203.0.113.0 with your server's public IP address, and use anonymous as your username:

      Output

      Connected to 203.0.113.0. 220 (vsFTPd 3.0.3) Name (203.0.113.0:default): anonymous 530 Permission denied. ftp: Login failed. ftp>

      Close the connection:

      Users other than sammy should fail to connect: Next, let's try connecting as our sudo user. They should also be denied access, and it should happen before they're allowed to enter their password:

      Output

      Connected to 203.0.113.0. 220 (vsFTPd 3.0.3) Name (203.0.113.0:default): your_sudo_user 530 Permission denied. ftp: Login failed. ftp>

      Close the connection:

      The user sammy should be able to connect, read, and write files: Let's make sure that our designated user can connect:

      Output

      Connected to 203.0.113.0. 220 (vsFTPd 3.0.3) Name (203.0.113.0:default): sammy 331 Please specify the password. Password: your_user's_password 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp>

      Let's change into the files directory and use the get command to transfer the test file we created earlier to our local machine:

      Output

      229 Entering Extended Passive Mode (|||47398|) 150 Opening BINARY mode data connection for test.txt (17 bytes). 100% |**********************************| 17 146.91 KiB/s 00:00 ETA 226 Transfer complete. 17 bytes received in 00:00 (0.17 KiB/s) ftp>

      Next, let's upload the file with a new name to test write permissions:

      Output

      229 Entering Extended Passive Mode (|||46598|) 150 Ok to send data. 100% |**********************************| 17 8.93 KiB/s 00:00 ETA 226 Transfer complete. 17 bytes sent in 00:00 (0.08 KiB/s)

      Close the connection:

      Now that we've tested our configuration, let's take steps to further secure our server.

      Step 6 — Securing Transactions

      Since FTP does not encrypt any data in transit, including user credentials, we'll enable TLS/SSL to provide that encryption. The first step is to create the SSL certificates for use with vsftpd.

      Let's use openssl to create a new certificate and use the -days flag to make it valid for one year. In the same command, we'll add a private 2048-bit RSA key. By setting both the -keyout and -out flags to the same value, the private key and the certificate will be located in the same file:

      • sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/private/vsftpd.pem -out /etc/ssl/private/vsftpd.pem

      You'll be prompted to provide address information for your certificate. Substitute your own information for the highlighted values below. For the Common Name field, be sure to add your_server_ip:

      Output

      Generating a 2048 bit RSA private key ............................................................................+++ ...........+++ writing new private key to '/etc/ssl/private/vsftpd.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:US State or Province Name (full name) [Some-State]:NY Locality Name (eg, city) []:New York City Organization Name (eg, company) [Internet Widgits Pty Ltd]:DigitalOcean Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []: your_server_ip Email Address []:

      For more detailed information about the certificate flags, see OpenSSL Essentials: Working with SSL Certificates, Private Keys and CSRs

      Once you've created the certificates, open the vsftpd configuration file again:

      • sudo nano /etc/vsftpd.conf

      Toward the bottom of the file, you will see two lines that begin with rsa_. Comment them out so they look like this:

      /etc/vsftpd.conf

      . . .
      # rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
      # rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
      . . .
      

      Below them, add the following lines that point to the certificate and private key we just created:

      /etc/vsftpd.conf

      . . .
      rsa_cert_file=/etc/ssl/private/vsftpd.pem
      rsa_private_key_file=/etc/ssl/private/vsftpd.pem
      . . .
      

      After that, we will force the use of SSL, which will prevent clients that can't deal with TLS from connecting. This is necessary to ensure that all traffic is encrypted, but it may force your FTP user to change clients. Change ssl_enable to YES:

      /etc/vsftpd.conf

      . . .
      ssl_enable=YES
      . . .
      

      After that, add the following lines to explicitly deny anonymous connections over SSL and to require SSL for both data transfer and logins:

      /etc/vsftpd.conf

      . . .
      allow_anon_ssl=NO
      force_local_data_ssl=YES
      force_local_logins_ssl=YES
      . . .
      

      After this, configure the server to use TLS, the preferred successor to SSL, by adding the following lines:

      /etc/vsftpd.conf

      . . .
      ssl_tlsv1=YES
      ssl_sslv2=NO
      ssl_sslv3=NO
      . . .
      

      Finally, we will add two more options. First, we will not require SSL reuse because it can break many FTP clients. We will require "high" encryption cipher suites, which currently means key lengths equal to or greater than 128 bits:

      /etc/vsftpd.conf

      . . .
      require_ssl_reuse=NO
      ssl_ciphers=HIGH
      . . .
      

      The finished file section should look like this:

      /etc/vsftpd.conf

      # This option specifies the location of the RSA certificate to use for SSL
      # encrypted connections.
      #rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
      #rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
      rsa_cert_file=/etc/ssl/private/vsftpd.pem
      rsa_private_key_file=/etc/ssl/private/vsftpd.pem
      ssl_enable=YES
      allow_anon_ssl=NO
      force_local_data_ssl=YES
      force_local_logins_ssl=YES
      ssl_tlsv1=YES
      ssl_sslv2=NO
      ssl_sslv3=NO
      require_ssl_reuse=NO
      ssl_ciphers=HIGH
      

      When you're done, save and close the file.

      Restart the server for the changes to take effect:

      • sudo systemctl restart vsftpd

      At this point, we will no longer be able to connect with an insecure command-line client. If we tried, we'd see something like:

      Output

      ftp -p 203.0.113.0 Connected to 203.0.113.0. 220 (vsFTPd 3.0.3) Name (203.0.113.0:default): sammy 530 Non-anonymous sessions must use encryption. ftp: Login failed. ftp>

      Next, let's verify that we can connect using a client that supports TLS.

      Step 7 — Testing TLS with FileZilla

      Most modern FTP clients can be configured to use TLS encryption. We will demonstrate how to connect with FileZilla because of its cross-platform support. Consult the documentation for other clients.

      When you first open FileZilla, find the Site Manager icon just above the word Host, the left-most icon on the top row. Click it:

      Site Manager Screent Shot

      A new window will open. Click the New Site button in the bottom right corner:

      New Site Button
      Under My Sites a new icon with the words New Site will appear. You can name it now or return later and use the Rename button.

      Fill out the Host field with your domain name or IP address. Under the Encryption drop down menu, select Require explicit FTP over TLS.

      For Logon Type, select Ask for password. Fill in your FTP user in the User field:

      General Settings Tab

      Click Connect at the bottom of the interface. You will be asked for the user's password:

      Password Dialogue

      Click OK to connect. You should now be connected with your server with TLS/SSL encryption.

      Upon success, you will be presented with a server certificate that looks like this:

      Site Certificate Dialogue

      When you’ve accepted the certificate, double-click the files folder and drag upload.txt to the left to confirm that you’re able to download files:

      Download test.txt

      When you’ve done that, right-click on the local copy, rename it to upload-tls.txt and drag it back to the server to confirm that you can upload files:

      Rename and Upload

      You’ve now confirmed that you can securely and successfully transfer files with SSL/TLS enabled.

      Step 8 — Disabling Shell Access (Optional)

      If you're unable to use TLS because of client requirements, you can gain some security by disabling the FTP user's ability to log in any other way. One relatively straightforward way to prevent it is by creating a custom shell. This will not provide any encryption, but it will limit the access of a compromised account to files accessible by FTP.

      First, open a file called ftponly in the bin directory:

      Add a message telling the user why they are unable to log in:

      /bin/ftponly

      #!/bin/sh
      echo "This account is limited to FTP access only."
      

      Save the file and exit your editor.

      Change the permissions to make the file executable:

      • sudo chmod a+x /bin/ftponly

      Open the list of valid shells:

      At the bottom add:

      /etc/shells

      . . .
      /bin/ftponly
      

      Update the user's shell with the following command:

      • sudo usermod sammy -s /bin/ftponly

      Now try logging into your server as sammy:

      You should see something like:

      Output

      This account is limited to FTP access only. Connection to 203.0.113.0 closed.

      This confirms that the user can no longer ssh to the server and is limited to FTP access only.

      Conclusion

      In this tutorial we covered setting up FTP for users with a local account. If you need to use an external authentication source, you might want to look into vsftpd's support of virtual users. This offers a rich set of options through the use of PAM, the Pluggable Authentication Modules, and is a good choice if you manage users in another system such as LDAP or Kerberos.



      Source link