Using PuTTY and keyfiles to SSH into your Ubuntu 12.04 server

This week I had a really hard time getting public key authentication to work with my Ubuntu 12.04 server. Partly because I didn’t know what exactly I was doing but mostly because I didn’t know how to do it.

Several tutorials were helpful in explaining what to do but in the end I figured out how to go about it. So here’s how.

Generate a key pair

Download PuTTY and PuTTY Key Generator from Save them somewhere, no installation is necessary.

ssh_key_auth (1)

Execute puttygen.exe and click the Generate button.


ssh_key_auth (2)

Move the mouse around a bit.


ssh_key_auth (3)

Enter your e-mail address in the “Key comment” field.


ssh_key_auth (4)

Copy ALL text under “Public key for pasting into OpenSSH authorized_keys file”. Include “ssh-rsa” and the e-mail address.


ssh_key_auth (5)

In the “Key passphrase” field enter a hard password.


ssh_key_auth (6)

Press “Save public key” and save the file where you can find it. The extension of this file doesn’t matter.


ssh_key_auth (7)

Press “Save private key” and save the file in a location only accessible to you. If you lose the file you might lock yourself out of your server. The extension of this file needs to be .ppk.

Tie the key to a PuTTY profile

Now close PuTTY Key Generator and start PuTTY.

ssh_key_auth (8)

Under “Host Name (or IP address)” enter the name or the ip address of your server and under “Saved Sessions” enter the name of the profile you’re creating (e.g. “My Server” – in this case my server is called ubuserv06).


ssh_key_auth (9)

 In the options tree on the left side choose Connection > SSH > Auth.


ssh_key_auth (10)

 Press “Browse” and select the private key you saved earlier.


ssh_key_auth (11)

 Go back to Session and press “Save”.


ssh_key_auth (12)

Press “Load” and login to your server through regular password authentication. Don’t mind the key error just yet, we still need to configure that.

You can also have PuTTY remember your username by entering it under Connection > Data > Auto-login username.

Edit the ssh settings on your server

Log on as your regular user (not root) and create a file ~/.ssh/authorized_keys.

In that file paste the string you copied from PuTTY Key Generator on one single line. Note that PuTTY Key Generator saves the key as a file with the key divided into multiple lines. Do not copy and paste that but paste it as it showed it to you just after generation in the “Public key for pasting into OpenSSH authorized keys file” field.

Make the directory ~/.ssh readable for only you and remove the executable bit from the authorized_keys file:
$ chmod -R 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Edit /etc/ssh/sshd_config so it contains
AuthorizedKeysFile %h/.ssh/authorized_keys

Restart the SSH service:
$ sudo service ssh restart

Now try and see if you can logon via PuTTY with your private key. It should say something like:
Authenticating with public key "your@email.address"
Passphrase for key "your@email.address": _

If it doesn’t work, it would say
Server refused our key

In that case, see the Troubleshooting section.


  • If you’re using encrypted home folders store your authorized keys in a place that is accessible to the system before you logon, for example in /etc/ssh/.
  • In Ubuntu 12.04 the ssh service is called ssh not sshd.
  • In the file ~/.ssh/authorized_keys each and every key must be on its own single line.
  • Before you disable password logins in /etc/ssh/sshd_config test if your key authentication works properly.
  • PuTTY Key Generator saves the key file with line endings. Copying and pasting it will not work.


If things don’t work, open up a second session to your server or logon locally and monitor ssh login attempts and their error messages in realtime:
$ tail -f /var/log/auth.log

If you’re done monitoring end it with Ctrl+C.

Setup OpenVPN with Google Authenticator on Ubuntu 12.04 LTS server

OpenVPN is nice. It works on all kinds of servers and nowadays there are clients for all kinds of devices as well. I use it to connect to my home network from my laptop when I’m elsewhere and from my Android phone if I’m on a public hotspot because it encrypts all my data.

Recently I added one time passwords to my OpenVPN setup. You install Google Authenticator on your phone and it generates a fresh code every thirty seconds. You use that code to add to authentication on your OpenVPN server and this gives you pretty good security because you need:

  • something you have (certificates);
  • something you know (your username and password);
  • something unique (the one time password from Google Authenticator).


These three things – something you have, something you know and something unique – are considered essential for decent security. Of course this is no guarantee for good security as other components are equally essential, like keeping your passwords for yourself and having your phone automatically lock after a certain amount of time so your secrets aren’t easily available for other people.

That said, it can’t hurt to add an extra layer of security to your OpenVPN setup and it’s not very difficult so there’s really no reason not to do it.

[Edit 2013-12-18: I found one. The SSL/TLS renegotiation handshake occurs once per hour per client. By default OpenVPN caches your credentials (you can turn it off by using the auth-nocache option) but the cached credentials contain a random number in the password! Effectively this means your connection will be dropped after exactly one hour. I haven’t found a workaround yet and I’m afraid any workaround will compromise other parts of the security philosophy. The solution must lie in implementing Google Authenticator in a separate credential field from the password. If you do not intend to use your connection for more than one hour at a time and then perhaps reconnecting this is fine but for all-day use this can get quite annoying.

Edit 2014-04-04: And here is the solution. Add this line to both the server and client configuration:

reneg-sec 0

If you set reneg-sec to 36000 on the server and to 0 on the client, the server will ask for a new one-time password every ten hours and the client won’t initiate dropping the connection by itself.]

In this article I’ll describe how I built two OpenVPN servers on a Ubuntu 12.04 LTS server. I chose Ubuntu 12.04 LTS because it’s easy to find documentation on it.

(Note: the term OpenVPN server refers to an OpenVPN profile on my server. So one Ubuntu server with two OpenVPN servers means one machine serving two different tastes of OpenVPN.)

The first OpenVPN server allows connecting to the LAN from outside but with the internet breakout at the client side: traffic from the client to your LAN goes through the vpn but traffic from the client to the internet doesn’t and goes outside directly. The advantage of this setup is that it spares bandwith on your server’s internet connection. You would use this if you are in a trusted network and your vpn server doesn’t have a whole lot of bandwith.

The second OpenVPN service has its internet breakout at the OpenVPN server. Here, all traffic from the client including internet traffic are routed through the vpn. The advantage here is that the client must adhere your OpenVPN server’s firewall rules and that all internet traffic is encrypted because it’s also vpn traffic. This is ideal for public hotspots and other untrusted networks.

A heads up: if you’re running more than one OpenVPN server on a server you MUST use unique virtual ip ranges and port numbers. If you’re using the same virtual ip ranges for multiple OpenVPN servers on the same machine then only one of those servers will work.

Also try and use a non-standard private ip range on your server’s lan. Most home routers use or and it’s virtually impossible to use a vpn from an ip range connecting to a lan with that same ip range. Use something like or so you’ll have a good chance you won’t be connecting from that same ip range in someone else’s network.

Before we begin:

  • My server’s wan network interface is called ‘wan’. Yours may be called eth1 or something else. Replace ‘wan’ with your interface’s name.
  • I’m doing this as root so I don’t have to type ‘sudo’ before every command.

Enabling your server’s routing capability

Enable packet forwarding by opening up /etc/sysctl.conf and uncommenting the line where it says


Now set up ip masquerading so your clients can break out:

# iptables -t nat -A POSTROUTING -o wan -j MASQUERADE

Add the above line to /etc/rc.local to have it enabled after a reboot.

Installing OpenVPN

This is the easy part.

# apt-get install openvpn

Creating certificates

The OpenVPN package now contains a convenient certificate authority which we’ll use. Feel free to use any other ssl facility you like.

Create a certificate autothority (ca):

# cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0 /etc/openvpn/easy-rsa
# cd /etc/openvpn/easy-rsa

