I touched on this topic in my First Day with Ubuntu at the Office post under Accessing Remove File Systems; however, I thought that this deserved its own topic.

For those that don’t know SSH stands for Secure SHell. In very non-technical terms, SSH allows you to access a system running a SSH server over a network. This other system can be another computer in your home or a remote system on the other side of the planet. SSH will allow you to connect to that other system and communicate with it securely. All the data passed back and forth is encrypted, so you don’t have to worry about people sniffing your passwords or valuable data.

You may be asking what all of that means to you. What it means is that you can connect to and control a computer that is somewhere else with the computer that is sitting right in front of you. If you have a remote webserver running Linux, SSH will let you install software, edit files, change the server configuration, access the database, and more. Did you forget a file on your computer at home? No problem, just SSH into your home computer and send the file to your email account or copy it directly to your office computer.

Hopefully those quick examples of what you can do is enough to whet your appetite.

Making SSH Work for You

When working on a Linux system, connecting to other Linux systems via SSH becomes so easy. Everything you need is bundled directly into the OS. All you need to do is load up the Terminal and run something that looks like the following:

After supplying the password, you’re connected.

So, if this is so easy, you might wonder what could make this any simpler. While the process I just described is definitely easy, there is always some server out there that requires a ssh command that is just difficult enough to be annoying. For example, imagine having to type the following each time you wanted to connect:

While it’s possible to remember this, who wants to?

Host-Based Config Options

Fortunately, ssh has a way to store options for each host.

This will load up the config file for editing in Gedit.

The format for setting options is as follows:

Using the config file, you can lose all those additional options and quickly connect by just using the following command:

Doesn’t that look a lot better?

Take the previous nasty example I provided. I can add the following to my config file for that specific host:

Host locutus.borg.domain.com
    User really_long_username
    Port 2222
    Protocol 2
    Cipher blowfish-cbc,aes256-cbc

After adding this to my ~/.ssh/config file, I can now connect with:

Easy cheesy.

There are a large variety of options available for the host-based config. For a full list of these options, run “man ssh_config” from Terminal.

Creating Hostname Aliases

Given the previous example, the hostname is locutus.borg.domain.com. That’s quite a bit to type, and it isn’t easy to remember how to spell locutus properly. Fortunately, the config file comes to the rescue again.

We can update our previous host definition to the following:

Host locutus.borg.domain.com locutus borg loc domain.com 192.168.1.105
    Hostname locutus.borg.domain.com
    User really_long_username
    Port 2222
    Protocol 2
    Cipher blowfish-cbc,aes256-cbc

Now I can easily connect to the system using any of the following commands:

Simply set up all the alias names you’d like to have after “Host” while seperating each one with a space. I always keep the original hostname in the list and add an additional alias to is easy to remember and type.

Keep the Connection Alive

Due to issues either caused by certain routers’ NAT firewalls or due to odd server configurations, I have found that my SSH connections will die if I leave then idle for too long. This is very annoying as it leaves me with a frozen session that I can’t do anything with. Fortunately, config comes to the rescue again. On each and every one of my host options in my config files, I have a ServerAliveInterval option that tells ssh to send a small keep-alive packet to the server at an interval that I specify.

For example:

Host domain.com
    User chris
    ServerAliveInterval 240

This tells ssh to send a keep-alive packet every 240 seconds, or four minutes. Now the only thing that terminates my connection is an actual loss of internet connection.

If you find that your connection still drops when idle, lower the number until it stabilizes. Even though the packet is small, you don’t want to send it too much. So, only lower the value to below a minute if you must.

Using Keypairs to Increase Security

SSH has the ability to use security keypairs to authenticate your session with the server. A security key can replace the need to supply your password when connecting to your server.

If you have access to modify your server’s SSH daemon settings, you can use your authentication key to disable password authentication. This means that an attacker would have to break your key’s encryption in order to connect rather than just having to guess your password.

Another great feature of keys is that you can use the same key for multiple server accounts. Since the private part of your key only resides on your local system, using the same key for multiple systems doesn’t decrease security in the same way that using the same password on multiple servers can. For example, if someone broke into one of your server accounts, they could get your public key, but this key will only give them the ability to give your key the ability to authenticate on other servers rather than giving them the ability to authenticate on the rest of your’s.

What This Means for Shared Servers

