TangoRangers.com's Blog

There are a couple ways to limit where users can and cannot use SSH keys for quick access to systems. The most common I have found is to put access requirements in the sshd_config file. While this is a great method, and has quite a few ways to customize it. What if you only want to limit access for one user? Or maybe you don’t have root/sudo access on the machine and you want to limit your own account. Well, these might be the best examples, but here is another nifty way to limit access with SSH keys. Please note that this will only block access with the key, but will still allow you to provide a password!

Lets get started. I’m going to assume you already have generated your key and used ssh-copy-id to get it to your remote host. SSH into your remote host and open your user’s authorized_keys file. This is usually in ~/.ssh/. You are going to see something like this.

ssh-rsa AAAAB3Nza...LiPk== user@host

Simply add from=”host” in front of it and you are set! Seriously, it is that easy.

from="192.168.1.3" ssh-rsa AAAAB3Nza...LiPk== user@host

The best part here is you don’t need to do anything for the changes to take effect. No restarting sshd or even logging out of the machine! It just works right away.

You can add other options in authorized_keys and not just limit by IP. What if your IP changes? Maybe you are always in a particular domain range somewhere, perhaps you want to force a VPN connection before allowing SSH (I’m just throwing out ideas here). I use it for my backup system. I allow root access only from that one machine and otherwise you can’t login via root at all. I only allow the one key and no password. So right there is a good use.

To see more options and additional syntax, open a terminal and type “man authorized_keys” and scroll down to the section titled Authorized_keys File Format. There is a lot of good information there.

I have been living and working in SSH environments for quite some time now. I even created a little bash script to help me keep track of all my connections. Today I wanted to talk about a new way (well, it’s not really new, but new to me I guess) of connecting to other Linux systems by using keys instead of passwords.

Normally when you open an SSH connection you are presented with a password request. The down side to using passwords is that if your not paying attention you can be hit with a brute force or dictionary attack. Because you allow passwords to be used there is a chance of someone gaining access. With keys only you have nothing to fear from these types of attacks.

Here is how it works. Normally you enter a password. With keys all you need to do is form the SSH connection and the keys transmit automatically. Once the keys are paired you are connected with a shell. There are two different ways of performing key pairs. The first way is just the key. No need for a passphrase. The other is a passphrased key. I will talk about both.

First is the “no passphrase key.” In this example you will create a key, upload it to the host, then every time you connect you will not be asked for a password or passphrase. Keep in mind that by doing this there are risks involved. More on that later.

To make a “no passphrase key” you need to generate a key pair. The simplest way of doing this is:

ssh-keygen -t rsa

When it asks you for the password just hit enter. You will get an output of something like this.

Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
52:b8:d4:fd:d3:f6:ef:46:d1:90:42:de:e2:94:f4:09 user@localhost
The key's randomart image is:
+--[ RSA 2048]----+
|           .E  . |
|       o . o.=o. |
|      o o . =.+..|
|     . o   + o ..|
|      o S   + o .|
|       .     o ..|
|               ..|
|                o|
|               oo|
+-----------------+

NOTE: These are test keys I generated, they won’t work after today.
This created two files. “id_rsa” and “id_rsa.pub”

Take the id_rsa.pub file and upload it to the remote system. There are several ways of doing this. You can use scp, or if you are already connected you can copy and paste the contents of the file in pico, nano, vi, vim, what ever your favorite editor it. Be sure if you use the copy and paste method you keep the entire key in one line!

For scp type:

scp id_rsa.pub @:/.ssh/

This will upload the pub file to the remote host. Once uploaded, login then navigate to ~/.ssh (your user’s home directory then to .ssh). Once there look for a file called “authorized_keys” and cat the contents of the pub file to it. If the file already exists type:

cat id_rsa.pub >> authorized_keys

If the file doesn’t exist use only one (1) “>”

For the copy and past method, cat the id_rsa.pub file to display the output. Select it. Login to the remote host. Open authorized_keys in an editor of your choice. Then paste the copied key. Make sure it stays all on one line! If you don’t it will not work. Save the file.

Once one of these two steps for implementing the key file has been completed you are good to go! You can delete the .pub file if you desire.

Now, onto part 2!

Here is where we generate passphrase keys. It’s basically the same task. When you generate a key put in a passphrase! Remember the passphrase. It is very important. Now when you login you will be prompted to enter you passphrase. This will unlock the key to be used for the connection. It should be different from your normal password.

Now, a few more little notes I want to talk about.

The problem with no passphrase keys: Without the need for a key is someone gains access to your system (like a laptop) they can gain access to any system you authorized that laptop to connect to. With passphrased keys you must type in a passphrase to authorize the key.

If you have problems make sure your ssh config is set to allow keys! Refer to your distro’s help files for more information. In the config you can also disallow passwords all together. The only way to login would be with the use the keys. The down side is if you lose your local key. If you do this method, ensure you have a backup plan. Like another computer with access keys. In Slackware Linux the lines to look for are in /etc/ssh/sshd_config

PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
PasswordAuthentication no

Note that it becomes a pain if you generate multiple keys for multiple machines. There are ways of doing it, but it adds longer lines to your ssh commands. You can use the same .pub file on any other remote machine you wish to connect to. I don’t know for sure if it would be considered bad practice to do so, but I don’t see what problems would truly arise.

What’s the true benefit to this instead of saving time typing a password? Security. If an attacker can’t use a password (since many users passwords are weak) it would essentially eliminate their ability to gain SSH access. What do you think if the likelihood of the attacker to guess your key. Look at id_rsa. It’s a pretty big key to guess.

Ever needed to work from home, but have the problem of using a Samba share on the server while at work, but not at home? Well here is a simple fix.

In my example I’m working on a “sandbox” from home. The folders I work in have files with more than one owner. This becomes a nightmare even when I ssh in. Some might think an NFS share would be better. Unfortunately with NFS you are stuck with the current file permissions. With Samba those file permissions are given to you. That may sound a bit confusing, so let me try to clear it up a bit. Let us say there is only one file in the Samba share. User “ender” has ownership of the file. I can’t alter it. When I login with Samba the file appears to be owned by me not “ender”. Now I can do my work and when I log out the file is still owned by “ender”… wow, I don’t think I did a good job there either. Lets just say that when in comes to file permissions, Samba is the way to go.

But I need to work over ssh? Only port 22 is open from the outside. No problem!

We simply need to create a ssh tunnel. For this we already know we need to connect to port 139 on “sandbox”, and we need a local port to connect to. I would say just make it 139 also. Unfortunately for me I’m also running Samba on my local machine, and I can’t do that. So any non used port will do. How about 1139?

ssh user@remotehost -L 1139:localhost:139

Simple as that. That will connect port 1139 on your local machine to 139 of the remote host. The “localhost” actually refers to the remote host. It’s saying connect 1139 to my local machine to the remote host’s “localhost” port 139. If you are actually connecting to a windows box on that network you can “bounce” off the linux host to the windows. For more information you can refer to a previous post: Secure VNC for free for more information.

Now comes the fun part. You have 1139 on your local machine tied to 139 on the server. Now to mount the share as a local disk.

As root we mount the share.

mount -t cifs //sandbox/www /mnt/sandbox/ -o username=<username>,password=<password>,ip=127.0.0.1,port=1139,uid=<your local UID>,gid=<your local GID>,file_mode=0770,dir_mode=0770

Fill in your Samba share’s username and password, then your local machine’s UID and GID. To find the UID and GID type:

cat /etc/passwd | grep <your local username>
cat /etc/group | grep users

This assumes your regular user is part of the “users” group.
It will show 2 numbers. UID is most likely 500 or 1000, and GID is likely to be 100.

After filling in the blanks hit enter and your set! This will use the local port 1139 through the ssh connection to 139 on the server. It may seem a little slow at first, but that may be from the old server I’m connecting to.

If you want to store the info in fstab try:

//sandbox/www    /mnt/sandbox     cifs        noauto,rw,username=<username>,password=<password>,ip=127.0.0.1,port=1139,uid=<UID>,gid=<GID>,file_mode=0770,dir_mode=0770          0   0

Now for some reason I can’t quite get this to work, but others seem to have no problem with it. You can add the mount line above into your /etc/fstab file so a regular user can mount. I did this, but it doesn’t work for me. I get an error saying “only ROOT can mount this”. If you get this error try:

chmod +s /usr/sbin/mount.cifs
chmod +s /usr/sbin/umount.cifs

Like I said, it didn’t work for me, however after creating the ssh tunnel I simply open a new terminal window, su to root and then type “mount //sandbox/www” and it works fine.

Also, the reason I don’t background the ssh connection is because if it drops you may run into some problems with trying to mount it again (or even trying to use umount). I had this problem and it gave me a head ache to try to fix it without just rebooting. I’m sure I could have forced an umount.cifs, but I didn’t try (actually I didn’t realize it was actually still mounted). When logging in I recommend running a command that continuously sends data like “top”. That will help prevent the connection from being lost. If the connection is lost you must umount the share, reform the ssh tunnel, and try again.

NOTE: If you are connecting to a share on a Windows 7 box you must open 2 ports, 139 and 443 (or so I’m told). To do this open up a few terminal windows and create two separate connections. After that I do not know as I have never tried.

EDIT NOTE: I wrote this some time ago and just now got around to posting it. I hope everything works fine for you as the mount works fine for me (except under fstab for some reason). Don’t forget that by typing the command into the shell it will be stored in your history. If the password is sensitive I would recommend clearing out your history after mounting the share.

