Fedora 10 - Setup

This article will take you from a 'barebones' Fedora 10 Cloud Server to a secured and up to date Cloud Server ready for your software (or whatever you use the Cloud Server for).

Not only that, you will have a better understanding of what is going on and, more importantly, why it's going on.



Log in

On your LOCAL computer, edit the SSH known_hosts file and remove any entries that point to your Server IP address. If this is a brand new Server then you will not need to do this, but a reinstall will result in a different signature.

    nano ~/.ssh/known_hosts

If you are not using Linux or a Mac on your LOCAL computer, the location of the known_hosts file will differ. Please refer to your own OS for details of where this file is kept.

As soon as you have your IP address and password for your VPS login via SSH:

    ssh root@

User administration

Now we're logged in to the VPS, immediately change your root password


Add an admin user (I've used the name demo here but any name will do).

    adduser demo

You will need to specifically set the password for your new user:

    passwd demo

As you know we never log in as the root user (this initial setup is the only time you would need to log in as root). As such, the main administration user (demo) needs to have sudo (Super User) privileges so he can, with a password, complete administrative tasks.

To do this, we're going to add the main user to the 'wheel' group. Once that is done, we need to edit the 'sudoers' file, using visudo, and ensure the 'wheel' group has the correct privileges.

So firstly, add the user to the wheel group:

    usermod -a -G wheel demo

Next, give the 'visudo' command:


Near the bottom of the file you will see this line:

    ## Allows people in group wheel to run all commands
    # %wheel  ALL=(ALL)       ALL

Simply uncomment (remove the '#') so it looks like this:

    ## Allows people in group wheel to run all commands
    %wheel  ALL=(ALL)       ALL

Now members of the 'wheel' group have full sudo privileges.

SSH keygen

One effective way of securing SSH access to your server is to use a public/private key. This means that a 'public' key is placed on the server and the 'private' key is on our local workstation. This makes it impossible for someone to log in using just a password - they must have the private key.

The first step is to create a folder to hold your keys. On your LOCAL workstation:

    mkdir ~/.ssh

That's assuming you use Linux or a Mac and the folder does not exist. I will do a separate article for key generation using Putty for Windows users.

To create the ssh keys, on your LOCAL workstation enter:

    ssh-keygen -t rsa

If you do not want a passphrase then just press enter when prompted.

That created two files in the .ssh directory: id_rsa and id_rsa.pub. The pub file holds the public key. This is the file that is placed on the Server.

The other file is your private key. Never show, give away or keep this file on a public computer.

SSH copy

Now we need to get the public key file onto the Server.

We'll use the 'scp' command for this as it is an easy and secure means of transferring files.

Still on your LOCAL workstation enter this command:

    scp ~/.ssh/id_rsa.pub demo@

When prompted, enter the demo user password.

Change the IP address to your server and the location to your admin user's home directory (remember the admin user in this example is called demo).

SSH Permissions

OK, so now we've created the public/private keys and we've copied the public key onto the Server.

Now we need to sort out a few permissions for the ssh key.

On your Server, create a directory called .ssh in your home folder and move the pub key into it.

    mkdir /home/demo/.ssh
    mv /home/demo/id_rsa.pub /home/demo/.ssh/authorized_keys

Now we can set the correct permissions on the key:

    chown -R demo:demo /home/demo/.ssh
    chmod 700 /home/demo/.ssh
    chmod 600 /home/demo/.ssh/authorized_keys

Again, change the 'demo' user and group to your admin user and group.

Done. It may seem a long set of steps but once you have done it once you can see the order of things: create the key on your local workstation, copy the public key to the Cloud Server and set the correct permissions for the key.

SSH config

Next we'll change the default SSH configuration to make it more secure:

nano /etc/ssh/sshd_config

The main things to change (or check) are:

    Port 30000                           <--- change to a port of your choosing
    Protocol 2
    PermitRootLogin no
    PasswordAuthentication no
    UseDNS no
    AllowUsers demo

The settings are fairly self explanatory but the main thing is to move the server from the default port of 22 to one of your choosing, turn off root logins and define which users can log in.

PasswordAuthentication has been turned off as we setup the public/private key earlier. Do note that if you intend to access your server from different computers you may want leave PasswordAuthentication set to yes. Only use the private key if the local computer is secure,


Right, now we have the basics of logging in and securing SSH done. Our Fedora 10 install comes with iptables already installed, so let's have a look at the default rules:

iptables -L

This will output something similar to this:

    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
    ACCEPT     icmp --  anywhere             anywhere            
    ACCEPT     all  --  anywhere             anywhere            
    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh 
    REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         
    REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited 
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         

Since we're not using port 22 for SSH, and we'd like to have other ports open (like HTTP and HTTPS), let's flush these rules and set up our own. Flush the current iptables rules by executing the following command:

iptables -F

We'll input several command that allow local connections and keep established connections (which is how the root SSH connection on port 22 will still work when we apply the SSH port changes and apply the new iptables rules).

We'll also open port 80 and port 443 (the normal HTTP and HTTPS ports) and, of course, allow connections to our custom SSH port (3000).

Then we'll allow pings to the Cloud Server and, effectively, reject all other attempts to connect to a port.

So, on the command line, enter these:

    iptables -A INPUT -i lo -j ACCEPT
    iptables -A INPUT -i ! lo -d -j REJECT
    iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
    iptables -A OUTPUT -j ACCEPT
    iptables -A INPUT -p tcp --dport 80 -j ACCEPT
    iptables -A INPUT -p tcp --dport 443 -j ACCEPT
    iptables -A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT
    iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
    iptables -A INPUT -j REJECT
    iptables -A FORWARD -j REJECT

If you are new to iptables then that may seem a little intimidating but, as I recommend with most things, take it one step at a time.

Have a look at each line and see what it does. I actually think they are all pretty self explanatory but don't be afraid to do some research if you are not sure.

Anyway, let's have a look at what rules are in place now:

    iptables -L
    Chain INPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     all  --  anywhere             anywhere            
    REJECT     all  --  anywhere             loopback/8          reject-with icmp-port-unreachable 
    ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:http 
    ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https 
    ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:30000 
    ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 
    REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 
    Chain FORWARD (policy ACCEPT)
    target     prot opt source               destination         
    REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 
    Chain OUTPUT (policy ACCEPT)
    target     prot opt source               destination         
    ACCEPT     all  --  anywhere             anywhere            

See the difference between the first time we entered that command and now? Again, have a look at each line of the output and see where it matches up with the rules we entered earlier.

If you are unhappy or have made a mistake you can flush the rules and start again with a:

    iptables -F


Although the rules are up and running, they are only active for the current session. If the Cloud Server was rebooted they would be lost.

As such, let's ensure they are restarted on a Server reboot:

    service iptables save

The output confirms the rules were added to the correct file:

    Saving firewall rules to /etc/sysconfig/iptables:          [  OK  ]

Feel free to have a look at that file and familiarize yourself with the syntax.

Logging in with the new user

Now we have our basic firewall humming along and we've set the ssh configuration. Now we need to test it. Reload ssh so it uses the new ports and configurations:

    /etc/init.d/sshd reload

Don't logout as root yet...

On your LOCAL computer, open a new terminal and log in using the administration user (in this case, demo) to the port number you configured in the sshd_config file:

    ssh -p 30000 demo@

The reason we use a new terminal is that if you can't login you will still have the working connection to try and fix any errors.

You can also log in via a console in the Cloud Services Control Panel if something goes awry.

You will be greeted with a plain terminal prompt like this:

    [demo@yourvpsname ~]$


We now know that the firewall and ssh_config works and we can log in.

Let's move on and install some personal configuration files to make our life easier. Once done, we can update the install and create a solid base for the 'meat' of the server.

OS check and Free

First thing is to confirm what OS we're using. We know we should be using FEdora 10 but let's see:

    cat /etc/redhat-release

You should get an output similar to this:

    Fedora release 10 (Cambridge)

Good. Memory usage should be very low at this point but let's check using 'free -m' (the -m suffix displays the result in MB's which I find easier to read):

    free -m

