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.
Here is how I deployed my first openSUSE 12.1 Server:
- Rackspace Cloud Server
- Image 109 – openSUSE 12.1
- Flavor 2 – 512MB
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)
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.
groupmod -A (USER NAME) sudoer groupmod -A (USER NAME) sshuser
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.
As a reminder you will need to generate the SSH user key, to do this use this command:
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
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:
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 >> Eth0 — Select External
Interfaces >> Eth1 — Select 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.
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.
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.
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
# "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, email@example.com, firstname.lastname@example.org] 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, email@example.com, firstname.lastname@example.org] logpath = /var/log/sshd.log maxretry = 5 [ssh-tcpwrapper] enabled = true port = (PORT NUMBER) filter = sshd action = hostsdeny sendmail-whois[name=SSH, email@example.com, firstname.lastname@example.org] 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.
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:
After the update has been completed I run a distribution update:
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.
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.
© 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