Recently I started school (which is why I haven’t done much of anything on my sites) where they have a wifi connection just like at a coffee shop. The problem with these open networks is that people (like myself) can run a packet catcher like WireShark and get user names and password for various sites such as yahoo, facebook, and myspace. Since when you log in to those you are doing so without https (encryption). Also my school logs every site to visit and when I’m bored in class I don’t want them to know I’m researching hacking sites.

To solve this I setup a Linux box on my network and point port 22 to it. 22 is the default SSH port in case you didn’t know. Then I create a secure tunnel from my laptop to my home box (my laptop also running Linux).

SSH -D 1080 username@ip

This creates what is essentially a SOCKS v5 proxy on port 1080. Anything and everything you do remotely can be routed through 1080 (any port works, I just like that number).

Now I don’t know how to setup my Linux machine so that I don’t need to configure every program I use to work with the proxy and currently have to setup everything manually. Here is how to do it with FireFox.

Open FireFox, goto Edit –> Preferences –> Advanced –> Network –> Connection –> Settings

Click “Manual proxy configuration:”, then under SOCKS Host put “localhost” port “1080” and make sure that SOCKS v5 is clicked.
Where it says “No Proxy For” you can leave localhost in, I’m not really sure, never tried. I just cleared it out and everything went smoothly.

Close the window and start surfing!

As long as you keep the SSH connection alive this will work. If you SSH connection does die you will know right away when you can’t surf. You will also need to revert your connection settings back when you are no longer using the SSH proxy. Also keep in mind that even tho you are routing via an encrypted tunnel to your remote machine, traffic will still be unencrypted after that point. Surfing may take longer than you would like. This is due to the fact that ALL traffic will be routed first to your remote machine then to you via the tunnel.

Lastly, I’m told that not every SSHd configuration allows SSH proxies. Mine does. I’m not sure why, I haven’t bothered to look into that yet. You may need to check your /etc/sshd_config file as there may be an option there. If you need help you know where to ask for it. Enjoy!

Here are my instructions on how to get VNC in KDE 3.5+ working through an SSH tunnel. It’s easier than you might think.

To start all you need is 2 or 3 Linux machines with OpenSSH installed. Most distros come with it (although I know Ubuntu does not).
NOTE: All my machines run Slackware 12.0 or higher.

Step 1 – Setup the host.
This is fairly simple, open up you Control Center, and find Desktop Sharing. Just look at my picture below and see the settings I would recommend for this.

Just make sure you set a STRONG password!

Now comes the fun part. Creating the SSH tunnel. By default the VNC connection is on port 5900.
For this example you have 2 computers. Your at a coffee shop with free wifi but your smarter than everyone else, so your going to use encryption to your home desktop and surf the internet from there.
Your home computer (lets say) has a domain name. For my examples it will be daijoubu.net, and your internal computer is 192.168.1.2.
Make sure you set your router to forward port 22 (the SSH default) to 192.168.1.2
Open up a terminal (some times it’s called Konsole) and type:

ssh dkun@daijoubu.net -L 5931:localhost:5900

The user name I’m using is dkun, just put in your user name
You will be prompted for your password, after entered you have formed the SSH connection. What this command does is it takes all traffic from your desktop port 5900, and forwards it to your laptop (at the coffee shop) to localhost port 5915.
Seems complicated, but trust me, it works!
Now open up Krcd and type

vnc:/localhost:5915

Just as shown below.

If you have 3 computers. For example, you don’t forward to your desktop (for security reasons) but you do forward to a file server. Lets say your file server is 192.168.1.3 and your desktop if 192.168.1.2 type:

ssh dkun@daijoubu.net -L 5915:192.168.1.2:5900

This will form the SSH tunnel to your server (192.168.1.3) then forward port 5915 from 192.168.1.2 through the SSH tunnel back to you.
Reminder: Doing it this was results in plain text from 192.168.1.3 to 192.168.1.2. This is only a problem if you don’t trust your internal network!

From here is gets simple, after you click Connect you will be prompted for the following window.

These are the settings I recommend for over the Internet, VNC can take a lot of bandwidth.
Next you will get a password prompt, type in your password and hit OK

Your remote desktop will appear! if you look quickly you will see this at the bottom right of the screen

That’s it! Now you can use your remote desktop over a secure connection!

WARNINGS! If you attempt a connection without the SSH tunnel your passwords will be sent in plain text! That is BAD!
DO NOT FORWARD PORT 5900 ON YOUR ROUTER!

Extra Notes: If you do not have a domain name to work off of, you can put in an IP address after the username@, make sure it’s an internet IP address, 192.168.1.2 will NOT work
If you don’t have a static IP address you can use dyndns to get you one. They are really good, but if your IP changes you will have to update your opendns account. I would recommend checking before you head out.

Special Thanks to Spyder_3lite of UCoD.com. If it weren’t for you showing me something way cool with SSH, I never would have been able to do this.

Note: This was originally written on my other site Daijoubu.net. I have moved it here for better indexing from Google. ^_^