Categorie: Arkon

SSH beveiligen

Aangezien ik de ssh-server op Arkon nu ook vanaf externe adressen wil kunnen benaderen zal ik moeten zorgen dat er geen ongewenste bezoekers binnenkomen. Nu kan ik een aantal ip-adressen opgeven vanwaar ingelogd mag worden maar ik kies voor een andere route.

Ik gebruik namelijk al een systeem met public en private keys, als ik opensshd nu aanpas dat er enkel nog ingelogd mag worden met behulp van een key dan kunnen ze proberen wat ze willen maar gaat het niet lukken.

Als eerste heb ik gisteravond de router ingesteld om de juiste poort te forwarden naar Arkon. Daardoor kan ik nu tijdens de pauze Putty instellen en de boel dichttimmeren.

Als eerste met behulp van Puttygen een rsa2 key van 2048 bits aangemaakt. Het publieke deel heb ik met nano toegevoegd aan de authorized_keys. In Putty heb ik vervolgens een profiel (Saved Session) met daarin de hostname en poort. De instellingen van het toetsenbord heb ik omgezet naar unix. Ook controleer ik op Putty probeert om de key te laden vanuit Pageant (Putty Authentication Agent)

De private key die ik aangemaakt heb met Puttygen heb ik voorzien van een (sterk) wachtwoord. Door eerst Pageant.exe op te starten kan ik daarin een key inladen waarbij ik het wachtwoord moet opgeven.

Hierna kan ik met Putty inloggen op Arkon, er wordt me om een gebruikersnaam gevraagt en Pagent doet de rest door de key te vergelijken.

login as: tecumseh 
Authenticating with public key "tecumseh.homeip.net" from agent

Nu de ssh server nog verder dichttimmeren. Door in /etc/ssh/sshd_config 2 waarden aan te passen kan er niet meer ingelogd worden met behulp van een wachtwoord:

PasswordAuthentication no 
UsePAM no

En dan nu het moment van de waarheid, het herstarten van de ssh server en kijken of ik er nog inkan.

Arkon:~# /etc/init.d/ssh restart 
Restarting OpenBSD Secure Shell server: sshd.

Vervolgens kan ik na het afsluiten van Putty nog steeds inloggen. Nu Pageant eens afsluiten en nog een keer proberen.

PuTTY Fatal Error 
Disconnected: No supported authentication methods available

Dat werkt dus prima!

Openssl in Debian en afgeleiden voorspelbaar

Aangezien recent gebleken is dat de Debian ontwikkelaars een bug ingevoegd blijken te hebben in openssl zijn de aangemaakte keys niet betrouwbaar.

Wat ik ervan begreep gebruikt openssl een variabele op een ongebruikelijke manier. De Debian ontwikkelaars hebben dat dus aangepast zonder te weten dat dit de basis is voor het aanmaken van random gegevens die een key onvoorspelbaar maken. Dat ze dit gedaan hebben komt mede doordat de code op dit punt niet gedocumenteerd was en er blijkbaar geen reactie geweest is na het submitten van deze patch naar de ontwikkelaars van openssl.

Nu gebruikt onder andere openssh deze aangemaakte keys en aangezien ik inlog met behulp van deze methode zal ik de oude keys moeten weggooien en opnieuw aanmaken. Het bijwerken van de pakketten op zowel de Debian als de Kubuntu systemen heb ik al gedaan.

Als eerste maar eens zorgen de oude keys niet meer gebruikt worden. Per machine log ik in met behulp van de key en hernoem het bestand authorized_keys. In een extra terminalvenster kan ik vervolgens op mijn machine een nieuwe key aanmaken op de vertrouwde methode. En het testen hiervan. Als dat lukt dan kan ik de hernoemde authorized_keys file gaan verwijderen.

Gelukkig heb ik slechts 4 machines waarbij ik op deze manier inlog en gebruik ik nog geen certificaten dus het blijft binnen de perken. Het schrijven van dit bericht heeft me in elk geval meer tijd gekost.

Aanpassen mailadressen op Arkon

In verband met de overstap van @home naar concepts ICT verdwijnt binnenkort mijn mailadres bij @home. Ik zal dus op Arkon een aantal dingen moeten aanpassen zodat ik nog steeds op de hoogte gehouden wordt over de stand van zaken op mijn systeem.

Nu krijg ik regelmatig mailtjes over 2 dingen. De 1e is het update script wat dagelijks gedraaid wordt, in dit script zit ook het mail commando en het mailadres dus dat levert geen zoektocht op.

Wat wel zoekwerk geeft is het backupscript wat me bij het falen een mailtje stuurt. Ik krijg namelijk dagelijks nog een mailtje met de volgende inhoud:

