Tutorial

Initial Server Setup with CentOS 7

Initial Server Setup with CentOS 7
Not using CentOS 7?Choose a different version or distribution.
CentOS 7

Introduction

When you first create a new server, there are a few configuration steps that you should take early on as part of the basic setup. This will increase the security and usability of your server and will give you a solid foundation for subsequent actions.

Step One — Root Login

To log into your server, you will need to know your server’s public IP address and the password for the “root” user’s account. If you have not already logged into your server, you may want to follow the first tutorial in this series, How to Connect to Your Droplet with SSH, which covers this process in detail.

If you are not already connected to your server, go ahead and log in as the root user using the following command (substitute the highlighted word with your server’s public IP address):

  1. ssh root@SERVER_IP_ADDRESS

Complete the login process by accepting the warning about host authenticity, if it appears, then providing your root authentication (password or private key). If it is your first time logging into the server, with a password, you will also be prompted to change the root password.

About Root

The root user is the administrative user in a Linux environment that has very broad privileges. Because of the heightened privileges of the root account, you are actually discouraged from using it on a regular basis. This is because part of the power inherent with the root account is the ability to make very destructive changes, even by accident.

The next step is to set up an alternative user account with a reduced scope of influence for day-to-day work. We’ll teach you how to gain increased privileges during the times when you need them.

Step Two — Create a New User

Once you are logged in as root, we’re prepared to add the new user account that we will use to log in from now on.

This example creates a new user called “demo”, but you should replace it with a user name that you like:

  1. adduser demo

Next, assign a password to the new user (again, substitute “demo” with the user that you just created):

  1. passwd demo

Enter a strong password, and repeat it again to verify it.

Step Three — Root Privileges

Now, we have a new user account with regular account privileges. However, we may sometimes need to do administrative tasks.

To avoid having to log out of our normal user and log back in as the root account, we can set up what is known as “super user” or root privileges for our normal account. This will allow our normal user to run commands with administrative privileges by putting the word sudo before each command.

To add these privileges to our new user, we need to add the new user to the “wheel” group. By default, on CentOS 7, users who belong to the “wheel” group are allowed to use the sudo command.

As root, run this command to add your new user to the wheel group (substitute the highlighted word with your new user):

  1. gpasswd -a demo wheel

Now your user can run commands with super user privileges! For more information about how this works, check out our sudoers tutorial.

The next step in securing your server is to set up public key authentication for your new user. Setting this up will increase the security of your server by requiring a private SSH key to log in.

Generate a Key Pair

If you do not already have an SSH key pair, which consists of a public and private key, you need to generate one. If you already have a key that you want to use, skip to the Copy the Public Key step.

To generate a new key pair, enter the following command at the terminal of your local machine:

  1. ssh-keygen

Assuming your local user is called “localuser”, you will see output that looks like the following:

ssh-keygen output
Generating public/private rsa key pair. Enter file in which to save the key (/Users/localuser/.ssh/id_rsa):

Hit return to accept this file name and path (or enter a new name).

Next, you will be prompted for a passphrase to secure the key with. You may either enter a passphrase or leave the passphrase blank.

Note: If you leave the passphrase blank, you will be able to use the private key for authentication without entering a passphrase. If you enter a passphrase, you will need both the private key and the passphrase to log in. Securing your keys with passphrases is more secure, but both methods have their uses and are more secure than basic password authentication.

This generates a private key, id_rsa, and a public key, id_rsa.pub, in the .ssh directory of the localuser’s home directory. Remember that the private key should not be shared with anyone who should not have access to your servers!

Copy the Public Key

After generating an SSH key pair, you will want to copy your public key to your new server. We will cover two easy ways to do this.

Note: The ssh-copy-id method will not work on DigitalOcean if an SSH key was selected during Droplet creation. This is because DigitalOcean disables password authentication if an SSH key is present, and the ssh-copy-id relies on password authentication to copy the key.

If you are using DigitalOcean and selected an SSH key during Droplet creation, use option 2 instead.

Option 1: Use ssh-copy-id

If your local machine has the ssh-copy-id script installed, you can use it to install your public key to any user that you have login credentials for.

