Getting Started with openSUSE in the Cloud


Preface

OpenSUSE is a rock solid collaborative Linux distribution that is based on Enterprise SUSE Linux.  Being that openSUSE is new to the Rackspace Cloud, I made the decision that I would begin using openSUSE as a server. Now this decision was based on curiosity as well as memories. A long, time ago, I used openSUSE for a desktop as well as a server. While this was back in the days of SUSE 9 and a whole lot has changed since then, I was curious how openSUSE would hold up to my beloved Debian Linux. While the principals are the same, there are some major differences between the distributions.  My main goal was to be able to spin up a production ready openSUSE environment, but what I found was a world of difference that I really like.  In short, openSUSE 12.1 is a force to be reckoned with, and the openSUSE team should be commended for all of their work.

Beginning Instance

Here is how I deployed my first openSUSE 12.1 Server:

  • Rackspace Cloud Server
  • Image 109 – openSUSE 12.1
  • Flavor 2 – 512MB

How to Create a User

After the brief waiting period while the server was being configured, I was ready to begin my journey back into the world of SUSE Linux.

useradd –m (USER NAME)

How to create Groups

Now that I have a user that I can use to login to the server, other than root, I create a group for use with sudo and ssh.

groupadd sudoer
groupadd sshuser

I then add the user to the groups that I have created.

usermod -a -G sudoer (USER NAME)
usermod -a -G sshuser (USER NAME)

Setting Up SSH On your Server

Once I completed these actions I modify the SSH configuration file at /etc/ssh/sshd_config. Here is the complete ssh configuration file that I have setup. Make sure you change the (PORT NUMBER) to a port number that you would like to use.

Port (PORT NUMBER)
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
KeyRegenerationInterval 1h
ServerKeyBits 1024
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120m
PermitRootLogin no
StrictModes yes
MaxAuthTries 6
MaxSessions 10
RSAAuthentication yes
PubkeyAuthentication yes
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts no
IgnoreRhosts yes
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding no
UsePrivilegeSeparation yes
ClientAliveCountMax 3
UseDNS no
PidFile /var/run/sshd.pid
MaxStartups 10
Subsystem    sftp    /usr/lib/ssh/sftp-server
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
AllowGroups sshuser

As you can see I have made it so that the only people that are allowed to SSH to the server are people that are part of the sshuser group and have a valid SSH public key. Additionally, I have made it so that the ROOT user is not allowed to SSH to the server.

Setting Up your SSH Key

As a reminder you will need to generate the SSH user key, to do this use this command:

ssh-keygen

I recommend that you run this command on both your Local computer as well as your server. I make this recommendation only because it will generate the necessary files needed to ensure that you have the .ssh directory as well as the correct permissions on the directory.

The command will also generate the necessary key on most UNIX / Linux Systems. Once you have the key generated you will need to upload the key file to your home directory on the server. This can be done in a number of ways, I use SCP, but Google is your friend, there are a million ways to upload the file to your server.

This is how I did the upload from my local system :

scp -P(PORT NUMBER) ~/.ssh/id_rsa.pub (USERNAME)@(IP ADDRESS):/home/(USERNAME)/.ssh/id_rsa.pub

Please Remember this is simply a snippet. As such you must remember to change the port Number to the Port you set in you SSH Configuration, also change the Username and IP address so match you IP address as well as your Username that you setup.

After you have uploaded your key make sure that you have copied the contents of the key file to the authorized_keys file. This can be done with a simple file output redirect, though there are many ways to achieve this, again Google is your friend. This is how I do the redirect :

cat /home/(USER NAME)/.ssh/id_rsa.pub > /home/(USER NAME)/.ssh/authorized_keys

Setting Up your Initial Firewall

Before you restart any services and or sign out of the server make sure you have setup the SSH access through the firewall. The easiest way to make sure that you have your firewall setup correctly is with the command:

yast firewall

This will bring up the blue screen configuration tool, which can guide you through ensuring the firewall is setup correctly. From within the configuration console go to:

Interfaces >> Eth0Select External
Interfaces >> Eth1Select Internal

These settings specify that you will have an internal interface as well as an external interface, which will allow different services to pass through the firewall.

Once the zones have been selected correctly, go to:

Allowed Services >> External Zone >> Secure Shell Server >> Add >> Advanced