It's nice to know what is going on so let's look at that output:

    .                  total       used       free     shared    buffers     cached
    Mem:           254        55          199          0           2               21
    -/+ buffers/cache:      30          223
    Swap:            511        0           511

The line to take notice of is the second one as the first line includes cached memory - in this demo server I have 254MB memory in total with 30MB actually used, 223MB free and no swap used. Nice.


Let's make the terminal a bit more attractive and a bit more informative by adding a few lines to our .bash_profile file.

    nano ~/.bash_profile

Add the next few lines at the end of the existing text. The following line will make the terminal display the server name in colour and display the working directory (the directory we are in) in a different colour:

    export PS1='\[\033[0;35m\]\h\[\033[0;33m\] \w\[\033[00m\]: '

Now we can add aliases to the file. Aliases are short cuts to commands or sequences of commands. I've included a few below but you can have as many or as few as you want.

    alias free="free -m"
    alias update="sudo yum update"
    alias install="sudo yum install"
    alias upgrade="sudo yum upgrade"
    alias remove="sudo yum remove"

The examples above are pretty simple. Instead of typing 'free -m' every time I want to look at the memory usage, I just type 'free. Typing 'sudo yum install' can get tedious, so I just type 'install'.

I still need to provide my password for the sudo command to work, but it is more productive/quicker/easier to have short cuts.