If your server is a shared host where you don’t have access to root, you typically can’t disable password authentication; however, keys can still greatly increase your security. Since you won’t need to supply your user’s password each time you connect since the key is doing the authentication, you can change your user’s password to something extremely strong and complex. This will make it very difficult for anyone to break into your account using brute-force methods.

Generating a SSH Authentication Key

Generating a key is extremely simple. Ubuntu, and most major distributions, have all the software you need already installed. Simply run the following command in Terminal:

Accept the defaults for all the options except the password.

Supplying the password is optional. If you simply press enter without supplying a password, your key won’t require a password to use. Let me share some information about what having a password on your key means to you.

• Unlike some password protection methods where the password is easily cracked, your key’s password is an integral part of the key. Without your password, the key is useless.
• If your key does not have a password, anyone who manages to gain access to your private key will have the ability to connect to every server your key is authenticated for without any password or other authentication required.
• On many systems, you will have to supply the password each and every time the key is used. Fortunately, for us Ubuntu users, we can simply opt to have the system remember the password for us as long as we are logged into our desktop. I’m sure that this feature is present on other systems, such as Linux Mint, but I haven’t tested which ones have this feature yet.

As you can see, there are great benefits to using a password on your key. There really aren’t any good reasons to not put a password on the key since Ubuntu will remember it for you.

By now, you should have generated your key. If you accepted the default location, you should have two new files in your ~/.ssh directory: id_dsa and id_dsa.pub.

The ~/.ssh/id_dsa file is your private key. This file should remain safe and secure on your system.

The ~/.ssh/id_dsa.pub file is your public key. The contents of this file will be used to authenticate your key with servers.

The permissions on the ~/.ssh/id_dsa file should be set up correctly by ssh-keygen. I like to make sure however as the wrong permission settings can cause the key to be ignored when authenticating. You can set the correct permissions by running:

Now it’s time to set up the server.

Setting up Your Server

Now you need to log into the server you want to use your key to authenticate with.

You need to create a ~/.ssh folder if one doesn’t already exist:

The -p will prevent an error from being thrown if the folder already exists.

Exit out of your server connection. We’re going to do a slick command from our Ubuntu Terminal to add our public key to the server.

From our desktop’s Terminal (not the server’s command line), run the following:

Replace hostname with the hostname that you use to connect to your server with. I’m assuming that you followed my instructions earlier and set up your ~/.ssh/config file to not require anything more than a hostname to set all the options needed to connect. If you haven’t done this, make sure you specify the port number (if other than 22), username, and any other necessary options to make the connection.

Testing

Now we just need to connect to the server again and see if it asks for the password.

If you are asked for a password, your authentication key was either not recognized, had improper permissions, or was not able to match with the server’s public key setting. A good way of checking on a potential problem is to run:

This will cause a large amount of verbose debug data to be printed during the connection phase. If the key is used properly, you should see the lines listed:

If you don’t see that the server can see the publickey authentication method or if that method isn’t the first one, your server isn’t set up to do key authentication. Contact your hosting provider and ask them if they can add this as it will increase server security.

If you can’t figure out the problem, please let me know. You can send me the output of your “ssh -v hostname” command via the Contact page, and I’ll do my best to help you out.

Conclusion

I hope that I helped you use ssh more efficiently and make your servers more secure at the same time. However, I’ve just scratched the surface on this topic. There are dozens of ways to use SSH in ways that I haven’t touched on.

Here are just a few additional things that you can do with SSH:

• Log into a visual desktop remotely by tunneling X
• Secure FTP alternative: use scp to easily transfer files between systems
• Mount remote file systems as local mount points
• Browse securely on insecure networks or bypass network restrictions to browse freely
• Easily run a command on remote servers directly. This is great for scripting status programs.
• And many more possibilities

I’m sure that I’ll touch on some of these subjects later on. If you’d like me to get to specific ones ASAP, please leave a coment and let me know what you’d like to see.

I got Ubuntu successfully installed on my office machine (Dell Studio 17) yesterday. Today, I’m going to use it all day at the office while making notes on what still doesn’t work, what I could get to work, how I fixed problems, and I’m sure some random ramblings will enter at some point.

Dual Monitors

The first issue didn’t take long to present itself. I have an external 24″ LCD that I have hook up to at the office. This morning, I did what I normally do, plug in everything, including the monitor, and then start up the machine. When Ubuntu came up, the LCD functioned, but it was a clone of main screen.

I went into System > Preferences > Screen Resolution to see if I could set the monitors to have independent content. Unfortunately only one screen was shown.

