Zero_Dogg

• Home
• Me
• Projects
• Technical notes
• Docs
• Norwegian content

• English
• SSH tips and tricks
• 
  Norwegian
• Notes Helse & Sosialfag GK
• Notes Hjelpepleiar VK1
• Notes Hjelpepleiar VK2

Index

Tip 1: Don't use telnet! Use ssh

Telnet is old, deprecated and very insecure. Use SSH instead; besides, if you're not using ssh then why are you reading this? :o

Back to the top

Tip 2: Use passworded ssh keys and ssh-agent

SSH keys are what the name implies. They are keys; they allow you to "unlock" a ssh session without typing a password. Sounds quite insecure right? It can be, having passwordless ssh keys isn't the smartest thing you can do. If your key then is stolen, then anyone can connect to your servers. Then again, what good is the key when you have to type a password anyway? That's where ssh-agent comes in. The ssh-agent sits in the background, it prompts you for the password for your key once per session, then remembers it. This means that you can have a securely locked key, while still enjoying the allmighty lazyness unix is so good at giving you by allowing passwordless use of ssh.

SSH keys

Let's start doing this. First, create a ssh key (WITH a password). Accept the default path to save the key to, and enter password when prompted.

[zerodogg@drizzt ~]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/zerodogg/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/zerodogg/.ssh/id_dsa.
Your public key has been saved in /home/zerodogg/.ssh/id_dsa.pub.
The key fingerprint is:
16:53:66:fa:b5:d3:6d:a5:9f:a9:84:73:df:48:55:0e zerodogg@drizzt
[zerodogg@drizzt ~]$

Good, now you've got a ssh key, of the type dsa with a password. Ssh-keygen will have created two files for you and placed them in ~/.ssh/. One named id_dsa and one named id_dsa.pub.

id_dsa is your "private" key. This is the key itself, you don't share it with anyone.
id_dsa.pub is your "public" key. This is the lock, you place it inside ~/.ssh/authorized_keys on all servers you want to use the ssh key on (explained later).

Now that you've created the key you need to deploy it to your servers. This is a simple thing, replace example.org with the hostname of the computer you want to put the key on.

[zerodogg@drizzt ~]$ cat ~/.ssh/id_dsa.pub | ssh example.org "cat >> ~/.ssh/authorized_keys"
[zerodogg@drizzt ~]$ 
# Or, if you're using Mandriva it's even easier:
[zerodogg@drizzt ~]$ ssh-copy-id -i ~/.ssh/id_dsa.pub example.org
[zerodogg@drizzt ~]$

That's it, the key is now on the server. Do this for each server you want to use the key on.

SSH agent

Now we get to the good part, ssh-agent. It's yet another gift from unix to lazyness. There's two main ways to use it, I'll explain both, beginning with vanilla ssh-agent.

What ssh-agent does is sit in the background, waiting for you to connect to a ssh server. Then, on the first connect to a server using the key it will prompt you for the key password. The next time you connect to a computer using that key you'll be let through without questions, provided ssh-agent is still running (you need to enter the password once for each ssh-agent session).

However, you first need to launch ssh-agent, how you do this is how the two methods differ. Using vanilla ssh-agent you would do something like this:

eval `ssh-agent -s`

Doesn't say much huh? Where to place it? What to do? Help!
You place this in a file that is launched before your terminals are, for example in ~/.xinitrc.
Then after you have logged in, type ssh-add. It will then prompt you for your key password, and after that you can ssh passwordless.

Now, you can make it even easier(!) by using keychain. Keychain (installed seperately) launches ssh-agent for you. It sits in /etc/profile.d, and when you for instance log into X, it is started - and runs ssh-add for you, which in turn prompts you for your password (if in X it pops up a graphical password prompt). When you've entered the password it gets out of your way and makes sure ssh is aware that ssh-agent is running so that it uses it. Honestly it doesn't really get more lazier.

[zerodogg@drizzt ~]$ ssh example.org
Last login: Mon Dec 19 10:15:20 2005 from drizzt
[zerodogg@example ~]$

If you want to use the ssh agent through other ssh connections (ie. connecting to example.com when logged in to example.org) you can add this to ~/.ssh/config:

Host *
ForwardAgent yes

Tip 3: Use ssh proxying to bypass firewalls