In the advanced tab change the “TCP Ports” to the SSH port that you had specified in the configuration file which you created earlier.

Now do the same steps as before but this time for the internal interface.  Please ensure that the check box “Protect Firewall from Internal Zone” is marked. This is so that the internal interface (eth1) will be equally protected by the SUSE Firewall.

Finally select:

Next >> Finish

Upon completion your firewall will begin running, and will listen only on the SSH port that you have specified.

Once you have accomplished all of this, it is a good idea to make sure you are able to SSH to your server while using the key and your new user.

Setting Up your sudoers file

Assuming that you are able to ssh to the server using the key, the next thing I do is setup sudo. This is the sudoers file that I use:

Defaults always_set_home
Defaults env_reset
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS XDG_SESSION_COOKIE"
Defaults insults
root ALL=(ALL) ALL
%sudoer ALL=(ALL) ALL

like with the SSH configuration file, you can see that there is mention of a group that is allowed to be used for sudo access. Additionally, these changes ensure that the ROOT users password is not needed for a user to be given access to sudo. Please note that these changes are instant, and can be tested once you have saved the file and exited to the shell.

Setting Up Fail2Ban

Finally I add a personal touch to the configuration by installing fail2ban. This this is not the most robust Server safety mechanism, but it is effective in accomplishing its objectives. Fail2Ban is a tool used to block/ban users whom attempt to access your server without proper credentials. This is great for stopping would be attackers from getting into your server. Thankfully fail2ban is a tool that is in the openSUSE 12.1 repositories and is an fairly easy install.

Lets first install the application:

zypper in fail2ban

After the package manager completes its operation, we will need to chkconfig fail2ban to ensure it will be available upon reboot. We accomplish this with the following simple command:

chkconfig --add fail2ban

Now we need to configure Fail2Ban so that it is listening and notifying properly. The configuration files are located in /etc/fail2ban/. We could make direct edits to the jail.conf file, though I prefer setting a jail.local file; this way I maintain a pristine version of the original configuration file. Furthermore, fail2ban is setup to allow for an override if a .local file exists. To create the fail2ban configuration file I execute this command:

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Now I edit the file and change the following settings. Please make sure you change the (PORT NUMBER) to your port that you have setup in the sshd_config file.

# "bantime" is the number of seconds that a host is banned.
bantime  = 7200

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 7200

[ssh-ddos]

enabled  = true
port     = (PORT NUMBER)
filter   = sshd-ddos
action   = iptables[name=ssh,port=(PORT NUMBER),protocol=tcp]
           sendmail-whois[name=SSH, dest=you@mail.com, sender=fail2ban@mail.com]
logpath  = /var/log/auth.log
maxretry = 5

[ssh-iptables]

enabled  = true
port     = (PORT NUMBER)
filter   = sshd
action   = iptables[name=SSH, port=(PORT NUMBER), protocol=tcp]
           sendmail-whois[name=SSH, dest=you@mail.com, sender=fail2ban@mail.com]
logpath  = /var/log/sshd.log
maxretry = 5

[ssh-tcpwrapper]

enabled     = true
port        = (PORT NUMBER)
filter      = sshd
action      = hostsdeny
              sendmail-whois[name=SSH, dest=you@mail.com, sender=fail2ban@mail.com]
ignoreregex = for myuser from
logpath     = /var/log/sshd.log

While you are navigating the configuration file, please take notice that there are a lot of variables which can be enabled. Please feel free to investigate them as you see fit. This basic configuration will allow for your server to watch what is transpiring on the server with regard to SSH, and nothing more.

Preforming a System Update

Now that the basic configuration has been accomplished it is time to update the system to the latest packages as well as reboot the server once the update has completed.

To update the openSUSE system’s packages for the base repositories run:

zypper refresh

After the update has been completed I run a distribution update:

zypper dup

After the completion of the distribution update I reboot the system to ensure that the updates have been applied correctly. If you have made all of the appropriate changes upon reboot your server will have a user for remote access, an SSH configuration that limits access, you will have sudo setup for a particular user group, and you will have Fail2Ban assisting in the protection of your server.

reboot

Conclusion...

If you have liked this article and or want to know more about openSUSE, I would recommend that you have a look at the SUSE Linux Website and begin perusing their forums. SUSE has a wealth of information available online all for free. OpenSUSE.org is a great place to start.
 



Was this content helpful?




© 2011-2013 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