StellarTech Blog

One of my favorite and most often used services is openSSH. While openSSH is generally known as being secure it never hurts to tweak a few extra settings.

Here are a few changes I generally do to help ensure openSSH is in tip top shape.

1. Use a strong password. My preference is to use randomly generated passwords of 20 plus alphanumeric characters with their own special blend of special characters. That should thwart most password crackers.
2. Change the port sshd listens on. Using port 22 hangs a sign out on your server saying I use sshd. While changing the port won’t stop anyone from figuring out you are running the service it will make them work harder. You can do this by changing the following in /etc/ssh/sshd_config:

   Port 1234

3. Get rid of root logins. There is absolutely no reason to log in as root when you can use ’sudo’ or ’su’ to elevate a wheel user to root privileges. To set this change the following line in /etc/ssh/sshd_config:

   PermitRootLogin no

4. Disable the antiquated Protocol 1 by changing to the Protocol line in /etc/ssh/sshd_config from ‘Protocol 1,2′ to the following:

   Protocol 2

5. Another option would be to block lame dictionary attacks with denyhosts or ConfigServer Firewall/Login Failure Dameon. ConfigServer firewall has the added benefit of adding a friendly interface to help managing IPtables. Blocking login failures can sometimes be overkill if you are already have other restrictions in place like using keys only or using the AllowUsers directive in your /etc/ssh/sshd_config
6. If you prefer to use keys instead of password the following changes to /etc/ssh/sshd_config are a good start in tightening things up. If you are going to have any accounts that use password authentication you’ll be locked out of the server making these changes. So only do so if you are using keys to log in:
   
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no

7. If you prefer to leave password authentication on then the AllowUser directive is for you. Below are a few examples this directive in play.
   
AllowUsers iizwheel@*
AllowUsers fjones@*
AllowUsers *@123.456.7.8
AllowUsers *@222.333.444.*


If anyone has further suggestions on securing openSSH please let me know.

Later I plan on doing posts on creating and using ssh keys, setting up DenyHosts, and setting up ConfigServer Firewall in future.

We are proud to announce an expansion of our current hosting offering. In the past we have offered more of a managed approach to hosting with each site we develop free for a year which included a 12 hour support response turn around. In order to give clients more control over their development and hosting environment we have expanded our fleet of dedicated servers with 2 more Linux cPanel servers.

We are currently migrating many of our existing clients to the new servers who have requested control panel access to their hosting environment. If you have an existing site with us and would like to have it migrated let us know and we will do so free of charge if requested before the month of April 2009.

New hosting and support packages will be offered at a later date so stay tuned.

Have you ever setup a cool /etc/motd on your Ubuntu installation just to see it vanish after a reboot? We don’t need Scooby and the gang to solve this mystery since it’s obviously a start-up script.

Here some cli medicine to make things all better:
touch /etc/motd.static && rm -f /etc/motd; ln -s /etc/motd.static /etc/motd

By default /etc/motd is symlinked to /var/run/motd which is rebuilt by /etc/init.d/bootmisc.sh every time you reboot.

I post this for archival purposes and the greater good of all mankind since I had little luck in finding a solution on Google quick enough.

Some things make me mad. Enough to want to start pulling my flesh out in clumps. This includes controlling all things in my environment down to even the smallest detail. So when I lose the ability to change my desktop background I seriously lose sight of all reason until the pain goes away.

I was at work connected to my Linux workstation, using Gnome’s Remote Desktop setting aka VNC aka VinoServer, through a ssh tunnel when lo and behold the power flickered at home and shut the workstation down. When I got back home I had a big ugly solid color set as my background. Changing the background in ‘Appearance Preferences’ and turning off Remote Desktop both fixed nothing. I even rebooted and then rebooted again picking a different kernel. Each time I was presented with the same big black screen. I foamed, I raved, I swore. Anything would have been more tolerable than this.

I finally fixed the problem by launching gconf-editor and then transversing to / -> desktop -> gnome -> background and checking draw_background. All was well after and I went to sleep.