I rebooted with the monitor disconnected and then plugged it in when Ubuntu had loaded. This produced something new: The screens were still cloned, but the primary laptop screen always tried to “focus” or center on the mouse cursor causing large portions of the screen to be cropped off if I moved the mouse to any of the edges. This was a new situation. I restarted X (ctrl+alt+backspace), and the problem remained. I decided to ignore this until I found another solution.

I googled around, read at least a dozen forum threads, and still didn’t find anything to address the issue of using dual view rather than clone view. So, I did what any good computer user should (or shouldn’t) do; I started digging around the menus for a possible solution. It only took me a couple of minutes to figure it out.

The Dell Studio 15 and Dell Studio 17 use an AMD video solution (personally, I prefer nVidia, but I digress). If you install the AMD proprietary drivers, you get a program at Applications > Accessories > ATI Catalyst Control Center. From inside this program, I could select a specific screen, click on the Multi-Display tab, and tell it how I wanted that screen to behave. I selected the external monitor from the drop-down, clicked the Multi-Display tab and then selected “Big Desktop left of display 1,” which matched the physical setup of the screens on my desk. The screens reconfigured themselves immediately.

Since I’m using cubes with Compiz, I loaded System > Preferences > CompizConfig Settings Manager, clicked on “Desktop Cube”, and changed the “Multi Output Mode” option to “Multiple cubes” to give each screen its own cube.

Headphones

Since I work in a room with other people, I always have headphones in. As soon as I had my dual monitor issue taken care of, I loaded up some music and found out that the sound didn’t work. I unplugged my headphones and heard sound from the system’s speakers. I plugged the headphones back in and didn’t hear sound from the headphones or the speakers.

I think this issue is due to the fancy headphone outputs on the Dell Studio 17. There are dual headphone outputs. In Windows, a software package allows me to select how I’d like to treat the individual jacks. I can use them as headphone outputs or line outs. I think it’s this ability to switch the functionality of the jacks combined with the fact that there is more than one jack that causes Ubuntu to fail.

A bit of playing around later, I found that if I loaded the Volume Control (right-click the speaker on the panel by the clock and select “Open Volume Control”), selected the Switches tab, and checked the “Headphone as Line Out” option, that sound is properly sent to the headphones. However, this has a side effect as having a headphone plugged in no longer disables the speakers. I’m working around this by muting the sound for the Front outputs in the Playback tab while the headphones are in use. Not the best solution, but it works.

Also of note, only the middle headphone jack functions for headphones as the front jack seems to be unaffected by the line out option.

There is an update on the headphone issue: Headphones Jacks Now Fully Work on Dell Studio 17 Running Ubuntu

Accessing the Windows Partition

Since I loaded Ubuntu to dual boot with the existing Vista, I wanted to be able to access the contents of the Windows drive. Here’s how I did it.

First, I had to install a new package. I loaded up terminal and executed:

sudo apt-get install ntfs-3g

I then needed to find out which partition I needed to access. I ran “sudo fdisk -l” and received the following output:

   Device Boot   Start      End      Blocks   Id  System
/dev/sda1            1       19      152586   de  Dell Utility
/dev/sda2           20     1325    10485760    7  HPFS/NTFS
/dev/sda3   *     1325    16001   117882777+   7  HPFS/NTFS
/dev/sda4        16002    30401   115668000    5  Extended
/dev/sda5        16002    29810   110920761   83  Linux
/dev/sda6        29811    30401     4747176   82  Linux swap

Notice that /dev/sda3 is a bootable partition, is quite large (number of blocks), and uses the NTFS format. /dev/sda3 is my Windows partition.

I created a location to mount the partition called /mnt/windows  by running “sudo mkdir /mnt/windows“. I then modified the filesystem table (sudo vi /etc/fstab) and added the following line:

/dev/sda3  /mnt/windows  ntfs-3g  quiet,defaults,rw  0  0

The two bolded entries are what you will need to modify to match your own setup. The first option is the partition to mount. The second option is where you wish to mount the partition.

To load my changes immediately, I ran “sudo mount -a” to reload the partition mount instructions.

Now all my Windows files are easily accessible at all times at /mnt/windows.

Accessing Remote File Systems

Since I frequently access remote Linux file systems for my job and my hobbies, I thought that I’d take advantage of SSH Filesystem in order to make these file systems available as if they were local file systems. Thanks to the SSHFS AUTOmount on Feisty guide, I was able to set this up quickly and easily. Not only that, but the scripts provided automatically mount and unmount the filesystems when the internet connection goes up or down, which is really, really cool to play around with and watch.

