Draft posting: Advanced ssh usage

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

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:

  1. Alice creates a keypair and sends her public key to Bob: "ssh-keygen -t dsa"
  2. Bob verifies the fingerprint of Alice’s public key: "ssh-keygen -f id_dsa.pub-alice -l"
  3. 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:

Puttygen Mainscreen

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:

Puttygen Generate Keypair

After wiggleing the mouse around for a couple of times, the key is generated, resulting in that screen:

Puttygen New Key

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:

Putty Connection -> SSH -> auth

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:

Putty Auth
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)


Creative Commons License
This work is licensed under a Creative Commons Attribution 2.5 License.


Tech Tags:

13 Responses to Draft posting: Advanced ssh usage

  1. Tas says:

    Looks very useful! :-)

    Tas.

  2. Michael says:

    Please continue. It”s usefull. :-)

  3. Markus says:

    spread this in our office ;)

  4. Markus: Actually that was my initial intend ;) (just look at the usernames, that should exlplain everything…)
    I’d rather write a document for the general public than one for the company which noone will actually read. It was already annouced on the SCITPE-mailinglist and will be annouced on the NW32 list later.
    The planners are “early adoptors” – not like our staff…

  5. Wiktor says:

    Hi Alex,

    good beginners tutorial. You should write something about sshagent and Portforward maybe.

  6. Wiktor: Is due for this week and will be included in this article as well.
    Cheers, Alex.

  7. Thanks got it working. Should I bother disabling the old school authentication method completely?

  8. Oi Daniel, you may do that – that’s something which will be covered in this document as well. And while you’re at it make sure you only allow ssh protocol version 2, version 1 is known to be vulnerable.

    Cheers, Alex.

    P.S.: Additional note: Make sure you backup your keypair on the client on some safe medium so that you don’t lock yourself out in case the client where they is stored dies for some reason (broken harddrive or something…)

  9. darkfader says:

    things you could add:
    include from=”” and
    command=”” for all the shinyness and wonderful restrictiveness that lies in them.

    (Meine Chefs hatten mal die Anforderung gestellt, dass die wunderbar abgeschottete Kiste doch bitte vom Adminhost passwortlos per ssh zu erreichen sein sollte. Habe ich gemacht – sieht so aus

    adminhost # ssh tight_box
    connecting ….
    legal banner …
    Selftest [OK]
    Status of Daemon 1 [OK]
    Status of Daemon 2 [OK]
    Status of Daemon 3 [OK]
    logout

    Das ist nun ein halbes Jahr so, und bisher gab es keine Anforderung es zu aendern. har har har. )

    Also, maybe include commands for testing that public key access still works,
    like ssh -o auth=publickey hostname “/bin/true” ; this is my personal faq, actually I already forgot the correct options. once again.

    flo

  10. Mansvi says:

    Article is indeed very gud.
    Here I am facing a problem..if you can help me in.
    If i execute a sommand on a server using ssh… then it doesnot execute .profile of the user i am logging through. Is there any option in ssh i can use to get my profile executed before the execution of my command.
    like
    ssh user@hostname ‘my_command’ will not execute the .profile
    what i have to do is
    ssh user@hostname ‘~/.profile ; my_command’
    but ssh if used for login as “ssh user@hostname” coz logins, executes .profile of the user.
    Is there any way it can be handled using some default ssh opton of some changes…

  11. Arun says:

    Really great stuff! I would like to read your further chapters about port-forwarding and tunneling too. Please go ahead and write them too!! :) Thanks a tonne for the stuff above…

  12. Sai says:

    great article for beginners, please finish it

  13. […] that, you may either use a search engine or read the following articles: SSH Advanced Techniques; Advanced SSH Usage; and SSH authorized_keys howto. What I will provide, though, are three quick […]

%d bloggers like this: