Ubuntu Tutorials

I spent a little bit of time trying to find an answer to this today but I was unsuccessful. I’m hoping one of you will have the secret for me.

Situation:
I’ve configured my .ssh/config file with profile and port information for the many servers I connect to on a regular basis.

Problem:
One of the servers I need to access requires bouncing through another server first. ie; In order to access machine2 I have to connect to machine1 first. How to automate this within the .ssh/config?

When I manually connect to this I use:

ssh -t machine1 ssh machine2

What I would like to do is configure my .ssh/config file to use that -t option when connecting to that specific machine. I would like to be able to simple run:

ssh machine1

and based on the configuration in the .ssh/config have this automatically connect to machine2.

Any ideas?

At work we maintain over a hundred machines, most of which are regularly accessed via SSH by our developers.  Due to the number of machines and the number of tasks that need completed, we found that many of the developers would often forget they were logged into a server and leave an idle SSH session open.  Due to the sensitive nature of the data on many of the servers we needed to find a solution to this.  We decided to implement an SSH feature to automatically logout SSH sessions after a period of inactivity.  Here is how we did it.

Inside the sshd_config file (/etc/ssh/sshd_config) there is a setting for ClientAliveInterval and ClientAliveCountMax.  Edit these two lines to look something like:

ClientAliveInterval 300
ClientAliveCountMax 0


Once these settings are changed you’ll need to restart your SSH server for them to take effect.

sudo /etc/init.d/ssh restart

Now, if an SSH session is connected with no activity for five minutes, it’ll be automatically logged out. Hopefully reducing the chance of an open connection becoming vulnerable at an idle workstation.

I have been tunneling all of my web traffic over an encrypted SSH connection for some time now. Considering the fact that I travel a lot, I’m very regularly on untrusted, insecure networks. I prefer to secure those connections (web, IM, email, etc) by creating an encrypted SSH connection and pushing the traffic through it. Today I also found a method for also pushing DNS requests through the same tunnel. This ensures total privacy between yourself and the SSH dedicated server.

Step 1: Creating the Tunnel

Creating this private connection you’ll need a remote SSH server to connect to. Mine runs at home in my garage on an old Pentium III 500MHz box (yeah, the kind most people threw away long, long ago!). I connect to this tunnel using:

ssh -D 8080 -fN user@server

This creates a SOCKS compatible proxy, which is a requirement of the DNS forwarding. Other methods on the interwebs suggest using ssh -L or similar, which are not SOCKS compatible proxies.

Step 2: Forwarding DNS

If you’d like to also forward your DNS requests (ie; the site addresses you type into your browser), you’ll need to change a setting in Firefox. This can be done by accessing the address about:config, and entering this string into the configuration:

network.proxy.socks_remote_dns

Change this value to “true”.

Step 3: Using the Tunnel

The last step is to configure your browser to use these new settings. In Firefox 3 (I hope you’ve upgraded by now), you can activate/toggle these settings via:

Edit > Preferences > Advanced > Network > Settings

Select “Manual Proxy Configuration” and add localhost to the “SOCKS Host:” field, followed by port 8080 (assuming you’ve used the port in the example above).

This will then forward your web traffic through the SSH tunnel and DNS requests will also be forwarded.

You may want to check out the FoxyProxy plugin for a simpler way of toggling this on & off.

To deactivate the tunneling and use the local DNS again simply revert Step 3 back to “Direct Connection to the Internet”.

I covered VNC this afternoon in my Linux system administration course and the question came up on how to secure VNC. You may or may not be aware than VNC is not encrypted by default, which could be a security concern.

If you use VNC regularly to connect to other Linux machines you may want to consider adding a level of encryption with SSH. Here is a quick run-down on how that is done:

If you look at the man page for vncviewer (man vncviewer) you’ll notice there is a small section for -via. The -via option, as outlined in the man page will do:

Makes the connection go through SSH to a gateway host. The gateway should be the target host for best connection secrecy.

Basically this is saying that you can tunnel VNC over SSH within your connection command. Let’s give it a try.

vncviewer -via user@host localhost:0

This, of course, will require that you have both ssh and vnc access to a remote machine.

This is a much simpler method than many other tutorials I’ve found which generally suggest creating a tunnel with ssh -L and then using that tunnel.

I was parsing through some of the logs on my new server tonite and I saw some unsuccessful ssh connection on ipv6. I thought I would mention quickly how you can disable listening on ipv6.

ListenAddress

The /etc/ssh/sshd_config file configures how your ssh daemon should run. By default it is likely listening on 0.0.0.0 (all ipv4 addresses) and :: (all ipv6), which is defined by two lines:

#ListenAddress 0.0.0.0
#ListenAddress ::

To configure your server to *not* listen on ipv6 you can remove that line. Now it might appear a bit confusing that the line we’re removing is commented out. That means its not reading that line, right? In this case it is displaying one of the default settings. I have altered my file to only listen on my public facing ipv4 address by removing the “::” listing, and specifically defining an ip instead of “0.0.0.0″.

Another solution which was brought to my attention by a comment is outlined here:

AddressFamily any # default
AddressFamily inet # IPv4 only
AddressFamily inet6 # IPv6 only

By defining the AddressFamily type that we want to use we can listen on both ipv4 and ipv6, just ipv4 or just ipv6. Find the line above in your config and define the AddressFamily you would prefer to listen on.

Once you update these lines you’ll need to restart your ssh service.

