Da ich heute bei Uli einen IPCop aufsetzen muss, setz ich kurz meine Einstellungen hier rein – als Memo für die Konfiguration der Shalla Blacklist. Ich kann mir die Zusammenhänge zwischen manchen Kategoriennamen und deren Wirkung einfach nicht richtig merken.

Ältere IPCop Installationen verwenden evtl. noch andere Bezeichnungen. Da der Updatemechanismus die nicht mehr gepflegten Kategorien wohl nicht (immer?) selbst entfernt, muss hier gelegentlich von Hand nachgeholfen werden. Gespeichert werden die Einträge auf dem Cop hier:

/var/ipcop/urlfilter/blacklists

In der Datei global_usage ist jeweils eine kurze Beschreibung der Kategorien zu finden.

Zuerst auf dem Weboberfläche des Cops die Häkchen bei der entsprechenden Kategorie entfernen und [Speichern und Neustart] anklicken. Dann im oben genannten Verzeichnis als root mit

rm -r kategorienname/

die entsprechenden Unterverzeichnisse und deren Inhalte entfernen und die URL Filter Seite im Anschluss im Cop neu laden. Die Kategorie sollte dann verschwunden sein. Wer aus Versehen zu viel gelöscht hat führt ein Update der Filterliste durch, was dazu führt, dass die aus Versehen gelöschten Verzeichnisse wieder angelegt werden.

Alle Einträge, die auf der Weboberfläche vorgenommen werden, scheinen in die folgenden Dateien geschrieben zu werden:

/var/ipcop/urlfilter/settings
/var/ipcop/urlfilter/squidGuard.conf

Zwecks ‚em Überblick hier mal meine Einstellungen:

Auf unserem Root sind mehrere Nutzer angelegt, die sich nur über scp anmelden können. Damit dies auch im public key Verfahren inklusive Passwort für den Key und dann auch noch mit gFTP funktioniert, müssen die folgenden Schritte durchlaufen werden.

Zuerst einen neuen Schlüssel für den Nutzer erzeugen, was auch lokal auf dem Client geschehen kann. Dabei einen gesonderten Namen für den Key angeben, damit dieser nicht in id_dsa landet (im Beispiel unten ist dies /home/dirk/.ssh/scpnutzer_dsa):

dirk@lokal:~$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/dirk/.ssh/id_dsa): /home/dirk/.ssh/scpnutzer_dsa
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/dirk/.ssh/scpnutzer_dsa.
Your public key has been saved in /home/dirk/.ssh/scpnutzer_dsa.pub.
The key fingerprint is:
1a:7a:19:9d:86:fc:01:34:ad:c5:94:13:81:8f:76:c6 dirk@lokal

Diesen dann mit scp auf den Server schieben – und zwar von einem Account aus, der auch über SSH auf den Server darf (ist ja klar):

scp scpnutzer_dsa.pub dirk@www.server.de:/home/scpnutzer/.ssh/

Auf dem Server den gerade hochgeladenen public key im Verzeichnis .ssh in die Datei authorized_keys integrieren:

cat scpnutzer_dsa.pub >> authorized_keys

Jetzt die Nutzung von gFTP (sofern gewünscht) vorbereiten. Da gFTP nicht selbst mit public keys umgehen kann (soweit ich weiß), den key zuerst „laden“ mit Hilfe von ssh-add:

dirk@lokal:~/.ssh$ ssh-add /home/dirk/.ssh/scpnutzer_dsa
Enter passphrase for /home/dirk/.ssh/scpnutzer_dsa:
Identity added: /home/dirk/.ssh/scpnutzer_dsa (/home/dirk/.ssh/scpnutzer_dsa)

Ob alles funktioniert hat ist nach Eingabe von

dirk@loakl:~/.ssh$ ssh-add -l

zu sehen. Eine Liste der von ssh-add verwalteten Keys wird ausgegeben.

In gFTP selbst nun zuerst zu /FTP /Optionen /Netz und hier als „Voreingestelltes Protokoll“ den Eintrag SSH2 wählen. Dann in gFTP unter /FTP /Optionen /SSH und dort den Haken bei „Benötige SSH Nutzername/Passwort“ entfernen.

Der Zugriff mit gFTP sollte nun funktionieren. Wenn nicht, dann hilft eine Analyse mit Hilfe von scp und dem Schalter -v im Terminal – das gFTP Log selbst gibt meist wenig Brauchbares aus.

Die Dateien scpnutzer_dsa.pub und scpnutzer_dsa – wenn alles funktioniert – an den SCP Nutzer weitergeben (und dabei einschärfen, dass diese Dateien nicht verloren gehen dürfen). Nicht vergessen das Kennwort mitzuteilen 🙂

Quelle und weitere Informationen (vor allem zum Setup von SSH über public key auf dem Server selbst): http://wiki.ubuntuusers.de/SSH