I recently encountered a very strange problem on a computer running openSuse. The computer had a sound card built into the motherboard, as most computers do, but it also has a new nVidia GT430 video card, which does sound over HDMI. I wanted to use the built-in sound, so I went into YaST, selected Hardware, then selected Sound. It was here that I noticed only the nVidia sound card was detected. Bummer. I pulled up the user’s manual for the motherboard, an Intel DG33BU, and found that the sound chip was an ALC888, which is made by Realtek. I researched the ALC888 a bit and felt very confident that it should be natively supported by openSuse 11.4. Hmm, what the hell was going on?

At this point, I needed to know if the computer was detecting the built-in sound at all. This is done by using the lspci command:

helium:/home/wes # lspci | grep Audio
01:00.1 Audio device: nVidia Corporation GF108 High Definition Audio Controller (rev a1)

Again I see only the nVidia card, which was not the one I wanted to use. But since this result was coming from lspci, it meant the computer didn’t even know there was another sound card in the system at all. I suspected that the built-in sound chip was dead, fried, or damaged badly enough that the computer just ignored it. However I researched a bit on the internet, and someone suggested checking for a BIOS update.

I rebooted the computer and went into the BIOS, and yes, the BIOS was badly out of date. However I kept poking around in the BIOS, and on the Advanced tab I noticed that the built-in audio had been disabled. Doh! I enabled it, rebooted the machine, and ran the lspci command again:

helium:/home/wes # lspci | grep Audio
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
01:00.1 Audio device: nVidia Corporation GF108 High Definition Audio Controller (rev a1)

Jackpot, the computer was now detecting the built-in sound. Once again I went into YaST, then Hardware, then Sound, and enabled the sound. It worked like a champ!

It left me wondering, who disables the sound in BIOS? What an annoying problem.

NX is an awesome way to remotely access a server. It’s much faster and more responsive than VNC, but it also has a much more modern feature set. The really cool part is that each NX session is actually it’s own virtual desktop session. When you close the session out, it can be preserved for the next time you log in. This would allow you to, for example, serve up a few hundred virtual desktops using just one server. The other big feature is that all of the traffic is SSH encrypted, so it’s secure enough that I actually access my home server from the internet at large.

SSH traditionally uses TCP port 22. So if you want to access your NX session from work, or another country, or whatever, just setup your router to forward port 22 to your server. While SSH itself is secure, this leaves your system vulnerable to brute-force attempts at cracking your password. Here is a sample from the file /var/log/messages of my own home server:

Feb  7 15:41:14 helium sshd[25695]: Invalid user oracle from 203.113.137.188
Feb  7 15:41:18 helium sshd[25704]: Invalid user guest from 203.113.137.188
Feb  7 15:41:20 helium sshd[25708]: Invalid user marta from 203.113.137.188
Feb  7 15:41:23 helium sshd[25712]: Invalid user anti from 203.113.137.188
Feb  7 15:41:25 helium sshd[25716]: Invalid user dragon from 203.113.137.188
Feb  7 15:41:29 helium sshd[25723]: Invalid user backup from 203.113.137.188
Feb  7 15:41:34 helium sshd[25731]: Invalid user mike from 203.113.137.188
Feb  7 15:41:38 helium sshd[25740]: Invalid user mythtv from 203.113.137.188

What you see above is my server rejecting SSH login attempts from a system with the IP address 203.113.137.188. That system was trying different combinations of usernames and passwords in an attempt to gain access to my machine. Until I checked out the contents of /var/log/messages, I had no idea that these attacks had been going on for months, and originated from dozens of different systems. It’s remarkable that no one managed to gain access to my system.

So what did I do to stop these attacks? The first order of business is to harden up your ssh service. Edit the file /etc/ssh/sshd_config, and find the line that says:

#Port 22

Uncomment that line and choose a new, high value (somewhere in the range of 50000 – 65535 is good). Now, at the end of the file, add a line similar to the following, making sure to use your username in place of bob:

AllowUsers bob nx

Now we will update our NX installation by editing the file /usr/NX/etc/server.cfg. Find the two following lines:

#SSHDPort = "22"
#SSHDAuthPort = "22"

The first one is near the beginning of the file, while the second is near the end. Both of those need to be uncommented and changed to match the port that you picked when you modified the sshd_config file. Finally, you are ready to restart the SSH daemon and the NX server with the following commands:

/etc/init.d/sshd restart
/etc/init.d/nxserver restart

Lastly, don’t forget to change the port number settings in PuTTY, the NX Client, and your router’s forwarding table so you can actually log in.

So what have we gained in all of this?

1. Only the user bob will be allowed to log in via SSH or NX. Even though we added the user NX to the list of allowed users, the way NX works prevents someone from SSHing into the server under the username NX. This greatly reduces the chances that someone will guess both the username and password to the single user account that is enabled for SSH login.
2. We have picked a high TCP port for the SSH daemon to use. This means that brute-force attacks now must also scan through all 65535 possible TCP ports, which greatly increases the length of time any attack would need to be successful.

The combination of those two points and a strong password for your account will make it extremely unlikely that a brute-force attack will be successful against your system. This is just the beginning of a very large topic, and there are other security measures you can use (such as a program called fail2ban) which will further ensure that no unauthorized users gain access to your system.

Here are two things I found while trying to configure an opensuse server.

Can’t resolve hosts after setting up DNS

After following a tutorial such as this to configure a domain name server (DNS) on my opensuse 11.2 server, I found myself in the following situation:

wes@helium:~> nslookup titanium.test.local
Server:         127.0.0.1
Address:        127.0.0.1#53
Name:   titanium.test.local
Address: 192.168.1.101
wes@helium:~> ping titanium.test.local
ping: unknown host titanium.test.local

What you see happening above is that I first ask the computer to tell me the IP address of the host titanium.test.local by using the command nslookup. nslookup resolves the IP address correclty, however, right after that, the ping command is not able to find the IP address for titanium.test.local. This was really confusing to me. If I was able to correctly resolve a hostname with nslookup, there should be no problems using that hostname with other commands. What I found was that opensuse has a strange configuration in the file /etc/nsswitch.conf.

hosts: files mdns4_minimal [NOTFOUND=return] dns

This line controls how the computer resolves hostnames. I think what was happening was that the domain I had created for my home network, test.local, was not contained in files or mdns4_minimal, and the NOTFOUND=return was causing the lookup to stop before the DNS server was used to try to resolve the hostname. Anyway, I just modified that line a bit:

hosts: files dns mdns4_minimal

That seems to have solved the problem. Everything looks good now:

wes@helium:/etc> ping titanium.test.local
PING titanium.test.local (192.168.1.101) 56(84) bytes of data.
64 bytes from 192.168.1.101: icmp_seq=1 ttl=128 time=3.64 ms
64 bytes from 192.168.1.101: icmp_seq=2 ttl=128 time=3.69 ms
64 bytes from 192.168.1.101: icmp_seq=3 ttl=128 time=5.64 ms

Setting a static IP address

If you want to give a computer a static IP address, you need to enter the IP address, submask, and gateway address (usually your router’s IP address), and you do this regardless of what operating system you are using. However openSuse is kind of weird in that the gateway address is not where you would think it would be:

Nope, not there with the IP address and submask. Instead it’s here:

If you forget to navigate to this extra screen and enter the gateway address, the computer will not know how to route traffic out to the rest of the world.