(This article is a draft and work in progress. Expect changes in the next couple of hours. This note will be removed when the article is finished, however, I’ll send updates every now and then for online-review by friends. Comments by anyone are welcome. Please use the comment-function.)
Time for a more technical posting. In my work as an IT guy I realised quite a few times that advanced knowledge about ssh and how it’s working almost non-existant. People are still stuck the the good old “ssh user@host” and plaintext-authentication scheme they still know from rlogin and telnet. Time to clean up and show the people what ssh – especially OpenSSH and putty – can do. I know that there’re plenty of howto but they seem to be obscure for the general user-audience. So I give another try. Let’s go.
(Note: Other implementations of ssh besides OpenSSH and Putty – like F-Secure’s ssh-server for UNIX – are not covered here. Key-conversion can be a mess or at least it used to be when I was last using it on Solaris.)
0. Introduction
0.1 What’s this all about?
You might only know the usual ssh-stuff; means “ssh -l user remotehost” or probably “ssh user@remotehost“, which is equivalent. When it asks for a password you’d enter the password of the user “user” on the machine “remotehost“. You probably also heard of things like “public keys”, “tunnels”, “port forwarding”, “X forwarding” but you never got a hang on it. In this article I’m going to cover exactly those topics.
0.2 How’s this article organised?
In the first chapter I’m going to lose a couple of words about public-key encryption in general and how this applies to ssh. In the second chapter I’ll head over to tunnels and portforwarding. Although X-forwarding is basically the same, I’m going to put that in the third chapter. The fourth chapter will deal with the ssh-agent and finally, in the last chapter, I’m going to give some configuration hints of the ssh-demon.
1. Public keys, ssh and all the other crap
1.1 Why is the traditional authentication scheme spoiled?
Authentication? What means that? It means that the system you’re about to log on recognises – authenticates – you. In UNIX-system that means you have to give a username which exists in /etc/passwd, and a password which is stored – encrypted – in the file /etc/shadow.
The traditional username/password scheme has – in my opinion – three practical major disadvantages: If lots of people need to acces the same account – let’s say, “oracle“, “superad“, “informix” or “tsp99” – a lot of people need to be aware of the password-of-the-day. That’s, speaking of security, a bad idea. (1) Because a lot of people log on using that password the adminstrator of the system might be tempted to choose an easy password which is not so hard to remember. (2) Which leads to the second problem, that the password might be easy to guess. (3) The third problem arises: How do you tell someone the password on a safe channel? Phone conversations and unencrypted internet-communication is easy to tap.
How can we do this better? There’s an answer. Public key authentication.
1.2 Public key authentication
Public-what-the-heck you might think.What you probably know about encryption is “hey, I got this encryption-thing, if I want to encrypt something I give a secret password, give this password to my buddy so that he can decrypt it”. Fine. Problem (1) solved. Problem (2) can be solved with a complicated password. But problem (3) still exist: how to you tell your friend the secret password? You better do that in person, rather than on the phone.
So a couple of clever scientists invented the so called “Public Key Encryption Scheme“, also known as “Assymetric Encryption“. What does that mean? Example:
Alice and Bob, the famous protagonists in cryptography, both create two files on their computers. One file is called the private key, the other one is called the public key. If Alice and Bob want to communicate in private, encrypted, they exchange their public keys. So Alice gets Bob’s public key and Bob gets Alice’c public key. Alice and Bob keep their secret key – well secret. They never give them away. Never ever. Secret. You see?
Now comes the important point: Public Keys only encrypt. Secret Keys only decrypt. The consequence? If Alice wants to write an encrypted email to Bob, she takes her message to Bob and uses Bob’s public key to encrypt the message. She sends that encrypted message to Bob. Bob takes his Private Key and can decrypt Alice’s message. Bob’s secret key and public key form a keypair. Both keys are one-way-keys, designed to do that specific purpose.
So why are those keys files and not passwords you want to ask? There’s no need for a password. Since the public keys can nothing do but encrypt, Alice can upload her public key to some website (also known as keyserver in the GPG-world) so that anyone who wants to send her an encrypted email can just use that key. Only Alice, with her secret key, can decrypt the message. As an extra precaution Alice’s secret key is encrypted with a traditional symmetric-encryption-scheme using a passphrase she choses, so that if someone steals her private key from her computer can’t use it.
Fancy, don’t you think?
1.3 Public Keys and OpenSSH
So how does this all apply to ssh? Easy. Ssh can, additionally to the traditional UNIX-password, also make use of the Public Key Encryption. But it doesn’t really use that scheme for encryption, but rather for authentication!
How? Quite easy. Imagine you’re working for the TAC (technical assistance centre) of some big company and you want to access a customer’s oracle server. You’d need access to the user “oracle” and “root” in that case. The customer would be rather stupid to give you the passwords over the phone or via email for obvious reasons.
So, what do you do? Let’s say Alice works for GreatInnovations Ltd. and does service for Bob’s ScrewedCompany AG’s Oracle database. She needs access to the user “oracle”. Alice now creates a keypair on her laptop – a secret and a private key. Alice keeps the secret key on her laptop and sends the public key to ScrewedCompany AG.
In openssh (Alice’s computer is called “castor”):
Create a “DSA”-keypair and choses a passphrase:
alice@castor:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/alice/.ssh/id_dsa): <enter>
Enter passphrase (empty for no passphrase): blabla123
Enter same passphrase again: blabla123
Your identification has been saved in /home/alice/.ssh/id_dsa.
Your public key has been saved in /home/alice/.ssh/id_dsa.pub.
The key fingerprint is:
9e:36:f0:fd:9e:10:3d:00:b9:69:56:36:4c:20:da:e9 alice@castor
alice@castor:~$
Ok, now Alice created a keypair. Alice also notes down the fingerprint of her keypair. The fingerprint is unique to every keypair and Bob needs it to verify that the key Alice will send him is the correct key.
What files do we have by now? Let’s change to the directory ~alice/.ssh and check what’s there:
alice@castor:~$ cd .ssh
alice@castor:~/.ssh$ ls
id_dsa id_dsa.pub
alice@castor:~/.ssh$
So, we have two files. The file named id_dsa ist Alice’s secret key – protected by the passphrase blabla123 – and the public key named id_dsa.pub. How do those keys look like? Let’s have a look at those keys:
alice@castor:~/.ssh$ cat id_dsa
-----BEGIN DSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,B5EE64D31AC8CE4F
NQU9YWg2DKX8rToZ/TtaeEphGxADpVPxUQhnl9sFmDSZlne0dE1Mp7+S+xny9YjU
GiWaFIQLCFkdquc5uTigNoPrmZse8NG2djbtu8+rU7Vi3jYK8YvK7mROgUQSaJ2u
++TqlfHfW9zk2by2sbjpHPgMHQSud2ANIFVqGRYvUDJq8fTEB0AqodOsv5phl5WV
9s4dx6CrRvoinoiFfTwaI8F7gYQbJ9YvVcaMGxEEjmqwQQm5LCLRD3xOmNKefC03
REodEUcwnrvD+R2RE9ldHk28eh9/4CJHOTB1GWHez6NfbrjlZJACDXO5UjSqdPXn
hM/i8o+I7WOQ4iMSH8L0Zdyg4EATlXIc0rO3xIpTdFBNaG3V1A4ZnuL5HTGv68I6
74GtQntQwjQVCUOCvxBC0PQN+esC9rwJ6Fj/JSj+50TIkdV4worxUa3NjRg4AKwU
y37B0m/dWGHNnhr4G79TmUYlujriCfMdZ9zjizNae8pZyi696xvpDpRHoHIWsusR
nUmwLNDv50DcN2BukFrGShJ2tfcwYCB63ytgd9arEwd1grpEiFGLVM2YN8XpO/py
aVLiNcV9z+9eFRLuEwX4mw==
-----END DSA PRIVATE KEY-----
alice@castor:~/.ssh$ cat id_dsa.pub
ssh-dss AAAAB3NzaC1kc3MAAACBAIECqUDgpN/nvhAyS+5LftVt5Oa1U+I2tHeeYlq6rjl8dNDX8gkr
SsjHmJCnO5QwGUwW/Y6egfYW8HlKpDSHUciJyW6IyiriuTwvEmOTv42RP6+6IeJ1sIVcFhihCcDQ7QEX
7+aY44SgHD9k9nu+SDWkDV/gHStlXmh+Fx02zUYlAAAAFQDCY2xbkBj6H8eMeHusrI1hh68AWwAAAIBB
WHUqWdlHWFqN1eYDlJ7/VPl4EvprxgKV+BHslYCmlEtKY2JDYlQTmYP39Sy4J5XKlJyuGDPtalrDAFjJ
VrqezbkzZMP9jUIaa8GGSi4l4Lf5xbNijTQObbqn3f+PJf2CzTtrQrmm0dzPV/KQ0VxXq0VQd4wNTDp4
nPLmOwV57QAAAIB5OKAt+KtU8wiUJN5h6JcWFcO0LcBxXjyIHip/bvNlIhciwmpMbWmWHB3xtmJCV/ul
aGeKpH5U6mzh1E9grn7+x6aRPQcyZfyGs7MjqmsjvAtOGTsD0QPpzApYB0x1DMUz68fQarmiqvMVLEAa
Enu385aLE+0CeWMTrtbtzVLIaQ== alice@castor
alice@castor:~/.ssh$
You see, the keys are a lot of gibberish, but actually nothing Alice and Bob have to worry about.
Alice now sends the file id_dsa.pub – her public key – to her customer Bob, working for ScrewedCompany AG.
Now suppose the customer’s Oracle-server is called neelix and Alice should get access to the user oracle on this machine. The customer therefore logs into neelix as user oracle and copies Alice’s public key for the user oracle to ~oracle/.
Just assume the key was copied to the machine by some means (scp, copy&paste, never mind). Suppose Bob stored Alice’s public key under the name of “id_dsa.pub-alice“. The first thing Bob from ScrewedCompany AG has to do is verifying the fingerprint of Alice’s public key:
oracle@neelix:~$ ssh-keygen -l -f id_dsa.pub-alice
1024 9e:36:f0:fd:9e:10:3d:00:b9:69:56:36:4c:20:da:e9 id_dsa.pub-alice
Bob now compares all the number to what Alice told him what her fingerprint is. Note: Alice shouldn’t tell Bob the fingerprint in the same email as in the one she sent her public-key! Why? Because if someone pretended to be Alice he could send Bob his own, but false, public key – and if the fingerprint would be included, it would surely match! So Alice gives Bob a call and tells here the numbers.
Now that we know that Alice’s key Bob got is the same key Alice really sent, Bob can install Alice’s key so that she can work as user oracle on host neelix.
oracle@neelix:~$ mkdir .ssh
oracle@neelix:~$ chmod 700 .ssh
oracle@neelix:~$ cat id_dsa.pub-alice >> .ssh/authorized_keys
(Note: The mkdir and chmod are only necessary if a directory .ssh didn’t yet exists. I assume it doesn’t since you’re reading this so this might be your first time)
Bob now installed Alice’s public key to the user oracle on the host neelix.
What now? Nothing! That’s it. Alice can now login to neelix as user oracle without actually knowing the password of user oracle; she only needs to know the passphrase of the secret key belonging to the public key Bob installed. Suppose Alice is logged in on machine castor as user alice and wants to log on as user oracle on host neelix:
alice@castor:~$ ssh oracle@neelix
The authenticity of host 'neelix (2001:5c0:8bf4::1)' can't be established.
RSA key fingerprint is 6d:50:18:85:f7:da:68:73:74:18:0b:9c:f9:e3:32:45.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'neelix,2001:5c0:8bf4::1' (RSA) to the list of known hosts.
Enter passphrase for key '/home/alice/.ssh/id_dsa': blabla123
Linux neelix 2.6.8-3-686-smp #1 SMP Thu Sep 7 04:39:15 UTC 2006 i686 GNU/Linux
oracle@neelix:~$
The question “The authenticity of host 'neelix (2001:5c0:8bf4::1)' can't be established.” occurs only the first time a user connects to a certain host. You probably know that. Type “yes” to acknowledge the fact.
Then the host asks for the passphrase. Important: This is the passphrase Alice gave when she created the keypair. This is not the UNIX-password of the user oracle on the host neelix! Don’t forget that! If you just thought “what the hell?” please reread the chapter, you fundamently got it wrong.
Voila! That’s it. No magic. No bells, no whistles.
Summary:
- Alice creates a keypair and sends her public key to Bob:
"ssh-keygen -t dsa"
- Bob verifies the fingerprint of Alice’s public key:
"ssh-keygen -f id_dsa.pub-alice -l"
- Bob installs the public key of Alice to the file ~oracle/.ssh/authorized_keys by just appending it
Using public key isn’t diffucult. It is easy, although more work than telling someone a password on the phone. But you gain so much additional security that it’s worth it! Both in private and corporate environments.
Useful hint: Did you know…?
That there’s a clever little program called ssh-copy-id which automates the process of setting up the file authorized_keys on the remote host? Suppose the user root on host neelix has a copy of Alice’s public-key, knows the password of user oracle and wants to install it to the user oracle. Example:
neelix:~# ssh-copy-id -i id_dsa.pub-alice oracle@neelix
10
Password: <UNIX password for user oracle>
Now try logging into the machine, with "ssh 'oracle@neelix'", and check in:
.ssh/authorized_keys
to make sure we haven't added extra keys that you weren't expecting.
neelix:~#
Alice know can log into oracle’s account on neelix. Additional node: ssh-copy-id works from everywhere on the network and can be used for both, plaintext (password) and public-key authentication.
What might go wrong:
You should be aware of a few things, things might might go wrong. If you look at a public key you might notice – or not – that the complete key in the file id_dsa.pub is all in one single line of text. If you copy&paste the key to the authorized_keys files make sure that you don’t introduce linefeeds or carriage-returns accidently. This will screw up the whole authorized_keys file. F-Secure’s ssh-client implementation for Windows is notoriously infamous for adding CR/LFs automagically.
1.4 Creating and using public-keys with putty for Windows
We now know how to create, install and use ssh-keys in UNIX-environments using OpenSSH. Time to explain how a Windows-client can create and use key-pairs.
Putty is a well known, stable and popular free ssh-client implemtation for Windows-systems. Putty can look back on to a long and successful history. From all the people I know who run Windows and use ssh, Putty is their ssh-client of choice. Putty is pretty lightweight, with a small memory-footprint and just easy to use; it also has a lot of very interesting and easy to use features, like tunneling ssh through http-proxies and an easy way to setup tunnels and portforwarding.
In this part of the article I’m going to use the programs putty and puttgen. They both can be downloaded for free from the Putty-website.
1.5 Generating key-pairs with puttgen
We start with firing up the program puttygen. The start-screen looks like that:
Now Alice wants to create a new keypair. Alice want’s a DSA-key with the size of 1024 bit – a sensible default, but not the default of Putty, it still uses RSA-keys as the default. In the parameter-section Alice checks the button “SSH-2 DSA” and presses the button “Generate”. A new screen appears asking Alice to wiggle around her mousebutton aboce the windows. Puttgen uses the mouse-movements to get some random data – that’s better than the pseudo-random-number generator Windows uses:
After wiggleing the mouse around for a couple of times, the key is generated, resulting in that screen:
What next? First: Alice has to write down the fingerprint of her key for future reference. Now she has to give her passphrase – we stick with blabla123 – she enters it into the fields “Key passphrase” and “Confirm passphrase”. Next she has to save both, the public-key and private-key, to some location on her harddrive, pressing the buttons “Save public key” and “Save private key” accordingly – chose a location which is safe – means only Alice can access it – and not to some network-share or into a directory which everyone on the system can access. “My Documents” might be a good place.
Now comes the “ugly” part; not really ugly, but not self-explaining either. Putty uses, for the public-keys it generates, a different format then the one OpenSSH on the server would expect (means: the key is not in one line of text, as I alredy pointed out in the last chapter). That’s why the public-key is displayed on the screen, luckily denoted with the text “Public key for pasting into OpenSSH authorized_key file“. So, do it – mark all the text in that textarea, copy it, open Notepad, make sure “Format -> Word Wrap” is disabled , paste it, do not attempt to modify anything of the text and save it to a file. This is the public-key Alice has to send to Bob, not anything else.
It’s a bit dodgy, but it works – if you know that you need to do it exactly that way.
Note: “Conversions -> Export OpenSSH key” exports the private-key to OpenSSH-format, not the public-key. The public-key has to be saved manually by the methode described above. This command is useful if Alice wants to use the same key-pair also on her UNIX-workstation, if she prefers not to have different keys.
1.6 Using ssh key-pairs with putty
I assume you’ve worked with putty before. So fire up Putty, load or create the data for the connection to oracle@neelix and head straigt to the menu “Connection -> SSH -> auth”. There you see, in the group “Authentication parameters”, the textbox “Private key file for authentication”. Hit “Browse” and chose the private-key (the one with the suffix .ppk) you’ve created earlier with Puttygen:
Then just press “Open” or go back to the main-menu to save the configuration first. First putty will ask you for the username, say “oracle”, but then – instead of asking for a password – it asks you for a passphrase. Enter the passphrase you gave earlier when creating the key, Voila:
So much for how to use putty and public-key authentication. It’s not complicated at all.
2. Tunneling
What’s tunneling? Technically speaking it means to forward remote ports to local ports, or local port to forward to remote ports.
What does that mean in plain english? Imagine Alice has a mysql-database running on castor. She uses it as her internal-troubleticket-system for her company GreatInnovations Ltd. – obvisioully she’s not goint o give anyone direct access to her database via direct socket-connects to the database-server – her server only listens to localhot – means 127.0.0.1. Good for her! A security-lesson was learned.
Now Alice is working in the datacenter of ScrewedCompany AG, doing some emergency-work on the customer’s system. She sitting in front of the cluster-console of her customer’s productive system but now realizes that she needs to query her database. What possibilities does she have? The easiest way would be to login to her database-server via ssh, fire up “mysql” and enter here queries. But what a lame example would that make, we were about to talk about tunnels, weren’t we? :) So Alice instead wants to use the local mysql-program on the customer’s server, directly connecting to the database in GreatInnovations Ltd.’s datacenter. But for security-reasons the server doesn’t listen on it’s public IP-address, as I already pointed out earlier.
So Alice needs to find a way to somehow get a connection from the customer’s machine to her database serverwithout compromising security. There’s a way. A simple way using ssh.
2.1 Getting remote services to your local machine
(tbd)
2.2 Getting local services to a remote machine
(tbd)
2.3 Combinations of all above
(tbd)
This work is licensed under a
Creative Commons Attribution 2.5 License.
Did you know that the tool OpenSSL which is shipped with the OpenSSL-distribution can do more than just create certificates of all kind for your webserver? It can also do other fancy stuff like calculating MD5-checksum or other digests. You can use it as a tool for encrypting or decrypting files. It can deal with encrypted S/MIME-emails or as a simple SSL-enabled TCP-client. And server!
Posted by Alexander W. Janssen 
Posted by Alexander W. Janssen 
A couple of people onthe freenode.net IRC-network asked today the same question: How to get access to freenode using TOR
Posted by Alexander W. Janssen 
I had a couple of discussions in the last weeks with various people about anonymity and privacy on the internet. Since 