tar: Removing leading `/' from member names

Dit mailtje is afkomstig van de crondaemon. De foutmelding hoor ik trouwens netjes af te vangen zodat ik enkel mail krijg bij het falen van de backup. Staat nog op mijn todo lijstje.

Cron heb ik niet geconfigureerd met een MAILTO adres. Dit mailtje vindt zijn oorsprong dus elders. Maar eens kijken wat postfix als configuratie heeft. In het bestand aliases vindt ik waarschijnlijk de hoofdschuldige. Alle mail gericht aan de root user wordt automagisch doorgestuurd naar mijn @home adres. Even aanpassen en postfix herstarten en dan hoort het voor elkaar te zijn.

Lighttpd staakt (2)

Zowel gisteren als vandaag begon de webserver weer kuren te vertonen. Na het updaten van een aantal posts op dit blog kreeg ik geen reactie meer terug. Dus toch maar weer eens de logbestanden nageplozen. Vreemd genoeg is er niets te vinden wat een probleem zou kunnen geven.

Als laatste redmiddel dan toch maar een mailtje gewaagd aan Henk van de Kamer, ik heb tenslotte van hem afgekeken hoe ik de server opzetten kan.

Gelukkig tref ik het want ik heb dezelfde avond nog een mailtje terug ontvangen. Henk was dus beschikbaar en hij had een oplossing voor me. Hij heeft hetzelfde probleem namelijk al eens eerder ondervonden. En aangezien ik zijn configuratie bestanden overgenomen en dus ook zijn achteraf gezien wat ongelukkig instelling:

http://www.hetlab.tk/asterix/tunen-webserver

Wat hier dus gebeurt is dat bij sommige handelingen er door php teveel tijd besteed wordt. Doordat er maar maximaal 1 proces mag zijn volgens de configuratie kom je in de problemen als dit proces ermee ophoud door geheugenproblemen. Door dus het maximale aantal processen te verhogen voorkom je dat de server in  staking gaat.

Na het aanpassen van het php configuratiebestand en het herstarten van lighttpd draait de webserver deze keer hoogstwaarschijnlijk een stuk langer.

Bedankt Henk!

Grub menu

Het is er dan eindelijk van gekomen. Al een paar dagen is mijn systeem in het bezit van een dualboot setup waarbij ik de beta van Kubuntu 8.04 Hardy Heron KDE4 aan het testen ben.

Door de installatie hiervan is er een 2e grub geïnstalleerd. Ik had blijkbaar toch voor een aparte boot-partitie moeten kiezen. Nu heb ik 2x een /boot directory, 1 op /dev/sda1 en 1 op /dev/sda5. Mogelijk komt er daar straks nog 1 bij want ik heb ook nog een /dev/sda6 gereserveerd voor een extra OS.

Als eerste dus maar het activeren van grub op /dev/sda1. Hiervoor starten we grub met de volgende opdracht:

sudo grub

Hiermee komen we in de grub-prompt waarmee we de juiste bootpartitie en hardeschijf selecteren voor het booten:

grub> root (hd0,0)
grub> setup (hd0)

Nu mis ik dus de opstartmogelijkheid om de testinstallatie te starten. Eigenlijk had ik dus de juiste regels vanuit de menu.lst vanaf /dev/sda5 moeten kopieren. Nu weet ik niet of ik er mee wegkom om enkel menu.lst aan te passen dus voor de zekerheid grub nogmaals geinstalleerd op hd0,0 (wat gelijkstaat aan /dev/sda1)

Dovecot update

Zo moet je ruim een week wachten om je update script te testen en zo krijg je er meteen een paar extra voor je kiezen:

Arkon wil update
Date: Today 07:00:19

dovecot-common dovecot-imapd

Meteen maar installeren dus:

Arkon:~# aptitude upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages will be upgraded:
  dovecot-common dovecot-imapd
2 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 1680kB of archives. After unpacking 20.5kB will be used.
Do you want to continue? [Y/n/?] y
Get:1 http://security.debian.org etch/updates/main dovecot-common 1.0.rc15-2etch4 [1133kB]
Get:2 http://security.debian.org etch/updates/main dovecot-imapd 1.0.rc15-2etch4 [547kB]
Fetched 1680kB in 3s (437kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 15696 files and directories currently installed.)
Preparing to replace dovecot-common 1.0.rc15-2etch3 (using .../dovecot-common_1.0.rc15-2etch4_i386.deb) ...
Stopping mail server: dovecot .
Unpacking replacement dovecot-common ...
Preparing to replace dovecot-imapd 1.0.rc15-2etch3 (using .../dovecot-imapd_1.0.rc15-2etch4_i386.deb) ...
Stopping mail server: dovecot .
Unpacking replacement dovecot-imapd ...
Setting up dovecot-common (1.0.rc15-2etch4) ...

Configuration file `/etc/dovecot/dovecot.conf'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : background this process to examine the situation
 The default action is to keep your current version.