At school or work and behind a restrictive firewall? If it allows you to connect to the outside (see tip 4 if you're having problems using ssh through the firewall) using ssh you can bypass all of those restrictions alltogether. Ssh allows you to forward data through it, it basically acts as a proxy, tunneling the data through to the ssh server and from there on out on the internet (same back ofcourse).
First, we open up the tunnel - like this:

[zerodogg@drizzt ~]$ ssh -D 9000 example.org
Last login: Mon Dec 19 10:15:20 2005 from drizzt
[zerodogg@example ~]$

This starts the tunnel on port 9000, ofcourse, it leaves you with a terminal open that you might not use, so you might want to tell ssh to just go into the background like a daemon:

[zerodogg@drizzt ~]$ ssh -D 9000 -f -N example.org
[zerodogg@drizzt ~]$ 

Okay, you've got the tunnel up. Now you need to tell the programs to use it. SSH supports SOCKS4 and SOCKS5 and acts as a SOCKS server. Go to the proxy preferences in your program and tell it to use localhost port 9000 as proxy server using either SOCKS4 or SOCKS5. For instance, in thunderbird 1.0 this is done by:
Edit -> Preferences -> Advanced -> Offline and connection settings -> Connection settings -> Manual proxy configuration
By doing that in thunderbird you can now fetch your mail fine, also, if you do the same with a webbrowser you will bypass those pesky corporate filters. See your applications documentation for more information on how to tell it to use a proxy.

Tip 4: Use ssh through port filtering firewalls

Does the firewall filter ports? Well, you can bypass that too - however, this assumes you have root access on the server, and that the server doesn't need to be running a http daemon.
On the ssh server you simply make the daemon listen on port 80 (aswell as port 22 if you want to).

[zerodogg@example ~]$ su
Password: 
[root@example ~]# $EDITOR /etc/ssh/sshd_config
# ... change:
Port 22
# ... to:
Port 80
# ... or
Port 80
Port 22
[root@example ~]# /etc/init.d/sshd restart
Stopping sshd:                                                 [  OK  ]
Starting sshd:                                                 [  OK  ]
[root@example ~]# exit
[zerodogg@example ~]$ 

Okay, now the ssh daemon is listening on port 80 too (make firewall changes on the server side as needed). Now you can simply do:

[zerodogg@drizzt ~]$ ssh -p 80 example.org
Last login: Mon Dec 19 10:15:20 2005 from drizzt
[zerodogg@example ~]$

To allow yourself to be even lazier add this to ~/.ssh/config:

Host example.org
Port 80

It makes ssh remember to always connect to port 80 when connecting to example.org

Tip 5: Use a reversed ssh session to make your local ssh daemon available through a firewall

Sometimes you want people to be able to connect to your computer using ssh, but you're behind a firewall that you don't have control over. No problem, ssh can do that too. Ssh connects to the remote machine as usual then binds a port on the remote machine where it allows incoming connections. So effectively connecting to that port on the remote machine leads to your machine.

# Create the tunnel
[zerodogg@drizzt ~]$ ssh -R 8000:localhost:22 -f -N example.org
[zerodogg@drizzt ~]$ 
[zerodogg@drizzt ~]$ ssh example.org
Last login: Mon Dec 19 10:15:20 2005 from drizzt
[zerodogg@example ~]$
# Test the tunnel
[zerodogg@example ~]$ ssh -p 8000 localhost
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
zerodogg@localhost's password:
Last login: Mon Dec 19 09:46:10 2005
# Hurray, works.
[zerodogg@drizzt ~]$

You can ofcourse do this with other services aswell by changing 22 to some other port.

Tip 6: Use hostname and username aliases in ~/.ssh/config

You can do alot of magic that allows you to type even less(!) by using ~/.ssh/config.

Different usernames on different computers

Sometimes you've got other usernames on various computers. This is easily solved by adding a few lines to ~/.ssh/config:

Host example.com
User eskild
Host *.sf.net *.sourceforge.net
User zero_dogg

Using shorter hostnames

Don't want to type example.org every time you're connecting to it? Just want to type example?

Host example
Hostname example.org
Host home
Hostname home.dyndns.example.org
Host sf
Hostname shell.sf.net
User zero_dogg

Tip 7: Connecting to machines behind another machine using ProxyCommand

In some cases you've got machines not avalable directly on the internet, but they are available on the LAN behind another computer. You might want to connect directly to those machines instead of having to manually go through the one computer that is listening on a port available to the internet. SSH solves this for you by providing you with ProxyCommand. To directly ssh to backup.example.org by proxying through example.org you would add this to ~/.ssh/config:

Host backup backup.example.org
ForwardAgent yes
ProxyCommand ssh -qax example.org /usr/bin/nc %h %p

This ofcourse assumes netcat is installed on the remote host and available as /usr/bin/nc. After adding this you can happily ssh to backup.example.org without having to bother with going manually through example.org:

[zerodogg@drizzt ~]$ ssh backup
Last login: Mon Dec 19 10:15:20 2005 from example.org
[zerodogg@backup ~]$

Tip 8: Limiting access to a ssh daemon using AllowUsers

This tip requires root access on the server computer. Have user accounts on your machine that you don't want to be able to ssh in? No problem there. Simply add this to /etc/ssh/sshd_config (your path may vary).

AllowUsers user1 user2

Then restart the ssh daemon (/etc/init.d/sshd restart). Now only the users you specified will have access to log in using ssh.

Tip 9: Using vnc securely with the help of ssh

I use a script to connect securely with vnc. I'll show you the script and explain it afterwards

#!/bin/bash
ssh -f -L 5901:localhost:5901 example sleep 10
vncviewer -compresslevel 9 -encodings "tight zlib" :1

The first part is the shebang. Then comes the ssh command. Here you would replace example with the hostname you want to connect to (or use a fancier script like I show later). Then comes the vncviewer command. Now this script is rather stupid ofcourse, and assumes a few things. Here is a smarter variant of the above:

#!/bin/bash
ssh -f -L 5901:localhost:5901 $1 sleep 10
vncviewer -compresslevel 9 -encodings "tight zlib" $2

This one takes two parameters, the first one the host to connect to, the second the display. Naturally the compresslevel and encodings may be changed to whatever fits you - I use this script when connecting through the internet so then I like some compression. Here is how I would use the script:

[zerodogg@drizzt ~]$ vncwrapper example.org :2
# ... connects :)

There you go, place the script in your PATH, for instance ~/bin and chmod +x it and off you go.

Copyright © Eskild Hustvedt 2005, 2006, 2007, 2008, 2009, 2010
Copying allowed under the terms of the Creative Commons Attribution-ShareAlike 2.5 License.