sudo /etc/init.d/ssh restart

Also, as a second measure you can firewall ipv6. I’ll be posting a firewall tutorial soon, but the below single command will block all incoming traffic on ipv6:

sudo ip6tables -P INPUT -j DROP

Quick-connect options for network shares inside gnome can be even easier than using the Places > Connect to Server options. You can also quick-connect to these using the ALT-F2 run dialog. As far as I understand these are interchangable in their features, its just another more flexible way for you to connect to a remote machine or network share.  I’ve tested quite a few of these below and they seem to work just fine.  Are there any others that I have missed?  Here are some examples:

ALT-F2: "ssh://user@host"

ALT-F2: "ssh://user@host:/some/folder"

These will connect and open up nautilus with the contents of that network share. They also work for samba, for the Windows people.

ALT-F2: "smb://servername"

Or if you’d prefer FTP or the more securet SFTP.

ALT-F2: "ftp://hostname"

ALT-F2: "sftp://user@servername:port

…it even supports HTTP(S).

ALT-F2: "http://google.com"

I don’t think loading network connections can get much faster than that. Enjoy. Thanks goes to the Ubuntu Colorado list and David for pointing this out.

You might remember a recent tutorial I did on securing VNC via SSH with the -via option of vncviewer.  Today I started looking into it more with one of my students and we wanted to make the -via option use compression.  By default it just creates a basic tunnel with SSH and doesn’t let you get much more specific.  We figured out how to make it follow more specific instructions!

update: the environment variable is valid in vncviewer version 4.1.2, but apparently not in Feisty’s current version, 3.3.7.  Solution 1 applies to Ubuntu, Solution 2 does not apply to Ubuntu (successful on RHEL5 and most likely recent Fedora series)

Solution 1:

vncviewer will look to client-side configuration files for its settings.  You can create a ~/.ssh/config file for any of your ssh connections and, which might look like this:

Host alias

HostName hostname

Compression yes

User username

…you get the idea.  This will connect to the HostName value when you “ssh alias”, using Compression and the User specified.  You can use any valid ssh value in this config (see man ssh).  Using client-side configuration like this can cut a long ssh configuration down to a much shorter one.  ie;

The vncviewer will look for this file when used in combination with the -via switch and use compression if set to on, as above.  Test it with and without the Compression value and see if you find a difference in performance.

Solution 2:

vncviewer uses an environment variable to start an ssh connection.  By default it looks like:

VNC_VIA_CMD=/usr/bin/ssh -f -L “$L”:”$H”:”$R” “$G” sleep 20

You can find this using one of the following:

env | grep VNC_VIA_CMD

or

strings /usr/bin/vncviewer | grep ssh

The second method of altering it’s connection settings are to update this environment value and tell it to use Compression.  This would be done using the following:

export VNC_VIA_CMD=’/usr/bin/ssh -C -f -L “$L”:”$H”:”$R” “$G” sleep 20′

(that uses single quotes around the entire value and double quotes on the embedded values.  This is important.)

So, if you do a lot of work with VNC I hope you’re using the -via option for SSH tunneling.  Now you can also compress your connection for better performance on slower networks.  What are your results here?  Do you notice much of a difference?  I have only tested this on a LAN so the speeds are fast in the first place.  Anyone want to share their results out over the public interweb?

I was discussing VNC this afternoon with some students and the question came up on how to secure VNC.  As you may have noticed most network protocols do not have much for built in security.  Many rely on other programs for their network security needs, such as ssh.  This is also the case with VNC.

If you use VNC regularly to connect to other Linux machines you may want to consider adding a lower-layer of encryption with ssh.  Here is a quick run-down on how that is done:

If you look at the man page for vncviewer (man (1) vncviwer) you’ll notice there is a small section for -via.  The -via option, as outlined in the man page will do:

Makes the connection go through SSH to a gateway host.  The gateway should be the target host for best connection secrecy.

Basically this is saying that you can tunnel VNC over SSH within your connection command.  Let’s give it a try.

vncviewer -via user@host localhost:0

This, of course, will require that you have both ssh and vnc access to a remote machine.

There are those of us that do a lot of ssh during the course of a day. I know I do quite a bit for accessing my files from my office. In any event you’ll probably want to setup public key authentication which allows you to login via ssh without a password.

Of course this adds a level of convenience for you, but could be considered less-secure. While its difficult to spoof an rsa/dsa encryption key (probably more difficult than a simple password) anyone that has access to your machine would be able to access the remote machines via this authenticated key.

There are a few quick steps for setting this up that I’ll outline below.

First you’ll need to generate your local public key. This is the public end of a local public / private pair that you’ll share with the remote machine to identify you.

ssh-keygen -t dsa (on your local machine)

Second you’ll need to copy this key to the remote machine using a command such as:

scp ~/.ssh/id_dsa.pub user@yourserver.com:~

Lastly, log into the remote machine via ssh (using your password for the last time!) and use this command to add the newly generated key to the list of authenticated keys:

cat id_dsa.pub >> .ssh/authorized_keys

You’ll also probably want to delete the original key as well.

rm id_dsa.pub

At this point a copy of your key is now stored on the remote machine as an authorized keys and any ssh connection coming from the local machine will match that key and connect with the key authentication instead of a password. So nice.

…just remember that anyone with access to your machine will now have this access as well. Definitely keep this in mind if you’re using any kind of a public machine.