(This article is outdated. It’s only preserved because I don’t like deleting old postings. Do not rely on this information any more and, especially if you’re using Tor, use the Tor Browser Bundle instead of brewing your own weird connections. It’s usually not needed any longer, especially in heavily censored environments. Use bridges instead. Comments are closed. -aja)
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.

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:

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:

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:

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.

(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:

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 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:

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.

My logfiles are totally full of logged connection-attempts to my servers. It looks like people are trying to exploit the ssh-vulnerability which became known some days ago (“openssh denial of service CVE-2006-4924“).

I got SSH protocol version 1 disabled by default, so this ain’t no real threat to me, but the scale of this attacks causes a DOS on my servers; the sshd is that busy that I, as a legetimate user, fail to log in any now and then:

“As a result of the current problems being experienced by the Apple and Dell Corporations with some of the batteries fitted to some of their laptops, as a safety precaution and with immediate effect, customers wanting to use an Apple or Dell laptop on board can only do so if the battery is removed. Any removed or spare batteries must be individually wrapped/protected and placed in your Carry On Baggage. This is limited to two batteries per passenger.

In cabins where the seats are fitted with In Seat Power Supplies, leads/adapters will be offered. Where no ISPS is provided or no laptop leads/adapters are available, the use of Apple and Dell laptops is prohibited.

Virgin is in communication with Apple and Dell. As soon as this safety issue is resolved these restrictions will be lifted.”

Oh my,first the terrorists now Apple and Dell. What’s next? urine-samples before boarding the plane? You could’ve drunk those evil liquid explosives!

Adobe releases a new version of their Flashplayer to plug a security-hole. This one is quite critical, a manipulated SWF-file can execute arbitrary code on the victim’s machine. Priviledge escaltion was not mentioned, but it’s bad enough. Apparently all platforms are affected.

The good news: There’s also an upgrade for the Linux- and Solaris-version available. Although still in their stinky old version. And fellow blogger Emmy Huang from Macromedia/Adobe still has to fulfill their promise to release a new Linux-version of the Flash-player… But releasing security-updates is a sign that they didn’t forget about us. Wonderful! :-)

Normally i wouldn’t blog about this, but my wife seems to be addicted to flashy games, especially the stuff at Neopets. I must admit that i couldn’t resist the urge to get an account there as well… ;)

“Last week, a few Tor exit-node servers were seized by the German police in a massive sting against child pornography. From our friends on the ground in Germany, we hear that dozens and dozens of machines may have been seized. So far as we know only six of those were Tor servers. We have heard from the server operators. None of them has been charged.

This is not a “crackdown” on Tor, as has been widely reported. We expect and hope that the volunteer Tor server operators in Germany will get their equipment back after this has blown over, and there will be no action against Tor.”

I have nothing to add here and I’d like to point out that we all should calm down a bit and to repeat what I said in my initial posting:

“Those servers were most probably configured to be TOR Exit-Nodes, so their IP-addresses might have shown up in the server logfiles of the child-porn servers in question.
[…]
I guess that the attorney of state is just after logfiles, they knew that those servers were operating as TOR-nodes. If you IP-address pops up in a child-porn case surely your IP looks interesting to the police.”

Maybe my words weren’t clear enough, maybe I underestimated the momentum of this news, and I probably didn’t take into account that lot’s of people didn’t actually read my posting completely and just picked up the news which seemed to be relevant to them. Also some people definitively interpolated those crippled news to justify their prejudices against Germany (“Nazis“), the police (“they’re after us!“), and the TOR-project (“They’re supporting child-porn and probably terrorists!“).

And clearly i made the assumption on Boing Boing where i said “Apparently it’s about the proliferation of child pornography, although no charges have been pressed against TOR operators yet.” I shouldn’t have written that.
So let me put it in other words, restating what i posted as a comment earlier:

The seized TOR-servers were most probably TOR exit-nodes.

Their IP-addresses most probably showed up in the logfiles of the alleged child-porn server.

The police found out about that IP-address and the police must take action and seize the server.

The fact that the server was running TOR is of no actual value for the process of forensics itself.

So there’s no actual evidence at the moment which proves that this is a direct attack on the TOR-network or it’s operators in Germany.