I did make a modification to the /etc/network/if-down.d/umountsshfs script provided in the previously mentioned guide. This change may or may not be needed depending on your setup. I changed the last line to the following, note the bolded portion:

In case anyone is interested in my final /etc/fstab entry format, here’s one as a sample:

sshfs#servername:  /mnt/servername  fuse  comment=sshfs,
uid=1000,gid=1000,users,noauto,exec,allow_other,reconnect,
transform_symlinks,BatchMode=yes,ConnectTimeout=10  0  0

Note: I changed the actual server name to protect the innocent. Also, the uid and gid are specific to my setup. You can find your’s by running “id” on the command line.

You may notice the lack of username and other relevant parameters. I put those in my ~/.ssh/config file to make connections to the servers more easy. For example, here’s a sample entry from my ~/.ssh/config:

Host hostname
     User username
     ServerAliveInterval 15
     Port 23

An entry can be created for each server with specific SSH directives which allow you to keep connection information for often-used servers short and simple. Setting the ServerAliveInterval helps keep inactive connections alive (this may not be needed or recommenI have to ded in your setup). You can find a full listing of available options and their descriptions at the ssh_config NetBSD Manual Page. You might also find the SshfsFaq helpful if you try to set this up.

Misc Other Setup

I installed Crimson Editor to be my programming editor until I find one I like that is Linux based. I really like Crimson Editor, so it’s going to be hard for me to find a replacement. Running CE in Wine isn’t without its problems though. It seems that CE only remembers changes to settings if I exit by doing File > Exit. If I simply close the window, the settings are not saved.

I tried gedit earlier, and it is extremely close to what I want but is just enough off to make me not want to keep trying with it. It sounds silly, but if gedit just added the ability to make the tabs visible, I would probably use it as my main editor.

I installed jEdit, but it failed to load. I reasoned that since jEdit was built on Java that the JRE was missing, so I installed it. I find it odd that the JRE wasn’t installed by default when I installed jEdit. I’ll try it out later and see what I think.

I can’t use my favorite coding font, Dina, so I’m hunting for a replacement there as well. So far, I’ve tried Bitstream Vera Sans Mono and Monaco. They are both nice, but they just aren’t what I’m looking for. Oh well… Time to keep looking. Why or why can’t I just have my lovely Dina?

Remaining Issues

I still have massive problems with video. I’m starting think that AMD video hardware just doesn’t perform well in Ubuntu, even with the proprietary driver. Flash video is fine, but all other video is choppy or has a frame rate around 1fps. The performance is so poor, it seems like all video decoding and rendering is handled in software rather than hardware. I have yet to confirm this though.

I can increase or decrease the brightness using the Fn+Up/Down keys, but there are problems. The brightness indicator doesn’t go away, the keyboard stops functioning, and the panels no longer function. Every time I accidentally adjust the brightness manually, I have to restart X (Ctrl+Alt+Backspace).

There are odd times when X just seems to fail. It always happens in different ways, but every time it happens, the windows just stop responding properly or windows get stuck in odd places. As with the brightness adjustment issue, restarting X is a quick fix. I’d really rather not have to do that though as it closes everything I have open. Sure beats a complete reboot however.

The trackpad on the Studio 17 is really wide. I keep accidentally touching it with my palm, causing focus to shift elsewhere while I’m typing. I need to see if I can change a setting somewhere to ignore the touchpad as I type.

The mouse acceleration is much different than I’m used to in Windows, but I’m sure that I will get adjusted to this.

Performance overall seems a bit sluggish. For example, whenever I visit a WordPress site that has the snowfall thing going on (thanks Matt), scrolling is very choppy and closing/switching tabs becomes slow. I’ll have to see if I can find a site that has information about optimizing Ubuntu performance to get the mose out of the machine.

Final Thoughts

I have to admit that I’ve found more issues that I expected, and not all the problems have been readily solvable. Ubuntu has already given me the ability to do things that I just couldn’t do with Windows. Ubuntu has also presented some very core problems which may or may not be fixable, but at least I have the power to make changes and try to fix it while I always felt that Windows told me to “suck it up kid, that’s the way it is.”

I’ll be playing with the system more over the weekend. I hope to have it in fighting shape by Monday so that I can stop messing with my computer and start using it.