Run the ssh-copy-id script by specifying the user and IP address of the server that you want to install the key on, like this:

  1. ssh-copy-id demo@SERVER_IP_ADDRESS

After providing your password at the prompt, your public key will be added to the remote user’s .ssh/authorized_keys file. The corresponding private key can now be used to log into the server.

Option 2: Manually Install the Key

Assuming you generated an SSH key pair using the previous step, use the following command at the terminal of your local machine to print your public key (id_rsa.pub):

  1. cat ~/.ssh/id_rsa.pub

This should print your public SSH key, which should look something like the following:

id_rsa.pub contents
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDBGTO0tsVejssuaYR5R3Y/i73SppJAhme1dH7W2c47d4gOqB4izP0+fRLfvbz/tnXFz4iOP/H6eCV05hqUhF+KYRxt9Y8tVMrpDZR2l75o6+xSbUOMu6xN+uVF0T9XzKcxmzTmnV7Na5up3QM3DoSRYX/EP3utr2+zAqpJIfKPLdA74w7g56oYWI9blpnpzxkEd3edVJOivUkpZ4JoenWManvIaSdMTJXMy3MtlQhva+j9CgguyVbUkdzK9KKEuah+pFZvaugtebsU+bllPTB0nlXGIJk98Ie9ZtxuY3nCKneB+KjKiXrAvXUPCI9mWkYS/1rggpFmu3HbXBnWSUdf localuser@machine.local

Select the public key, and copy it to your clipboard.

Add Public Key to New Remote User

To enable the use of SSH key to authenticate as the new remote user, you must add the public key to a special file in the user’s home directory.

On the server, as the root user, enter the following command to switch to the new user (substitute your own user name):

  1. su - demo

Now you will be in your new user’s home directory.

Create a new directory called .ssh and restrict its permissions with the following commands:

  1. mkdir .ssh
  2. chmod 700 .ssh

Now open a file in .ssh called authorized_keys with a text editor. We will use vi to edit the file:

  1. vi .ssh/authorized_keys

Enter insert mode, by pressing i, then enter your public key (which should be in your clipboard) by pasting it into the editor. Now hit ESC to leave insert mode.

Enter :x then ENTER to save and exit the file.

Now restrict the permissions of the authorized_keys file with this command:

  1. chmod 600 .ssh/authorized_keys

Type this command once to return to the root user:

  1. exit

Now you may SSH login as your new user, using the private key as authentication.

To read more about how key authentication works, read this tutorial: How To Configure SSH Key-Based Authentication on a Linux Server.

Step Five — Configure SSH Daemon

Now that we have our new account, we can secure our server a little bit by modifying its SSH daemon configuration (the program that allows us to log in remotely) to disallow remote SSH access to the root account.

Begin by opening the configuration file with your text editor as root:

  1. vi /etc/ssh/sshd_config

Here, we have the option to disable root login through SSH. This is generally a more secure setting since we can now access our server through our normal user account and escalate privileges when necessary.

To disable remote root logins, we need to find the line that looks like this:

/etc/ssh/sshd_config (before)
#PermitRootLogin yes

Hint: To search for this line, type /PermitRoot then hit ENTER. This should bring the cursor to the “P” character on that line.

Uncomment the line by deleting the “#” symbol (press Shift-x).

Now move the cursor to the “yes” by pressing c.

Now replace “yes” by pressing cw, then typing in “no”. Hit Escape when you are done editing. It should look like this:

/etc/ssh/sshd_config (after)
PermitRootLogin no

Disabling remote root login is highly recommended on every server!

Enter :x then ENTER to save and exit the file.

Reload SSH

Now that we have made our changes, we need to restart the SSH service so that it will use our new configuration.

Type this to restart SSH:

  1. systemctl reload sshd

Now, before we log out of the server, we should test our new configuration. We do not want to disconnect until we can confirm that new connections can be established successfully.

Open a new terminal window. In the new window, we need to begin a new connection to our server. This time, instead of using the root account, we want to use the new account that we created.

For the server that we configured above, connect using this command. Substitute your own information where it is appropriate:

  1. ssh demo@SERVER_IP_ADDRESS