We still don’t know if any charges are pressed against operators. Basically we’re all speculating, so please, let’s keep calm until we really know more. If i find out more, I’ll post updates here.

I learned from all the feedback I got in comments and trackbacks that there’re actually people in China and other countries in the world specifically asking not to shutdown our nodes. They said that TOR is one of their very little possibilities to get a decent internet connection at all. Considering that other websites like Wikipedia are banned in those countries we should make it our responsibility to give people from oppressive states the support they need – free communication.

Famous last words: My TOR-server is still running, pushing 40GB/day around. I’m not going to shut it down for whatever reason. I ask all other TOR-operators in Germany to do the same. There’s no sign that we’re going to be sued for whatever reason at the moment.

The public prosecutor’s office of Konstanz raided computing centres of seven providers in Germany, seizing ten servers because of the proliferation of child pornography. Nothing new, things like that happen all the time, the juicy detail is that some of the servers were merely running a copy of the TOR, a software to anonymize the usage of the internet to protect your privacy.

Those servers were most probably configured to be TOR Exit-Nodes, so their IP-addresses might have shown up in the server logfiles of the child-porn servers in question. One could argue that this is an attempt to frigthen german TOR-node operators, but I’d just keep calm for the moment. I guess that the attorney of state is just after logfiles, they knew that those servers were operating as TOR-nodes. If you IP-address pops up in a child-porn case surely your IP looks interesting to the police.

However, this situation is disturbing, really disturbing. I run a TOR-server myself (wormhole.ynfonatic.de) and the last thing I want to experience is the police kicking down my door, seizing my computer. (despite the fact that my server is rented and in Leipzig i don’t want them to raid my appartment. Child-porn, you know, the last reason. You could possibly justify everything with it.)

One operator whose server was seized as well wrote a letter to all the TOR-operators in Germany he was aware of, reaching me as well; he wrote that he is not aware of any charges pressed against him at the moment and that his provider, whose server-room was raided, was not avilable for a real comment on the weekend.

We just have to wait what’s going on, which charges are pressed – if at all, i somehow doubt that – and when the state will give that servers back. This is really something horrible for the TOR-operator – especially if you take into account that there will be no evidences at all to find on the harddrive. It’s just a hassle, stress which is put upon you.

But i guess we have to go through it. There was no lawsuit about TOR in Germany yet – i hope it’s not going into the direction of “supporting proliferation of child-pornography“. This would be the end of anonymizing services in Germany and probably everywhere in the EU.
I run TOR to get a certain level of privacy. Staying anonymous is no crime. I want my privacy.

I’m still completly out-of-service because of that spider-bite (it apparently was one). Wireless network is working currently so i got lot’s of time to surf the net:)

A friend from IRC posted me an interesting article (thanks roam, good read!) by someone who’s really into chemistry and security and he completly dismantled the plausibility of the recent terrorist-plot. What he basically says is that the explosive which should’ve been used are impossible to synthesize on board of a plane.

It was claimed that the terrorists wanted to use hydrogen peroxide (H2O2) and sulfuric acid (H2SO4) to create an oxidizer known as “piranha bath” – one of the most evil substances you can imagine – and mix it with acetone (aka “nail polish remover”) to create acetone peroxide, which is a nasty explosive.

The whole problem with this plot is that it’s almost impossible to mix those substances on a plane, the terrorist would kill himself – and probably only himself – while mixing the ingredients. No explosion? No fame for those pesky terrorist!

David also compiled a list of other substances which should’ve been banned in the first place because they are intended to kill people:

baby powder

replace with potassium cyanide + dry carboxylic acid – add water from the toilet – voilá! – hydrogen cyanide gas (aka the stuff some american states use in their gas-chambers)

elderly gentleman’s cane

Made of aluminum and iron oxide – aka termit! Burn a hole in the plane. Yay!

“about as many people die in the US every month in highway accidents than have died in all our domestic terrorist incidents in the last 50 years. Untold numbers of people in the US are eating themselves to death and dying of heart disease, diabetes, etc.”

Happy terrorist hunting!

Edit: Added the “replace with” ’cause people were asking “wow, didn’t know that baby powder is that dangerous“.