Users Archives - XpresServers Hosting

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

Updated Thursday, January 16, 2020 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.

Click the Linodes link in the sidebar menu and select the Linode whose disks you’d like to see.
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.

Reboot Your Linode

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

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

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.
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.

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.

Click Linodes from the sidebar menu.
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.
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.
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.

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.

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.

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.

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:

Click on the Account link from the sidebar menu.
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.

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.

Navigate to your Account by clicking on Account in the sidebar.
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.
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.

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:

Navigate to the Account page in the sidebar links menu, then click on the Settings tab.
Expand the panel labeled Import Display Groups as Tags and then click Import Display Groups:
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.

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.
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.
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.

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.

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
 hassan latif
 
 3 Comments
blog
      
	

		
		
			 



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:
OutputStatus: 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:
OutputStatus: 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

Outputtotal 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

Outputtotal 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:

Outputsammy

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:

OutputConnected 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:

OutputConnected 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:

OutputConnected 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:

Output229 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:

Output229 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:
OutputGenerating 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:

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

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:

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

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:

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:

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:

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:
OutputThis 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 
		

	
	
	
1
2
Next Page »


                            
                    


		
			
				
				
				
			
			
		
				Recent Posts
		
											
					Using Octant with Kubernetes – A Tutorial
									
											
					How to Install Apps on Kubernetes with Helm 3
									
											
					Structs in Go – A Tutorial
									
											
					An Overview of Linode's Cloud Manager for Classic Manager Users
									
											
					What Are the Cloud Manager Events and Activity Feeds
									
					
		
Recent Comments
Archives
		
			January 2020
	December 2019
	November 2019
	October 2019
	September 2019
	August 2019
	July 2019
	June 2019
	May 2019
	April 2019
	March 2019
	February 2019
	January 2019
	December 2018
	November 2018
	October 2018
	September 2018
	July 2016
		
		
Categories
		
	blog

	client

		
Meta
			
						Log in
			Entries RSS
			Comments RSS
			WordPress.org

Shared

Cloud VPS

Dedicated

Users

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

In this Guide

Linodes

Find Your Disks

Reboot Your Linode

Delete a Public IP Address

Volumes

Find Volumes

Object Storage

NodeBalancers

Domains (DNS Manager)

Zone Files

Longview

One-Click Apps

Kubernetes

StackScripts

Find StackScripts

Images

Find Images

Account (Management and Billing)

Find Credit Remaining

Printing an Invoice

Import Display Groups

Password Management

My Profile

API Keys / API Tokens

Manage Email Event Notifications

User Interface Enhancements

Compact Mode and Dark Mode

Accessibility

Next Steps

How to Add and Delete Users on Ubuntu 18.04

Introduction

Prerequisites

Adding a User

Granting a User Sudo Privileges

Adding the New User to the Sudo Group

Specifying Explicit User Privileges in /etc/sudoers

Testing Your User’s Sudo Privileges

Deleting a User

Conclusion

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

Introduction

Prerequisites

Step 1 — Installing vsftpd

Step 2 — Opening the Firewall

Step 3 — Preparing the User Directory

Step 4 — Configuring FTP Access

Step 5 — Testing FTP Access

Step 6 — Securing Transactions

Step 7 — Testing TLS with FileZilla

Step 8 — Disabling Shell Access (Optional)

Conclusion