Edit the /etc/openvpn/easy-rsa/vars file to your needs:

export EASY_RSA="/etc/openvpn/easy-rsa"
export KEY_COUNTRY="NL" (or whichever country you're in)
export KEY_PROVINCE="ZH") (or whichever province you're in)
export KEY_CITY="Rotterdam" (idem)
export KEY_ORG="Vorkbaard, Inc." (your organisation's name. Make one up if you need.)
export KEY_EMAIL="your@email.address"

Make sure easy-rsa can find openssl-cnf to prevent an error:

# ln -s openssl-1.0.0.cnf openssl.cnf

Commit your changes:

# source ./vars

Create a ca certificate

# ./build-ca openvpn

Enter the correct values. Noone’s checking them and you may use the same values as before. It’s handy to fill these out with true values in case you need to troubleshoot and you have more than a couple of users. For the common name, enter your server’s fqdn, e.g.

Create a key server:

# ./build-key-server myserver

(‘Myserver’ would be my server’s hostname)

Enter the correct values; these will be used to sign user certificates.

You can leave A challange password and An optional company name empty.

Sign the certificate? y
Commit? y

Set up Diffie-Helleman parameters

# ./build-dh

Create the OpenVPN config files

We’ll first setup the OpenVPN servers and clients and get them working. Then we’ll add the Google Authenticator bits. It’s easier to troubleshoot that way. We’ll call the local breakout one ‘general’ and the vpn breakout one ‘routeall’. You can use any name. Choose one that describes your vpn server so its easy to recognize while going through logfiles for troubleshooting. I’ll use non-standard ports; feel free to use any ports you like.

Create a file /etc/openvpn/general.ovpn and put this in it:

dev tun
proto udp

# Here comes the port name. Remember this must be unique for every OpenVPN server on your system!
port 1095
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/myserver.crt
key /etc/openvpn/easy-rsa/keys/myserver.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem

# Here comes the virtual ip range. Remember this must be unique for every OpenVPN server on your system!

# Here comes your server's lan subnet. Substitute with your own!
push "route"
push "dhcp-option DNS"
push "dhcp-option DNS"

# Float: if your client switches from one network to another (which you might if you're testing) this tells OpenVPN to ignore errors on packages that got lost because of that.

# Use a per-server logfile for easy troublesooting.
log-append /var/log/openvpn-1095-general.log

Create an OpenVPN config with server side breakout

This is essentially the same as the local breakout, but call this file /etc/openvpn/routeall.ovpn and add this line for server side breakout:

push "redirect-gateway def1"

change the port number and the virtual ip:

port 1094

and change the logfile to reflect this profile’s name:

log-append /var/log/openvpn-1094-routeall.log

For troubleshooting, look in the logfiles. I like to use this method:

# tail -f /var/log/openvpn-1094-routeall.log

This keeps the logfile on the screen and updates it in realtime.

Restart the OpenVPN service:

# service openvpn restart

Create user profiles

We’ll create a user profile for user Lucas. We need to do this for every user separately.

# cd /etc/openvpn/easy-rsa
# ./clean-all
# source ./vars
# ./build-key lucas

Enter your preferred values. You can leave A challange password and An optional company name empty.

Sign the certificate? y
Commit? y

Now send these three files to the client:

On the client

On the client, make a directory, put the three files in it (ca.crt, lucas.key and lucas.crt) and create a file called myserver-general.ovpn (or whatever name you would like to give the profile) and put this in it:

dev tun
proto udp
remote your.servers.fqdn.or.public.ip.address 1095
resolv-retry infinite
ca ca.crt
cert lucas.crt
key lucas.key
verb 3

‘Verb 3′ means the level of verbosity. If you need to troubleshoot the client, increase the level of verbosity for more status messages. Decrease for less.

Make a second file called myserver-routeall.ovpn based on myserver-general.ovpn but change the port number and virtual subnet to reflect your routeall OpenVPN service. You now have two OpenVPN profiles on your client.

Download and install an OpenVPN client you like and initiate the connection. Verify that both profiles work. If they don’t, check the logfiles to find out why they don’t and fix it. Check for typos, check for port forwarding if you need that. If they don’t work, don’t go through to the Google Authenticator part.

And now for the fun part.

Adding Google Authenticator to the mix

We use Linux’s Pluggable Authentication Modules (PAM) system to require Google Authenticator when connecting to the OpenVPN server. At the moment of writing Google Authenticator is missing a piece that’s necessary for us to use it so we’ll download the source code, edit in the missing piece and compile it.

Install the pam developer tools:

# apt-get install libpam-dev

Prepare the Google Authenticator code

Download the Google Authenticator source code from Google, extract it and save it somewhere.

# mkdir ~/gauth
# cd ~/gauth
# wget
# tar xvf *.bz
# cd lib*

Open the file Makefile and between the license part and where it says ‘VERSION := 1.0’ add this line:


Save the file and compile it:

# make
# make install

Implementing Google Authenticator in OpenVPN

On your server open /etc/openvpn/general.ovpn (the other one as well if you like) and add this line:

plugin /usr/lib/openvpn/ openvpn

Restart the OpenVPN servers:

# service openvpn restart

Make a PAM file that works with OpenVPN:

# cp /etc/pam.d/common-account /etc/pam.d/openvpn

Open /etc/pam.d/openvpn and add these lines:

auth requisite forward_pass
auth required use_first_pass

Now as the user who will be using the OpenVPN connections, execute

$ google-authenticator

…and follow the instructions. Meanwhile on your phone install Google Authenticator and create a profile with the information presented by google-authenticator on your server.

Executing google-authenticator adds a file .google_authenticator in the user’s home directory. This file must have no rights except read for the user:

$ chmod 400 /home/lucas/.google_authenticator

On the client, edit the .ovpn files and add:


Using OpenVPN with Google Authenticator

If all is well you now have a six digit number generator on your phone. Fire up the OpenVPN connection on your client and log in with these credentials:

username: yourusername
password: yourpassword573984

That’s right: the six digit Google Authenticator code is added directly to your password. So every time you log in, you have a unique password-six digit code combination.

If your username is lucas, your password is p@55w0rd and the current six digit code on your phone is 822546, you would log in with

username: lucas
password: p@55w0rd822546

If things don’t work, check OpenVPN’s log file on the client and on the server check /var/log/auth.log and /var/log/openvpn-1095-general.log (or whatever you’re having your OpenVPN server log to).

Een Debian-systeem backuppen en restoren

Backups zijn leuk maar geteste backups zijn nuttig. Zo kwam het dat ik de disk uit mijn Ubuntu-server trok en er een lege disk in stopte om te kijken hoe compleet mijn backupsysteem was.

Het viel me op dat het in Debian-systemen (*nix in het algemeen) erg makkelijk is om alles in één keer te backuppen. Ik was een lijst aan het maken van wat ik moest backuppen op een nieuwe server en dat waren de volgende dingen:

  • configuratiebestanden van geïnstalleerde software;
  • websites;
  • de software zelf;
  • instellingen van de router/firewall;
  • MySql-databases.


De userdata op de server backup ik op een andere manier en deze server is geen mailserver.

Backups zijn er grofweg in twee smaken: backups voor historische redenen en backups voor disaster recovery. Historische backups gebruik je als je er vandaag achterkomt dat je twee weken geleden een bestand overschreven hebt waarvan je een oude versie nodig hebt. Disaster recovery is voor als je server compleet onbruikbaar geworden is, zoals bv. door diefstal, brand of een vervloeking.

Voor disaster recovery gebruik ik CloneZilla. De server moet daar een half uurtje voor uit de lucht maar als je het eens per maand doet vind ik het een mooie trade-off tussen gemak en functionaliteit aan de ene kant en downtime aan de andere kant.

Voor historische backups heb ik een aantal dingen geprobeerd maar uiteindelijk heb ik toch zelf een scriptje gebakken. Dit is wat het doet:

  1. maak een backup van /etc met tar voor de configuratiebestanden
  2. maak een backup van /var/www met tar voor de websites
  3. doe dpkg –get-selections > selections voor de software (via dpkg –set-selections < selections kan je alles dan weer automatisch laten installeren)
  4. iptables-save > iptables voor de router/firewall (restoren met iptables-restore < iptables)
  5. backup alles MySql-databases met mysqldump -u root –password=p@55w0rd –events –all-database > mysql (restoren met mysql -u root -p < mysql)
  6. maak een mooie logfile en mail die naar me


Ik had weinig ervaring met bash-scripting maar het viel me mee hoe eenvoudig het allemaal in elkaar zit. Het lijkt of je dichter op het os zit dan in Windows en daarom minder rekening hoeft te houden met lagen bovenop je os en je software.

De historische backups kan je gebruiken als differentiële backups die je aan je disaster recovery toe kan voegen. Dat houdt in dat je je systeem vanaf niks herstelt met de image van CloneZilla en dan aanvult met de meest recente historische backup – een beproefde methode.

Zie ook: The Tao Of Backup. Een reclame, maar wel erg grappig en leerzaam.

Het restoren van mijn Ubuntu-server is overigens prima verlopen. Ik begon zoals ik dacht dat logisch was (systeem installeren, software, updates, data, databases, config-files) en alles werkte eigenlijk zoals je zou verwachten.

Debian Wheezy op een nc4400

Bij archeologische opgravingen op mijn zolder is een oude laptop naar boven gekomen. Deze laptop had eerder dienst gedaan als mediaspeler met XBMC maar bij gebrek aan werkende kabels liep dit project uiteindelijk in de soep.


Onlangs kwam de nieuwe versie van Debian, Wheezy, uit en de opgraving leek me een mooie gelegenheid om het eens te proberen. In eerste instantie had ik er Ubuntu op gezet maar de Unity-desktop is bepaald niet mijn smaak: de tendens om alles full-screen te maken, en zeker het startmenu, vind ik erg ononverzichtelijk. Bovendien had ik moeite met dingen zoals Flash goed aan de praat te krijgen. Kleine ongemakken allemaal, en goed te verhelpen als je van Googlen houdt, maar de idee van Ubuntu was nou juist dat het allemaal gewoon werkte, dacht ik.

Enter Linux Mint. Linux Mint heeft als doel een beter gepolijste desktop (Cinnamon) te bieden en een afgewerkter os als geheel. Audio- en videocodecs zijn ingebakken, drivers voor wireless en video en normale software (VLC Player) zijn meteen geïnstalleerd.

De standaard desktop van Mint is Cinnamon, wat ik erg fijn vind werken omdat het truukjes die in Windows 7 ook beschikbaar zijn, kent, zoals het automatisch aan de linkerkant van het scherm vullen van een window als je het tegen de linkerkant aansleept, of Win+left. Het probleem dat ik met Linux Mint had echter was dat het soms bevroor. Het os stond helemaal vast op de muis na. Een artikel op How-To Geek over the magic SysRq-toets hielp me om de laptop dan weer netjes af te sluiten, maar een oplossing was het niet.

Aangezien Linux Mint op Ubuntu is gebaseerd en Ubuntu weer een Debian-derivaat is, besloot ik stroomopwaarts te gaan naar Debian zelf. Na een beetje puzzelen (niet te moeilijk want het moet wel leuk blijven) had ik een verse Debian-installatie op mijn ouwe laptop. De desktop die ik erbij kreeg, was Gnome. Nu is Gnome een aardige desktop maar niet zo mijn smaak. Gnome Classic vind ik te mager en de nieuwe Gnome veel te aanwezig.

Daarom heb ik de Cinnamon-desktop erop geïnstalleerd en ik ben er erg tevreden over.


Vooralsnog is Debian op deze laptop erg snel en stabiel.

sudo op Debian

Debian zit sudotechnisch een klein beetje anders in elkaar dan Ubuntu en Mint. Wil je in Ubuntu iets als root doen, dan kan je sudo <commando> doen. In Debian kan dat ook maar niet vanzelf. Alleen gebruikers die in de groep sudo zitten, mogen sudo doen. Je kan wel altijd su root gebruiken om als root verder te gaan in de sessie maar sudo is handig om beschikbaar te hebben.

Om sudo te kunnen gebruiken, moet je jezelf eerst aan de groep sudo toevoegen, maar om gebruikers aan groepen te kunnen toewijzen, moet je eerst root zijn:

# su root
# usermod -G sudo vorkbaard

Als je nu opnieuw opstart, kan je sudo gebruiken.

Cinnamon installeren

Het leuke van Linux is dat de desktop die je gebruikt, gewoon een programma is net als al de andere. Je kan desktopprogramma A gebruiken maar ook desktopprogramma B en dat heeft (vrijwel) geen effect op je andere programma’s. Dat klinkt voor veel mensen logisch maar toen ik voor het eerst rondkeek buiten Windows (namelijk bij FreeBSD) wist ik het niet.

De desktop van Gnome beviel me niet zo dus heb ik Cinnamon geïnstalleerd. Dat was niet al te ingewikkeld:
# echo "deb debian main upstream import" >> /etc/apt/sources.list
# apt-get update
# apt-get install linuxmint-keyring cinnamon

/etc/apt/sources.list is de lijst van bronnen die Debian raadpleegt bij het zoeken naar software en updates. Voor het installeren van Cinnamon waren vroeger wat meer packages nodig (met name cinnamon-session en cinnamon-settings) maar die zitten tegenwoordig blijkbaar in cinnamon ingebakken.

Het installeren duurde een minuutje. Nu kon ik bij het aanmelden voor Cinnamon kiezen.

Drivers voor draadloos netwerk en videokaart installeren

Debian bevat standaard uitsluitend vrije software. Ik moest de driver voor mijn Intel-wlankaart dus apart ophalen.

# dmesg | grep -i "wifi"
om uit te vissen welke driver je nodig hebt. Bij mij stond er:
l3945 0000:10:00.0: firmware: agent aborted loading iwlwifi-3945-2.ucode (not found?)

Tik “iwlwifi-3945” in bij Google en klik op de eerste link die je tegenkomt. Daar wordt de volgende methode beschreven:

Voeg de non-free-repository toe aan /etc/apt/sources.list:
# echo "deb wheezy main contrib non-free" >> /etc/apt/sources.list

Update de package-lijst:
# apt-get update

Installeer de driver:
# apt-get install firmware-iwlwifi

Laad de iwlwifi-module zonder opnieuw op te hoeven starten:
# modprobe -r iwlwifi ; modprobe iwlwifi

Nu de videokaart:
# apt-get install xserver-xorg-video-intel

OpenVPN in Gnome network manager

Ik gebruik OpenVPN om verbindingen naar diverse lokaties te maken. Gnome heeft een mooie grafische network manager en die gebruikt Cinnamon ook. Het is mogelijk om hier OpenVPN-profielen aan toe te voegen.

Deze pagina heeft een duidelijke uitleg over het gebruik van network manager:

Installeer de juiste pakketten:
# apt-get install openvpn network-manager-openvpn network-manager-openvpn-gnome

Network manager beheert standaard alleen maar netwerkinterfaces die niet in /etc/network/interface staan. Dit is te overschrijven door in /etc/NetworkManager/NetworkManager.conf managed=false te veranderen naar managed=true.

Herstart de network manager:
# service network-manager restart

Haal je OpenVPN-bestanden op van je OpenVPN-server en kopieer ze naar ~/Vpn. Maak de bestanden leesbaar voor jezelf en voor de rest voor niemand met
# chmod 400 ~/Vpn/*

Importeer het .ovpn-profiel in Gnome Network Manager. Door een fout in de gui kan je als je .p12-cinnamon_02certificaten gebruikt, pas op Save drukken als je iets hebt ingevuld bij ‘Wachtwoord van de privésleutel’. Soms vraagt Gnome bij het starten van de vpn om dit wachtwoord maar lang niet altijd. Ik heb hier maar ‘test’ ingevuld. Het is een dummy-password, het hoeft dus niet ergens mee overeen te komen. Het is in theorie mogelijk om je .p12-certificaat om te zetten naar .crt, .key en .pem maar hoewel me dat wel is gelukt, is het me niet gelukt om network manager hiermee te laten werken.

Na het importeren kan je de vpn starten door erop te klikken in de network manager. Erg mooi!

Extra themes installeren voor Cinnamon

Op kan je extra themes voor Cinnamon downloaden. Download een theme en pak het uit naar /usr/share/themes. Daarna kan je het via Menu > Preferences > Cinnamon Settings > Themes activeren.

Automatisch Samba-shares mounten

Om naar de shares op mijn Windows-server te verbinden, heb ik entries toegevoegd aan /etc/fstab. /etc/fstab is het bestand waarin staat welke filesystems gemount moeten worden bij het opstarten.

Eerst heb ik een bestand ~/.smbcredentials gemaakt om de credentials van het account op mijn server in te schrijven:

(Het password hierboven is natuurlijk niet mijn password…)

Ook heb ik twee lege directories gemaakt waarop de shares gemount kunnen worden. Deze directories zijn placeholders voor de te mappen filesystems. Het is gebruikelijk om filesystemen in /media te mounten maar je kan ze maken waar je wil.

Mijn server heet N36L. Mijn homefolder is Vorkbaard en de andere share waar ik naar wil verbinden, is Media met daarin films, muziek en foto’s.
# mkdir /media/n36lhome
# mkdir /media/n36lmedia

Daarna heb ik het bestand /etc/fstab geopend en dit eraan toegevoegd:
//n36l/vorkbaard /media/n36lhome cifs credentials=/home/vorkbaard/.smbcredentials,oicharset=utf8,file_mode=0777,dir_mode=0777,sec=ntlm 0 0
//n36l/media /media/n36lmedia cifs credentials=/home/vorkbaard/.smbcredentials,oicharset=utf8,file_mode=0777,dir_mode=0777,sec=ntlm 0 0

file_mode=0777,dir_mode=0777 is nodig om de shares schrijfbaar is maken. Zonder deze optie zouden ze alleen-lezen zijn.

Als je de laptop nu opnieuw opstart, worden de shares automatisch gemount. Je kan het ook doen zonder opnieuw op te starten door
# mount -a
te doen. Dismounten kan met (in dit geval):
# umount /media/n36l*

Evolution mail client

Evolution is een mailclient die met de juiste plugins ook met Exchange kan praten en dat komt me goed uit. Mijn server is Exchange 2007 en Evolution kan er verbinding mee maken via de plugin evolution-ews.


# apt-get install evolution

Maak een nieuw account van de smaak Exchange Web Services. Vul je username in en bij Host URL het adres van je owa, bv. Druk op Fetch URL om de rest automatisch in te laten vullen.

Ik gebruik Evolution met veel plezier met twee Gmail- en twee Exchange-accounts. Het laat netjes alle mail, mappen, agenda’s en contactpersonen zien en ik vind dat het economischer gebruik maakt van de beeldschermruimte dan Thunderbird.

Bij het instellen moppert Evolution soms een beetje dat het dingen niet kan vinden, agenda’s niet kan laden, enz. Laat Evolution gewoon verder pruttelen en de volgende keer dat je het start, werkt het wel.

Voor offline gebruik kan je aangeven dat Evolution je mail lokaal moet cachen, net als Outlook.