Note: If you are using PuTTY to connect to your servers, be sure to update the session’s port number to match your server’s current configuration.

You will be prompted for the new user’s password that you configured. After that, you will be logged in as your new user.

Remember, if you need to run a command with root privileges, type “sudo” before it like this:

  1. sudo command_to_run

If all is well, you can exit your sessions by typing:

  1. exit

Where To Go From Here?

At this point, you have a solid foundation for your server. You can install any of the software you need on your server now.

If you are not sure what you want to do with your server, check out the next tutorial in this series for Additional Recommended Steps for New CentOS 7 Servers. It covers things like enabling fail2ban to reduce the effectiveness of brute force attacks, basic firewall settings, NTP, and swap files. It also provides links to tutorials that show you how to set up common web applications.

If you just want to explore, take a look at the rest of our community to find more tutorials. Some popular ideas are configuring a LAMP stack or a LEMP stack, which will allow you to host websites.

Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.

Learn more about our products


Tutorial Series: New CentOS 7 Server Checklist

When creating a new CentOS 7 server, there are some basic tasks that you should take to ensure that your server is secure and configured properly. This tutorial series will go over connecting to your server and general security best practices, and will also provide links to articles that will help you to start running your own web server or application.

About the authors

Still looking for an answer?

Ask a questionSearch for more help

Was this helpful?
 
46 Comments
Leave a comment...

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Love all of these topics

Can you add a step of configuration timezone for server? I guess it’s useful

Kamal Nasser
DigitalOcean Employee
DigitalOcean Employee badge
August 7, 2014

@grimavatar+digitalocean: You can change your server’s timezone by running the following command:

cp /usr/share/zoneinfo/Time/Zone /etc/localtime

Replace Time/Zone with your actual timezone, e.g. /usr/share/zoneinfo/Europe/London. You can list the available timezones by running:

ls -R /usr/share/zoneinfo

For someone layman like me, feel a specialist following your tutorial. It’s like picking at hand. Congratulations. I followed the tutorial in full. Everything went well until the last statement, but when I login (putty) using the user created, displays a message that server refused our key. What’s wrong?

Kamal Nasser
DigitalOcean Employee
DigitalOcean Employee badge
August 11, 2014

@contato: Have you added your public key to the user’s .ssh/authorized_keys file? Are there any errors?

sudo tail /var/log/secure

I’m having the same problems. I created the ssh key using PuTTy KeyGenerator. It works for the root account, but not for the user account. I manually copied and pasted the public key both from the PuTTy display and from a saved file. I also tried creating known_hosts, based off the root directory, but that didn’t matter so I deleted it. The results of

sudo tail /var/log/secure

were Sep 29 13:56:11 centos-7-x64 sudo: william : TTY=pts/1 ; PWD=/home/william ; USER=root ; COMMAND=/bin/tail /var/log/secure Sep 29 13:58:04 centos-7-x64 sudo: william : TTY=pts/1 ; PWD=/home/william/.ssh ; USER=root ; COMMAND=/bin/systemctl reload sshd Sep 29 13:58:04 centos-7-x64 sshd[10061]: Received SIGHUP; restarting. Sep 29 13:58:04 centos-7-x64 sshd[10061]: Server listening on 0.0.0.0 port 22. Sep 29 13:58:04 centos-7-x64 sshd[10061]: Server listening on :: port 22. Sep 29 13:58:11 centos-7-x64 sshd[16874]: pam_unix(sshd:session): session closed for user william Sep 29 13:58:31 centos-7-x64 sshd[16911]: Accepted password for william from 140.211.44.188 port 65505 ssh2 Sep 29 13:58:31 centos-7-x64 sshd[16911]: pam_unix(sshd:session): session opened for user william by (uid=0) Sep 29 13:58:56 centos-7-x64 sudo: william : TTY=pts/1 ; PWD=/home/william ; USER=root ; COMMAND=/bin/tail /var/log/secure Sep 29 13:59:03 centos-7-x64 sudo: william : TTY=pts/1 ; PWD=/home/william ; USER=root ; COMMAND=/bin/tail /var/log/secure