*** dovecot.conf (Y/I/N/O/D/Z) [default=N] ?
You already have ssl certs for dovecot.
Starting mail server: dovecot.

Setting up dovecot-imapd (1.0.rc15-2etch4) ...
Starting mail server: dovecot.

Nog meer updates, lighttpd

Wederom staat er een update voor lighttpd klaar. Hopelijk lost dit meteen het niet reageren van de website op.

Arkon wil update
From: root
To: anywhere@localhost.net
Date: Today 07:00:22
lighttpd
Arkon:~# aptitude upgrade
Reading package lists... Done
Building dependency tree... Done
Reading extended state information
Initializing package states... Done
Building tag database... Done
The following packages will be upgraded:
lighttpd
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 289kB of archives. After unpacking 0B will be used.
Do you want to continue? [Y/n/?] y
Get:1 http://security.debian.org etch/updates/main lighttpd 1.4.13-4etch6 [289kB]
Fetched 289kB in 1s (247kB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 15696 files and directories currently installed.)
Preparing to replace lighttpd 1.4.13-4etch5 (using .../lighttpd_1.4.13-4etch6_i386.deb) ...
Stopping web server: lighttpd.
Unpacking replacement lighttpd ...
Setting up lighttpd (1.4.13-4etch6) ...
Starting web server: lighttpd.

Lighttpd staakt

Op de een of andere manier is me vanmorgen na het plaatsen van het update bericht lighttpd aan het staken geslagen. Totaal geen reactie meer.

Voor zover ik kan zien draait ie echter wel gewoon:

Arkon:~# ps -e | grep light
19975 ?        00:00:02 lighttpd

Zometeen de logs dus maar eens doorspitten om te kijken of ik daar nog iets in kan vinden. Met het volgende commando herstellen we de zaak weer:

Arkon:~# /etc/init.d/lighttpd restart
Stopping web server: lighttpd.
Starting web server: lighttpd.
Arkon:~# ps -e | grep light
29021 ?        00:00:00 lighttpd

Toevoeging 07-03-2008 om 20:08

Blijkbaar heb ik last gehad van een conflict tussen Lighttpd en aptitude. Na het posten of bewerken van een bericht bleef de webserver stil. Het process bleef lopen en ik kan in de logs niets vinden. Na het uitvoeren van de update reageert de webserver echter weer zoals het hoort.

Update script (2)

Het heeft even geduurd maar Arkon wil nu een update hebben. Zoals je hier kunt zien heb ik in navolging van Henk van de Kamer een update script geïnstalleerd. Heel veel kun je hier niet aan testen, zolang er geen update is krijg je ook geen melding. Ik heb dus de afgelopen anderhalve week regelmatig gekeken of er een update was terwijl ik nog geen mailtje had. Vanaf nu hoef ik dat niet meer te doen want het mailtje is er:

van: root
aan: anywhere@localhost.net
datum: 7 mrt. 2008 07:00
onderwerp: Arkon wil update
lighttpd

Vanavond dus meteen de update maar installeren.

Backup script

Backup was 1 van de meest belangrijke dingen die ik nog niet geregeld had. Ik heb nu een script overgenomen vanaf de site van Henk van de Kamer.

#!/bin/bash
# Aanpassingen:         Marcel Dijkerman
#
#       * MD 2008-02-26 Bestandslocatie's gewijzigd
#
# Original Author:      Henk van de Kamer (henk@vandekamer.nscom)
# Created:              08-02-2006
# Modified:             09-02-2006
#
# Algemene variabelen
#
pass="--password=geheim"

# Maak juiste back-up, 1e van de maand full, rest van de dagen een differential
#
cd /backup
if [ `date -d 'yesterday' +%-d` -eq 1 ]; then
  date > lastfull.txt
  tar -czf full.tgz /var/www/
  mysqldump --protocol=tcp --skip-opt $pass -A | gzip -9 > fulldb.gz
else
  tar -czf diff.tgz --newer "`cat lastfull.txt`" /var/www
  mysqldump --protocol=tcp --skip-opt $pass -A > diffdb
  zcat fulldb.gz | diff -cbB - diffdb | gzip -9 > diffdb.gz
  rm diffdb
fi

Uiteraard zijn de bestandslocatie’s van hem anders dus die zijn veranderd.

Meteen dit script ook maar toegevoegd in de crontab op een nachtelijk uur zodat ik niet alsnog een geautomatisch ding handmatig hoef te starten.

Na het toevoegen van dit berichtje kan ik meteen testen of het geheel naar behoren werkt.

Op het wensenlijstje staat nu nog het automagisch veranderen van de namen van de backupbestanden zodat daar een datum of weeknummer instaat en het geheel vervolgens offsite neerzetten. Ik heb op zich toegang tot de server van een vriend van me en die wil me daar vast de ruimte voor vrijmaken. Ik kan dan meteen de wederdienst voor hem bewijzen.