To activate the changes enter this command:

source .bash_profile

You should now see the server name in purple and the working directory in brown.

To change the colours to your choosing, adjust the 0;35m and the 0;33m values in the 'export PS1' line of your .bash_profile.

For example:

    export PS1='\[\033[0;32m\]\h\[\033[0;36m\] \w\[\033[00m\]: '

...would give you a green and blue output.

Yum repositories

The CentOS Server comes with a basic set of repositories that are defined in /etc/yum.repos.d.

Have a look at the enabled repositories:

    ls /etc/yum.repos.d/

This will list the repository files that Fedora uses. Take a look at the fedora.repo and fedora-updates.repo files:

sudo nano /etc/yum.repos.d/fedora.repo
    sudo nano /etc/yum.repos.d/fedora-updates.repo

As you scroll through the file, you will see each repository has a set of definitions including which mirror to use and what gpg key to use (and actually whether to check the package signature at all).

You can, of course, add more repositories whenever you want to but I would just give a word of caution: Some of the available repositories are not officially supported and may not receive any security updates should a flaw be discovered.

Keep in mind it is a server we are building and not a desktop.


Now we can update the package list that yum uses.

The command will also offer to install any updated packages. As with all installs have a careful look at the list and, once happy, press 'y' to continue:

    sudo yum update

NOTE: If you have used the .bash_profile aliases shown above you just need to enter 'update' as the alias will use the entire command. I've put the whole thing here so you know what is happening.

That's really the basics done for the Server.

Once any updates have been installed, we can move on to installing some essential packages.

Development Tools

Fedora has some handy meta-packages that include a set of pre-defined programs needed for a single purpose.

So instead of installing a dozen different package names, you can install just one meta-package. One such package is called 'Development Tools'. Issue the command:

    sudo yum groupinstall 'Development Tools'

Notice the programs that are to be installed include gcc, make, patch and so on. All these are needed for many other programs to install properly. A neat system indeed.

Enter 'Y' and install them.

Now we have the necessary packages should we want to build an application from source.

We'll go on and install a very useful package that I recommend called 'screen'.


This is a great application that allows 'virtual' terminals to be opened in one console. Switching between them is done with the press of a key.

The advantages are that you can be working on more than one shell at a time, say one installing software and another monitoring network activity - all without having more than one physical shell open. If the SSH connection is cut for some reason or you have to leave the room then close the terminal and the work will still carry on in the background.

I recommend getting used to using screen. This screen tutorial gives an excellent introduction.

sudo yum install screen

To start a screen session simply enter the command:


Not much appears to have changed, but you can open another virtual terminal with a:

    Ctl-A and then press 'c'

Enter a simple command such as:

    ls -al

then nip back to the other virtual terminal with:

    Ctl-A and then press 'p'

You can have several processes running at the same time using this technique.

One thing to note, is that the bash aliases we setup previously in this article, will not work in Screen.


Quite a lot happening here but now we have a more secured Server with updated packages ready for the meat to be installed.

Table of Contents

© 2015 Rackspace US, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License

See license specifics and DISCLAIMER