@contato maybe you have to adjust the rights of the .ssh and authorized_keys file.

chmod 700 /home/your_user/.ssh
chmod 600 /home/your_user/.ssh/authorized_keys

@arne.wiese That got me too. Thanks for the reminder.

Thank’s Kamal, but not solved for me

arne.wiese. No file in home/ user folder. Only hidden files \ .bash …

thanks very much for the tutorial.

hi haven’t tried it yet but where / when do you get the ip address? thanks can’t wait to start it.

Mitchell Anicas
DigitalOcean Employee
DigitalOcean Employee badge
September 2, 2014

The droplets page in the DigitalOcean Control Panel displays the public IP address next to your droplet name.

Please update this guide to include adding your SSH key to the new user, and setup the correct permissions on the directory and file.

Also, something should be added about un-commenting. I know this, but some people do not.

Also, the first command you should always run is yum update :)

I’ve followed the steps correctly but for some weird reason, I’m no longer being able to access the server via SSH using the new port.

As soon as I reset it back to 22 it works, if I change port, I try on 22 connection gets refused (which is normal) but then I input the new port, I get a timeout error.

I’m I missing something here ?

Mitchell Anicas
DigitalOcean Employee
DigitalOcean Employee badge
September 16, 2014

Check if your firewall is dropping the port that you are binding SSHD to. Here’s a tutorial on IPTables.

Hello, On Centos 7, You need to add a Firewall Rule to Open the new SSH Port using the firewall-cmd command, Like this:

sudo firewall-cmd --zone=public --add-port=4444/tcp --permanent

In this tutorial explain that

I doubt this would work since it’s a Centos 7. With RHEL 7 / CentOS 7, firewalld was introduced to manage iptables.

Actually, it was the work Firewall that wasn’t allowing SSH Access :)

Thanks

This instruction does not work if you have SELinux enabled. You need to tell SELinux of the new SSHD port:

# yum install policycoreutils-python
# semanage port -a -t ssh_port_t -p tcp 25000

I have tried editing the sshd_config now twice and each time I alter the port it messes it up, ie I cannot access via port 25000

Mitchell Anicas
DigitalOcean Employee
DigitalOcean Employee badge
September 24, 2014

Assuming it’s configured correctly, here are a few likely reasons it is failing:

  • Your server’s firewall could be dropping requests on port 25000
  • You are accessing your server through a firewall that is blocking port 25000
  • SELinux is enabled and is not allowing that port for SSH

I actually removed the port-change step from the tutorial because it is not necessary for most people. So feel free to just disable root login and leave it at that.

This is my first Centos, I have never had any issue changing the port on Ubuntu. And so it was a brand new build. So does Centos have a firewall running automatically. I am not going through a firewall. SELinux is disabled by default. So I am still a bit perplexed.

Nice article - helped very much. Have a good day!

I generated keys with puttygen, but is not working… my key starts like this ---- BEGIN SSH2 PUBLIC KEY ---- Comment: “rsa-key-20141113”

is this tutorial written for macs because windows does not have openSSH

Mitchell Anicas
DigitalOcean Employee
DigitalOcean Employee badge
November 14, 2014

Sorry that you are having issues. Yes, this tutorial was written for systems with OpenSSH installed.

For help with using puttygen, check out this tutorial.

Hey guys,

Having an issue when trying to install phpmyadmin. I’ve googled but can’t seem to find any help on this.

–> Finished Dependency Resolution Error: Package: php-tcpdf-6.0.098-1.el6.noarch (epel) Requires: php-tidy Error: Package: php-mcrypt-5.3.3-3.el6.x86_64 (epel) Requires: php(api) = 20090626 Installed: php-common-5.4.16-23.el7_0.3.x86_64 (@updates) php(api) = 20100412-64 Available: php-common-5.4.16-21.el7.x86_64 (base) php(api) = 20100412-64 Available: php-common-5.4.16-23.el7_0.x86_64 (updates) php(api) = 20100412-64 Available: php-common-5.4.16-23.el7_0.1.x86_64 (updates) php(api) = 20100412-64 Error: Package: php-mcrypt-5.3.3-3.el6.x86_64 (epel) Requires: php(zend-abi) = 20090626 Installed: php-common-5.4.16-23.el7_0.3.x86_64 (@updates) php(zend-abi) = 20100525-64 Available: php-common-5.4.16-21.el7.x86_64 (base) php(zend-abi) = 20100525-64 Available: php-common-5.4.16-23.el7_0.x86_64 (updates) php(zend-abi) = 20100525-64 Available: php-common-5.4.16-23.el7_0.1.x86_64 (updates) php(zend-abi) = 20100525-64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest

Any advice please?

I have successfully completed up until this step: Copy the Public Key Unfortunately I am unable to copy the key…my pointer will not select it. Perhaps related to the VirtualBox keyboard capture? How do I do this copy?

Mitchell Anicas
DigitalOcean Employee
DigitalOcean Employee badge
December 12, 2014

Have you installed the VirtualBox Guest Additions ?

This tutorial is missing firewall configuration: (other than that it’s great!) In CENTOS 7 as root user -

sudo firewall-cmd --permanent --remove-service=ssh firewall-cmd --permanent --add-port=4444/tcp firewall-cmd --reload where 4444 is your custom port for ssh

then

ssh -p 4444 demo@SERVER_IP_ADDRESS

will work

This is covered in the next chapter ;)

This comment has been deleted

    appears to me this error message when I change the ssh port:

    sshd.service - OpenSSH server daemon
       Loaded: loaded (/usr/lib/systemd/system/sshd.service; disabled)
       Active: activating (auto-restart) (Result: exit-code) since Ter 2015-01-27 09:25:12 EST; 3s ago
      Process: 16459 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=255)
      Process: 16457 ExecStartPre=/usr/sbin/sshd-keygen (code=exited, status=0/SUCCESS)
     Main PID: 16459 (code=exited, status=255)
    
    Jan 27 09:25:12 xxxx.com.br systemd[1]: sshd.service: main process exited, code=exited, status=255/n/a
    Jan 27 09:25:12 xxxx.com.br systemd[1]: Unit sshd.service entered failed state.
    
    

    Command ssh-copy-id is much easier than manually copying the key to the server. May be necessary to add it to the guide?

    It makes more sense to copy the ssh-key with the command ssh-copy-id -i ~/.ssh/id_rsa.pub demo@SERVER_IP_ADDRESS to the server. As a result, the necessary directories and files are created automatically and using the correct file permissions.

    Hi, when I get to the text edit inside the server, after creating the directory “.ssh” I try to use comand “nano” and get response: “-bash: nano: command not found”

    Mitchell Anicas
    DigitalOcean Employee
    DigitalOcean Employee badge
    March 4, 2015

    Hey, I updated the tutorial to use the vi editor instead (which you should have). Please try it again.

    Awesome, thanks! That worked, however - I am getting an error saying that I am not able to write anything to that file. I think I may have made a mistake earlier in the process - I’m getting Centos re-installed and trying again.

    Mitchell Anicas
    DigitalOcean Employee
    DigitalOcean Employee badge
    March 4, 2015

    If you’re talking about not being able to write to /etc/ssh/sshd_config, make sure that you are logged in as the root user (or use sudo vi /etc/ssh/sshd_config). A normal user without superuser privileges won’t have permission to edit that file.

    I was getting error when I was trying to save the public ssh keys to the .ssh/authorized_keys logged in as a user. I was able to open the text edit file and paste but after esc from insert and then :x to save - I would get an error that I wasn’t able to save an the edit.

    Mitchell Anicas
    DigitalOcean Employee
    DigitalOcean Employee badge
    March 4, 2015

    What was the error?

    I’m not sure. It had something to do with not having permission to edit the file, but I had Centos re-installed to start over & now when I try to ssh into the server I get this message:

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 00:00:0f:gf:0h:0r:00:0r:w0:0a:00:00:0r:00:00:hj. Please contact your system administrator. Add correct host key in /Users/Sample/.ssh/known_hosts to get rid of this message. Offending RSA key in /Users/Sample/.ssh/known_hosts:1 RSA host key for 000.000.000.00 has changed and you have requested strict checking.

    *Obviously changed all sensitive information.

    Mitchell Anicas
    DigitalOcean Employee
    DigitalOcean Employee badge
    March 5, 2015

    You’re getting that message because you destroyed a droplet, and created a new one that ended up with the same IP address. Each server gets a unique host ID, and your computer keeps a record of which host IDs are associated with particular IP addresses.

    To remove the original host ID, enter this command on your local computer:

    ssh-keygen -R SERVER_IP_ADDRESS
    

    The new user cannot access SFTP. If I want to use SFTP, should I add my user with:

    visudo

    and add demo user here:

    Allow root to run any commands anywhere

    root ALL=(ALL) ALL demo ALL=(ALL) ALL

    My box tells me the group “wheel” does not exist… actually no /etc/group folder exists.

    I have the same problem.

    Mitchell Anicas
    DigitalOcean Employee
    DigitalOcean Employee badge
    May 8, 2015

    Which distro are you using?

    /etc/group is a file.

    This comment has been deleted

      When I follow step 3 to add the user to the wheel group, using exactly the command given (with the name of the user I created), I get:

      gpasswd: group 'wheel' does not exist in /etc/group
      

      Nevermind I figured out the problem!

      There’s a missing step in Step Five — Configure SSH Daemon, the line with:

      PasswordAuthentication yes

      should be changed to

      PasswordAuthentication no

      Thank you for your time in this tut, I know a lot of time and effort goes into writing these tuts.

      First off there is plenty missing from this tutorial and it is NOT straight forward. I know it is tough writing technical docs since you do believe that everyone will understand what you are trying to communicate but the speed bump is hit with the SSH keygen section. There is no communication that you have to change from root to your newly created user first to save the ssh keys in, second when copying the SSH keygen it the server just hangs and does not respond. When I try to follow the tut I get an error telling me that the directories cannot be found. When I do it the manual way I cannot login in with the user that was created with the keygen that was created and copied to the directory that was set with the proper permissions. Third you speak of additional ports but you fail to describe what the end user needs to do to set those ports.

      Even though I replaced all the demo words with my new user syntax I get the below error when copying:

      ssh-copy-id demo@SERVER_ADDRESS /bin/ssh-copy-id: ERROR: No identities found

      Again I know it is time consuming to make these tuts but it is also time consuming when things don’t work out according to these tuts. I hope you understand what I am saying. Plus we should NOT have to refer to other articles when we are just learning how to setup an initial server. All the information should be in one article - STEP by STEP.

      Have a good day.

      I had no issue following this guide. I’m a Linux beginner with a Windows background.

      To whom it may concern: on CentOS 7 droplet, although having key in ~/.ssh/authorized_keys and changed port number in /etc/ssh/sshd_config, Putty connection still refused. It’s likely because of firewall’s default settings. Please try following:

      sudo firewall-cmd --permanent --remove-service=ssh sudo firewall-cmd --permanent --add-port=<port-number>/tcp

      This comment has been deleted

        https://www.digitalocean.com/community/tutorials/initial-server-setup-with-centos-7

        I updated

        Followed instructions but it didn’t work I found this extra detail for the strict mode if you have SELinux enabled (default) (from CentOS7 doc itself https://wiki.centos.org/HowTos/Network/SecuringSSH#head-9c5717fe7f9bb26332c9d67571200f8c1e4324bc) You must be logged locally with the desired user (su will do)

        restorecon -Rv ~/.ssh

        now it works

        Note that you can disable password for ALL users

        Disable password authentication forcing use of keys

        PasswordAuthentication no

        In the “Where To Go From Here?” section of this article, it links to another article and says that instructions for setting up fail2ban is in that linked article, but it is not.

        I have a problem with CentOs, when i uncomment this line : PermitRootLogin no, and reload then i can’t login with public key, but in Ubuntu is good.

        To solve the problem in CentOS, i commented #PermitRootLogin no, and change the PubkeyAuthentication yes to PubkeyAuthentication no, change PasswordAuthentication yes to PasswordAuthentication no, and reload sshd.

        Absolutely beautiful - great tutorial!

        This comment has been deleted

          It seems that the DO build process now disables login via password by default. This breaks the current steps for adding a new user’s key.

          Any ideas for a work-around that doesn’t involve manually overriding that setting and then re-enabling it? This breaks my deploy scripts, and editing config files via bash scripts gets really messy, so I’d like to avoid that if possible.

          The first thing that comes to mind is using the Console to access your droplet for the first steps.

          Are you sure the build process changed as I deployed a new Droplet maybe a week or so ago and it seemed to work fine using the usual process? If it changed it must have been super recently as in within the last week or so. I’d be surprised that there wouldn’t be an announcement. I’m tempted to deploy a new droplet just to see if the defaults are different.

          Though I deploy manually as this is for personal projects so it could be that your default build process is different than mine.

          I deploy manually via the website normally (create new droplet, pick OS and location, add SSH key, deploy). Once that is done, I have scripts that do a default setup for me - update the system and install some tools, add a non-root user, install apps if I want, etc.

          The issue is that with CentOS password login is disabled by default. This causes no problems with root, as I login via SSH key that DO places automatically for you. But when you add a new user, per this very guide, you cannot login via that user because password logins are disabled by default. So without editing that config file (which is totally possible, just messy to do via bash scripts), you can’t even complete the steps in this guide. And this guide makes no mention of that config file.

          I don’t care so much that the guide is missing that info, I’m savvy enouh with Linux to figure it out. My main question is if I can either change or avoid this default behavior so I don’t have to change the default configs just to create a user. I guess to be more specific, can I add a new user key without first logging in as that user, or using su (which doesn’t work well in scripts).

          One thing I’ve done is added ssh keys to my DO account that seem to be globally accessible to droplets. Do you ever do that? I know I’m suggesting workarounds and not getting at the root problem but that’s all I’ve got.

          You seem to be asking if there’s a way you could change defaults to what they were before this change happened so like a global configuration setting option?

          Did you try contacting DO to see if they have any suggestions?

          I do add my keys and that works fine for root. But I only use root for my inital login and server deploy, as soon as the very basics are setup and a new user is a added, I disable root login.

          And I did submit a support ticket in parallel with my original comment. They suggested using their cloud-config process, which seems like it would work (at the expense of either re-doing my current deploy scripts in that format, or using a hybrid setup with both). That’s workable, but my deploy scripts are essentially universal right now, and adding or converting to cloud-config would compromise that aspect (I use DO for almost everything, but don’t want to be left dependent on them either, I can use my current scripts with Linode or any other host).

          The other suggestion they had was to use /etc/skel and add .ssh/authorized_keys - this is a better solution for me if it works. It retains my original scripts and their compatibility. The downside is that the etc/skel gets applied to every new user, which in my current use-case is fine, but definitely limits the application of this method overall (generally not a great idea to load users up with a “default” key that will allow access to all of them).

          Anyway, I appreciate the discussion on this. I’m surprised no one else has run into this yet as an issue.

          I set up a droplet with CentOS on it. I set up SSH keys and logged in via PuTTY (Win10). I created a secondary user, set “PermitRootLogin no” (uncommenting it) and all went well, until the sentence:

          “Now, before we log out of the server, we should test our new configuration. We do not want to disconnect until we can confirm that new connections can be established successfully. Open a new terminal window.…”

          Disaster: as it was not at all obvious how to open a new window (how you do that?), I started a new PuTTY session to log in as the secondary user, and got “network error, connection refused.” I tried commenting out “PermitRootLogin no” and now I can’t log in (via SSH+PuTTY) even as root…

          I’m afraid the /etc/ssh/sshd_config file is all screwed up now. I am trying to fix this logging into the droplet console, but I’m stuck. Any suggestion will be welcome. Thanks.

          Don’t worry at all as DO has a console that’s equivalent to plugging directly into the server.

          This doc has console instructions.

          You access the console through your Droplet’s page in the DigitalOcean control panel. I’ve had to use this a few times so it’s a nice feature to have.

          I’m surprised this tutorial doesn’t include a recommendation of running yum update !

          That’s a good point, and I think you upgrade, too, right?

          I wonder if there are a set of tasks that are a good idea once a day should run in a cronjob or something. Not right now but I might kind of look around for a list of best practices, if there are best practices for when and how often these things should be run.

          Hi guys, I have this problem in step four:

          ssh-copy-id user@Server_IP
          /usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/Users/Laptop_User/.ssh/id_rsa.pub"
          /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
          /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
          Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
          

          Thanks for the help, Best Regards.

          There is beautiful repository in Ansible for initial server setup. https://github.com/Adsizzlerlabs/initial-server-setup-centos-7

          Overly detailed (even the steps inside vi/vim?) steps made the Article quite annoying/confusing unnecessarily.

          I am setting up the server for the first time. Trying to login as root first and Putty gives this error: Disconnected: No supported authentication methods available. Server sent: publickey,gssapi-with-mic,password

          CentOS 7.3.

          Any chance the system can be improved/fixed?

          If anyone has the same issue I had a very hard time with this:

          SSH and Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

          Solved it by amending the /etc/ssh/sshd_config --> ‘PasswordAuthentication yes’ --> then re-started the service ‘sudo systemctl restart sshd’

          Hope this helps.

          Excellent tutorial and thank you for your time in creating this but shouldn’t a recommendation to install firewalld be listed here. I just checked the Additional Recommended Steps for New CentOS 7 Servers and when I went to run the following:

          systemctl start firewalld

          I received the following:

          Failed to start firewalld.service: Unit not found.

          Figuring that firewalld was already installed with the Centos image.

          But it does not state in either tutorial’s how to install it. Very simple:

          yum install firewalld

          Plus everyone that rolls out a Centos 7 image / droplet should use the update option in yum to update / upgrade all of your CentOS system software to the latest version with one operation.

          To perform a full system update, type this command:

          yum update

          If asked for a password enter the root password.

          You could also add the following lines to a cron job. To create a cron job do the following:

          crontab -e

          Type the a key on your keyboard.

          Paste the following lines

          #Automatic updates via yum 0 1 * * * /usr/bin/yum -y update >> /dev/null 2>&1 30 23 * * * /usr/bin/yum clean all >> /dev/null 2>&1

          Press the ESC key then :wq! then ENTER to save and exit the file.

          This will keep your system updated on a regular and automatic basis.

          Regards, Robert

          Since sudo is not pre-installed with CentOS 7, you should add the line yum install sudo, so that sudo command_to_run actually works! ;)

          The primary reason we do Step 4, is to ensure that the new user (eg. demo) is also using SSH public key authentication method, without resorting to using passwords again.

          However, the moment the new user (eg. demo) uses sudo for executing commands, the console prompts for password. Since there was no password created, and since the root login disabled in the subsequent Step 5, how would the new user ever use sudo, without a password?

          Good afternoon,

          During installation, the following error occurs:

          /opt/dropbox/dropbox-lnx.x86_64-159.4.5870/dropbox: /lib64/libc.so.6: version `GLIBC_2.18’ not found (required by /opt/dropbox/dropbox-lnx.x86_64-159.4.5870/libdropbox_core.so)

          Please if anyone can help me.

          Thanks.

          Try DigitalOcean for free

          Click below to sign up and get $200 of credit to try our products over 60 days!

          Sign up

          Join the Tech Talk
          Success! Thank you! Please check your email for further details.

          Please complete your information!

          Become a contributor for community

          Get paid to write technical tutorials and select a tech-focused charity to receive a matching donation.

          DigitalOcean Documentation

          Full documentation for every DigitalOcean product.

          Resources for startups and SMBs

          The Wave has everything you need to know about building a business, from raising funding to marketing your product.

          Get our newsletter

          Stay up to date by signing up for DigitalOcean’s Infrastructure as a Newsletter.

          New accounts only. By submitting your email you agree to our Privacy Policy

          The developer cloud

          Scale up as you grow — whether you're running one virtual machine or ten thousand.

          Get started for free

          Sign up and get $200 in credit for your first 60 days with DigitalOcean.*

          *This promotional offer applies to new accounts only.