Dies ist eine alte Version des Dokuments!
SKS Keyserver unter CentOS 6.x
Zur Verteilung und Abfrage von PGP-Schlüsseln bedienen wir uns am einfachsten eines OpenPGP Keyservers. In diesem Kapitel widmen wir uns nun eingehend mit der Installation eines SKS Keyservers unter CentOS 6.x.
Der große Vorteil des SKS-Keyservers ist sein einfaches und robustes Design, da der Server im wesentlichen aus zwei Prozessen besteht. Der erste (sks-db) übernimmt die Aufnahme neue Schlüssel, sowie die Ausgabe der gesuchten Schlüssel. Hierzu wird eine einfache Web-Schnittstelle zur Verfügung gestellt. Der zweite Serverprozess (sks-recon) kümmert sich um den automatischen Abgleich der lokalen Datenbank mit den in Verbindung stehenden Peering-Partnern.
Ein wesentlicher Vorteil des SKS-Keyservers ist, dass dieser aktuell und aktiv weiterentwickelt wird, sowie eine weitestgehende Unterstützung des OpenPGP-Standards inklusive PhotoIDs und Subkeys unterstützt.
Installation
Zur Installation unseres SKS-Keyservers benutzen wir am einfachsten das RPM-Paket aus dem Projekt Extra Packages for Enterprise Linux kurz EPEL. Dieses Repository binden wir in unserem Server wie im Kapitel Einbinden des EPEL Repository unter CentOS 6.x beschrieben in unser System ein.
Die Installation gestaltet sich somit sehr einfach, muss nur noch das Paket sks mit Hilfe von yum installiert werden.
# yum install sks -y
Was uns das Programmpaket alles mitbringt offenbart uns wie immer eine Abfrage mit Hilfe von rpm -qil.
# rpm -qil sks
Name : sks Relocations: (not relocatable) Version : 1.1.4 Vendor: Fedora Project Release : 1.el6 Build Date: Thu 21 Feb 2013 04:50:26 AM CET Install Date: Mon 11 Mar 2013 05:27:39 PM CET Build Host: buildvm-18.phx2.fedoraproject.org Group : System Environment/Daemons Source RPM: sks-1.1.4-1.el6.src.rpm Size : 2335743 License: GPLv2+ Signature : RSA/8, Fri 22 Feb 2013 06:16:30 PM CET, Key ID 3b49df2a0608b895 Packager : Fedora Project URL : http://code.google.com/p/sks-keyserver/ Summary : Synchronizing Key Server Description : SKS is a OpenPGP keyserver whose goal is to provide easy to deploy, decentralized, and highly reliable synchronization. /etc/rc.d/init.d/sks-db /etc/rc.d/init.d/sks-recon /usr/bin/sks /usr/bin/sks_add_mail /usr/bin/sks_build.sh /usr/sbin/sks-db /usr/sbin/sks-recon /usr/share/doc/sks-1.1.4 /usr/share/doc/sks-1.1.4/ANNOUNCEMENT /usr/share/doc/sks-1.1.4/BUGS /usr/share/doc/sks-1.1.4/CHANGELOG /usr/share/doc/sks-1.1.4/FILES /usr/share/doc/sks-1.1.4/LICENSE /usr/share/doc/sks-1.1.4/README.md /usr/share/doc/sks-1.1.4/TODO /usr/share/doc/sks-1.1.4/UPGRADING /usr/share/doc/sks-1.1.4/VERSION /usr/share/doc/sks-1.1.4/sampleConfig /usr/share/doc/sks-1.1.4/sampleConfig/DB_CONFIG /usr/share/doc/sks-1.1.4/sampleConfig/aliases.sample /usr/share/doc/sks-1.1.4/sampleConfig/crontab.sample /usr/share/doc/sks-1.1.4/sampleConfig/debian /usr/share/doc/sks-1.1.4/sampleConfig/debian/README /usr/share/doc/sks-1.1.4/sampleConfig/debian/forward.exim /usr/share/doc/sks-1.1.4/sampleConfig/debian/forward.postfix /usr/share/doc/sks-1.1.4/sampleConfig/debian/mailsync /usr/share/doc/sks-1.1.4/sampleConfig/debian/membership /usr/share/doc/sks-1.1.4/sampleConfig/debian/procmail /usr/share/doc/sks-1.1.4/sampleConfig/debian/sksconf /usr/share/doc/sks-1.1.4/sampleConfig/mailsync /usr/share/doc/sks-1.1.4/sampleConfig/membership /usr/share/doc/sks-1.1.4/sampleConfig/procmailrc /usr/share/doc/sks-1.1.4/sampleConfig/rc.sks /usr/share/doc/sks-1.1.4/sampleConfig/sksconf.minimal /usr/share/doc/sks-1.1.4/sampleConfig/sksconf.typical /usr/share/doc/sks-1.1.4/sampleWeb /usr/share/doc/sks-1.1.4/sampleWeb/HTML5 /usr/share/doc/sks-1.1.4/sampleWeb/HTML5/README /usr/share/doc/sks-1.1.4/sampleWeb/HTML5/index.html /usr/share/doc/sks-1.1.4/sampleWeb/HTML5/robots.txt /usr/share/doc/sks-1.1.4/sampleWeb/OpenPKG /usr/share/doc/sks-1.1.4/sampleWeb/OpenPKG/README /usr/share/doc/sks-1.1.4/sampleWeb/OpenPKG/index.html /usr/share/doc/sks-1.1.4/sampleWeb/OpenPKG/robots.txt /usr/share/doc/sks-1.1.4/sampleWeb/XHTML+ES /usr/share/doc/sks-1.1.4/sampleWeb/XHTML+ES/README /usr/share/doc/sks-1.1.4/sampleWeb/XHTML+ES/index.xhtml /usr/share/doc/sks-1.1.4/sampleWeb/XHTML+ES/robots.txt /usr/share/doc/sks-1.1.4/sampleWeb/XHTML+ES/script.es /usr/share/man/man8/sks.8.gz
Nicht von der Version im RPM-Paket verwirren lassen! Es handelt sich keineswegs um die Version 1.1.3 des SKS-Keyservers, sondern um Version 1.1.2!
Dokumentation
Die Dokumentation die mitgeliefert wird, findet sich im Verzeichnis /usr/share/doc/sks-1.1.3/. Die Datei README kann bei der weiteren Konfiguration wertvolle Hilfe Leisten.
README
# less /usr/share/doc/sks-1.1.3/README
- /usr/share/doc/sks-1.1.3/README
The following is an incomplete guide to compiling, setting up and using SKS. The documentation still needs work, but hopefully this is enough to get you started. -- Prerequisites -------------------------- There are a few prerequisites to building this code. You need: * ocaml-3.10.2 or later. Get it from http://www.ocaml.org * Berkeley DB version 4.6.* or later. You can find the appropriate versions at http://www.oracle.com/technetwork/database/berkeleydb/downloads/index.html -- Compilation and Installation ----------------------------- * Install OCaml and Berkeley DB When installing ocaml, make sure you do both the "make world" and the "make opt" steps before installing. The later makes sure you get the optimizing compilers. (do make opt.opt if you want faster compilation. You can then set the environment variables OCAMLC, OCAMLOPT and CALMP4O to ocamlc.opt, ocamlopt.opt and camlp4o.opt respectively.) If your vendor or porting project supplies prebuilt binaries and libraries for Berkeley DB, make sure to get the development package as you will need the correct version include files. * Copy Makefile.local.unused to Makefile.local, and edit to match your installation. * Compile make dep make all make all.bc # if you want the bytecode versions make install # puts executables in $PREFIX/bin, as defined # in Makefile.local There are some other useful compilation targets, mostly useful for development. - make doc creates a doc directory with ocamldoc-generated documentation of the individual modules. These are mostly useful as documentation to the source code, not a user's guide. - make modules.ps Creates a ps-file that shows the dependencies between different modules, and gives you a sense of the overall structure of the system. For this to work you need to have AT&T's graphviz installed, as well as python2. The python script that's used actually requires that python2 be called python2, rather than python. You can of course edit that script. -- Setup and Configuration --------------------- You need to set up a directory for the SKS installation. It will contain the database files along with configuration and log files. Configuration options can be passed in on the command-line or put in the "sksconf" file in the SKS directory. the -basedir option specifies the SKS directory itself, which defaults to the current working directory. * sksconf and commandline options The format of the sksconf file is simply a bunch of lines of the form: keyword: value The '#' character is used for comments, and blank lines are ignored. The keywords are just the command-line flags, minus the initial "-". The one thing you probably want no matter what is a line that says logfile: log which ensures that sks will output messages to recon.log and db.log respectively. * membership file If you want your server to gossip with others, you will need a membership file which tells the "sks recon" who else to gossip with. The membership file should look something like: epidemic.cs.cornell.edu 11370 athos.rutgers.edu 11370 ... This file should be called "membership", and should be stored in the SKS directory. Note that in order for synchronization to work, both hosts have to have each other in their membership lists. Send mail to <sks-devel@nongnu.org> to get other SKS administrators to add you to their membership lsits. IMPORTANT NOTE: if you include the server itself in the membership file, you should make sure that you also specify the "hostname" option, and that the selected hostname is exactly the same string listed in the membership file. Otherwise, the "sks recon" will try to synchronize with itself and will deadlock.p * outgoing PKS synchronization: mailsync file The mailsync file contains a list of email addresses of PKS keyservers. This file is important, because it ensures that keys submitted directly to an SKS keyserver are also forwarded to PKS keyservers. IMPORTANT: don't add someone to your mailsync file without getting their permission first! In order for outgoing email sync's to work, you need to specify a command to actually send the email out. The default is "sendmail -t -oi", but you may need something different. * incoming PKS synchronization Incoming PKS synchronization is less critical than outgoing, since as long as some SKS server gets the new data, it will be distributed to all. Having more hosts receive the incoming PKS syncs does, however, increase the fault-tolerance of the connection between the two systems. In order to get incoming mail working, you should pipe the appropriate incoming mail to the following command via procmail: "sks_add_mail sks_directory_name" Here's an example procmail entry: PATH=/path/of/sks/exectuables :0 * ^Subject: incremental | sks_add_mail sks_directory_name * built-in webserver You can server up a simple index page directly from the port you're using for HKP. This is done by creating a subdirectory in your SKS directory called "web". There, you can put an index file named "index.html", "index.htm", "index.xhtm", or "index.xhtml", supporting files with extensions .css, .es, or .js, and some image files with extensions jpg, jpeg, png or gif. Subdirectories will be ignored, as will filenames with anything other than alphanumeric characters and the '.' character. This is particularly useful if you want to run your webserver off of port 80. This can be done by using the -hkp_port command-line option. -- Building up the databases ------------------- - First, you need to get a keydump. If you're running a PKS server, you should be able to convince PKS to generate one for you. If you're starting from scratch, you'll need to download one from the net. You should contact the pgp keyserver list <pgp-keyserver-folk@flame.org> - in the SKS directory, put in a subdirectory called "dump" which contains the keydump files from which the database is to be built. - Run sks_build.sh. That script actually runs three utilities. You might want to edit sks_build.sh if you want to trade off speed for space usage. At the current settings, you could run out of ram if you try this with less then 256 megs of RAM. DO NOT DELETE THE "dump" DIRECTORY, even after the database is built. The original keys are not copied to the database, and so the dump must be left in place. -- Platform specific issues ---------------- FreeBSD: On FreeBSD it appears that libdb is named differently than on some other platforms. For that reason, you need to set the LIBDB environment value to "-ldb46" instead of "-ldb-4.6" for other platfomrs.
Manpage
Als eine weitere sehr hilfreiche Quelle sei die Manpage von sks genannt:
# man sks
sks(8) SKS OpenPGP Key server sks(8) NAME SKS - Synchronizing Key Server SYNOPSIS sks [options] -debug DESCRIPTION SKS is a OpenPGP keyserver whose goal is to provide easy to deploy, decentralized, and highly reliable synchronization. That means that a key submitted to one SKS server will quickly be distributed to all key servers, and even wildly out-of-date servers, or servers that experience spotty connectivity, can fully synchronize with rest of the system. The design of SKS is deliberately simple. The server consists of two single-threaded processes. The first, "sks db", fulfills the normal jobs associated with a public key server, such as answering web requests. The only special functionality of "sks db" is that it keeps a log summarizing the changes to the key database. "sks recon" does all the work with respect to reconciling hosts databases. "sks recon" keeps track of specialized summary information about the database, and can use that information to efficiently determine the differences between its database and that of another host. FEATURES Highly efficient and reliable reconciliation algorithm Follows RFC2440 and RFC2440bis carefully - unlike PKS, SKS supports new and old style packets, photoID packets, multiple subkeys, and pretty much everything allowed by the RFCs. Fully compatible with PKS system - can both send and receive syncs from PKS servers, ensuring seamless connectivity. Simple configuration: each host just needs a (partial) list of the other participating key servers. Gossip is used to distribute information without putting a heavy load an any one host. Supports HKP/web-based querying, and soon-to-be-standard machine readable indices OPTIONS SKS binary command options are as follows: db Initiates database server. recon Initiates reconciliation server. cleandb Apply filters to all keys in database, fixing some common problems. build Build key database, including body of keys directly in database. fastbuild -n [size] -cache [mbytes] Build key database, doesn’t include keys directly in database, faster than build. -n specifies the number of keydump files to read per pass when used with build and the multiple of 15,000 keys to be read per pass when used with fastbuild. -cache specifies the database cache to use in megabytes. pbuild -cache [mbytes] -ptree_cache [mbytes] Build prefix-tree database, used by reconciliation server, from key database. Allows for specification of cache for key database and for ptree database. dump #keys dumpdir Create a raw dump of the keys in the database. merge Adds key from key files to existing database. drop Drops key from database. update_subkeys [-n # of updates / 1000] Updates subkey keyid index to include all current keys. Only useful when upgrading versions 1.0.4 or before of SKS. help Prints the help message. ADDITIONAL OPTIONS You won’t need most of the options below for normal operation. These options can be given in basedir/sksconf or as command line option for the sks binary. -debug Debugging mode. -debuglevel Debugging level -- sets verbosity of logging. -q Number of bits defining a bin. -mbar Number of errors that can be corrected in one shot. -seed Seed used by RNG. -hostname Current hostname. -d Number of keys to drop at random when synchronizing. -n Number of keydump files to load at once. -max_internal_matches Maximum number of matches for most specific word in a multi-word search. -max_matches Maximum number of matches that will be returned from a query. -max_uid_fetches Maximum number of uid fetches performed in a verbose index query. -pagesize Pagesize in bytes for key db. -cache Cache size in megs for key db. -ptree_pagesize Pagesize in bytes for prefix tree db. -ptree_cache Cache size in megs for prefix tree db. -baseport Set base port number. -recon_port Set recon port number. -recon_address Set recon binding addresses. Can be a list of whitespace separated IP addresses or domain names. -hkp_port Set hkp port number. -hkp_address Set hkp binding addresses. Can be a list of whitespace separated IP addresses or domain names. -use_port_80 Have the HKP interface listen on port 80, as well as the hkp_port. -basedir Set base directory. -stdoutlog Send log messages to stdout instead of log file. -diskptree Use a disk-based ptree implementation. Slower, but requires far less memory. -nodiskptree Use in-mem ptree. -max_ptree_nodes Maximum number of allowed ptree nodes. Only meaningful if -diskptree is set. -prob Set probability. Used for testing code only. -recon_sync_interval Set sync interval for reconserver. -gossip_interval Set time between gossips in minutes. -dontgossip Don’t gossip automatically. Host will still respond to requests from other hosts. -db_sync_interval Set sync interval for dbserver. -checkpoint_interval Time period between checkpoints. -recon_checkpoint_interval Time period between checkpoints for reconserver. -ptree_thresh_mult Multiple of thresh which specifies minimum node size in prefix tree. -recon_thresh_mult Multiple of thresh which specifies minimum node size that is included in reconciliation. -max_recover Maximum number of differences to recover in one round. -http_fetch_size Number of keys for reconserver to fetch from dbserver in one go. -wserver_timeout Timeout in seconds for webserver requests. -reconciliation_timeout Timeout for reconciliation runs in minutes -stat_hour Hour at which to run database statistics. -initial_stat Runs database statistics calculation on boot. -reconciliation_config_timeout Set timeout in seconds for initial exchange of config info in reconciliation. -missing_keys_timeout Timeout in seconds for get_missing_keys. -command_timeout Timeout in seconds for commands set over command socket. -sendmail_cmd Command used for sending mail. -from_addr From address used in synchronization emails used to communicate with PKS. -dump_new_only When doing a database dump, only dump new keys, not keys already contained in a keydump file. -max_outstanding_recon_requests Maximum number of outstanding requests in reconciliation. -membership_reload_interval Maximum interval (in hours) at which membership file is reloaded. -disable_mailsync Disable sending of PKS mailsync messages. ONLY FOR STANDALONE SERVERS! THIS IS THE MECHANIASM FOR SENDING UPDATES TO NON-SKS SERVERS. -disable_log_diffs Disable logging of recent hashset diffs. --help, -help Displays list of options. FILES Information about important files located in your SKS basedir. bin/sks The main SKS executable. bin/sks_add_mail The executable responsible for parsing incoming mails from PKS key servers. bin/sks_build.sh Script to generate an initial database. mailsync The mailsync should contains a list of email addresses of PKS keyservers. This file is important, because it ensures that keys submitted directly to an SKS keyserver are also forwarded to PKS keyservers. IMPORTANT : don’t add someone to your mailsync file without getting their permission first! membership With SKS, two hosts can efficiently compare their databases then repair whatever differences are found. In order to set up reconciliation, you first need to find other SKS servers that will agree to gossip with you. The hostname and port of the server that has agreed to do so should be added to this file. sksconf The configuration file for your SKS server. EXAMPLES membership keyserver.ahost.org 11370 # Comments are allowed keyserver.foo.org 11370 # Another host with default ports sksconf membership_reload_interval: 1 initial_stat: hostname: keyserver.example.com from_addr: pgp-public-keys@keyserver.example.com Procmail PATH=/path/of/sks/exectuables :0 * ^Subject: incremental | /path/of/sks_add_mail /path/to/sks/directory /etc/aliases pgp-public-keys: "|/path/of/sks_add_mail /path/to/sks/directory" SEE ALSO The SKS website is located at http://minskyprimus.net/sks/. AUTHOR The first draft was written by Thomas Sjogren <thomas@northernsecurity.net>. 0.1 2012-01-24 sks(8)
Konfiguration
Die Konfiguration unseres sks-Keyservers gestaltet sich unter CentOS 6.x etwas aufwändiger, als noch unter CentOS 5.x.
Die Qualität des EPEL-Paketes hat sich im Januar 2012 erheblich verbessert, so dass sich die Konfiguration nunmehr doch recht schnell erledigt hat. Erstaunlicher Weise befinden sich in den Startsrcripten ein eigenartiger und bekannter Name. 
Konfigurations- und Arbeitsverzeichnis anlegen
Im nächsten Schritt legen wir uns unser Zielverzeichnis für unsere Konfigurationsdateien an.
# mkdir /etc/sks
# mkdir /srv/sks
Anschließend passen wir die Dateiberechtigungen unseres Zeilverzeichnisses an.
# chown sks:sks /etc/sks
# chown sks:sks /srv/sks
Konfigurationsdateien anlegen
sksconf
# vim /etc/sks/sksconf
- /etc/sks/sksconf
# Debuglevel 4 is default (max. is 10) debuglevel: 4 # Set the hostname of this server #hostname: keyserver.mydomain.net # Django: 2011-01-25 hostname: keyserver.nausch.org # Set contact email-address of this server #server_contact: # Django: 2013-03-15 server_contact: michael@nausch.org # Bind addresses #hkp_address: 1.2.3.4 #recon_address: 1.2.3.4 # Use sendmail #sendmail_cmd: /usr/sbin/sendmail -t -oi -fpks-admin@mydomain.net # From address in sync emails to PKS #from_addr: pks-admin@mydomain.net # Django: 2011-01-25 #from_addr: pks-admin@nausch.org from_addr: keysync@keyserver.nausch.org # When to calculate statistics #stat_hour: 2 # Django: 2011-01-25 stat_hour: 0 # Django: 2012-01-18 # Runs database statistics calculation on boot initial_stat:
Die Dateiberechtigungen passen wir nun noch kurz an.
# chown sks:sks /etc/sks/sksconf
mailsync
# vim /etc/sks/mailsync
- /etc/sks/mailsync
# /etc/sks/mailsync # # <mailaddr> # Django 01.02.2011 # deaktiviert da Zielhost down # pgp-public-keys@keyserver.kjsl.com
Auch hier passen wir noch die Dateiberechtigung passend an.
# chown sks:sks /etc/sks/mailsync
membership
Die dritte Konfigurationsdatei beinhaltet eine Liste sämtlicher SKS-Knotenserver mit denen wir unsere Schlüssel austauschen.
# vim /etc/sks/membership
- /etc/sks/membership
# /etc/sks/membership # # <hostname/addr> <recon-port> keyserver.nausch.org 11370 # Michael Nausch <michael@nausch.org> 0x2384C849
Wie auch schon bei den vorangegangenen beiden Konfigurationsdateien passen wir auch hier die Dateiberechtigungen noch an.
# chown sks:sks /etc/sks/membership
Logverzeichnis anlegen
Damit für spätere Übrwachungs- und ggf. Fehlersuchaufgaben auch entsprechende Logdateien geschrieben werden können, legen wir uns noch das passende Verzeichnis an.
# mkdir /var/log/sks
Die Datei- und Verzeichnis-Berechtigungen passen wir auch hier an.
# chown sks:sks /var/log/sks/
WEB-Verzeichnis anlegen
Unser SKS-Keyserver wird später ein Webformular präsentieren, über das folgende Funktionen zur Verfügung gestellt werden.
Für dieses Webseite legen wir uns nun ein passendes Verzeichnis an.
# mkdir /srv/sks/web/
Die Datei- und Verzeichnis-Berechtigungen passen wir auch hier an.
# chown sks:sks /srv/sks/web/
Abschließend laden wir uns die noch die Keyring-Graphik auf unseren Server.
# wget http://keyserver.nausch.org/keyring.png
Ein passendes favicon- laden wir uns bei Bedarf auch gleich noch auf unseren SKS-Keyserver.
# wget http://keyserver.nausch.org/favicon.ico
Als Muster für die Webseite können wir uns folgender Vorlage bedienen, die wir entsprechend individualisieren und unseren Bedürfnissen anpassen.
- /srv/sks/web/index.html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>SKS OpenPGP Keyserver Suchmaschine</title> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#eeeeee" link="#000099" vlink="#990099" alink="#000099"> <table cellpadding="2" cellspacing="2" border="0" width="100%" > <tbody> <tr> <td valign="center"> <center> <h1>SKS OpenPGP Keyserver</h1> <h2>@keyserver.nausch.org</h2> <a href="http://keyserver.nausch.org:11371/pks/lookup?op=stats">Keyserver Statistik</a> </center> </td> <td> <img src="keyring.png" alt="keys" width="175" align="left"> </td> </tr> </tbody> </table> <br> <table cellpadding="2" cellspacing="2" border="1" width="100%" bgcolor="#dddddd"> <tbody> <tr> <td valign="top"> <h3>Einen Schlüssel suchen</h3> <p> Sie können hier bequem nach einen Schlüssel suchen. Geben Sie hierzu beliebige Zeichen der UserID an. Möchten Sie nach die Key-ID als hexadezimale Zahlenfolge eingeben, stellen Sie einfach der schlüssel-ID die Zeichenfolge <code>("0x...")</code> voran. </p> <form action="http://keyserver.nausch.org:11371/pks/lookup" method="get"> gesuchte Zeichenfolge: <input name="search" size="40"> <br> <br> PGP fingerprints der Schlüssel anzeigen <input type="checkbox" name="fingerprint"> <br> SKS Full-Key Hashes anzeigen <input type="checkbox" name="hash"> <br> <br> Such- und Anzeigeoptionen: <br> <input type="radio" name="op" value="index"> Ausgabe der gefundenen Schlüssel in Kurzform<br> <input type="radio" name="op" value="vindex" CHECKED> <b>ausführliche</b> Ausgabe der gefunden Schlüssel anzeigen <br> <input type="radio" name="op" value="get"> Schlüssel im Format ASCII-armored anzeigen <br> <input type="radio" name="op" value="hget"> Schlüssel an Hand von Full-Key Hashes suchen <br> <br> <input type="reset" value="Eingabefeld löschen"> <input type="submit"> </form> </td> </tr> <tr> <td valign="top"> <h3>Schlüssel zum Keyserver übertragen</h3> Sie können Ihren Schlüssel zum Keyserver hochladen. Fügen Sie hierzu einfach Ihren public-key ein, den Sie mit <p> <p> <b>gpg – export –armor keyID > public-key.asc</b> </p> generiert haben (ASCII armored Version) und klicken auf den Button <u>Diesen Schlüssel zum Keyserver übertragen!</u>. </p> <form action="http://keyserver.nausch.org:11371/pks/add" method="post"> <textarea name="keytext" rows="20" cols="66"></textarea> <br> <input type="reset" value="Eingabefeld löschen"> <input type="submit" value="Diesen Schlüssel zum Keyserver übertragen!"> </form> </td> </tr> </tbody> </table> <p> Dieser OpenPGP KeyServer läuft mit Hilfe von SKS, der <a href="http://code.google.com/p/sks-keyserver/">Synchronizing Key Server</a> Software. </p> <p> Wenn sie mit meinem Keyserver eine Partnerschaft zum Schlüsselaustausch eingehen möchten, wenn Sie Anmerkungen oder Fragen haben, oder wenn Sie den Administrator des Servers anderweitig kontaktieren möchten, dann schicken Sie einfach eine eMail an <a href="mailto:michael@nausch.org?subject=SKS Keyserver"> Michael Nausch <michael<nbr>@<nbr>nausch.org></a>. </p> <p> Benutzen Sie zum Verschlüsseln Ihrer Nachricht meinen public-key <a href="http://keyserver.nausch.org:11371/pks/lookup?search=0x2384C849&fingerprint=on&op=index"> <b><u>0x2384C849</u></b> </a>, den Sie hier auf dem Keyserver abfragen können. </p> <hr> </body> </html>
Bei Bedarf passen wir nun diese Datei unserer Umgebung an.
# vim /srv/sks/web/index.html
SKS-Sysconfig Definition
Wollen wir unseren SKS-Keyserver nicht unter Root-Rechten laufen lassen, legen wir uns noch eine passende Konfigrationsdatei im Verzeichnis /etc/sysconfig an.
# vim /etc/sysconfig/sks
- /etc/sysconfig/sks
# /etc/sysconfig/sks # # User to run the daemon as RUN_AS="sks" # # Add extra daemon options here # OPTIONS=""
Logrotate Definition
Damit uns unser Logverzeichnis nicht voll läuft, werden wir unseren SKS-Server so einstellen, dass er in regelmäßigen Abständen das Logfile archiviuert und ein neues anlegt. Hierzu legen wir uns im Verzeichnis /etc/logrotate.d/ die Datei sks mit nachfolgendem Inhalt an.
# vim /etc/logrotate.d/sks
- /etc/logrotate.d/sks
/var/log/sks/*.log { rotate 4 weekly notifempty missingok delaycompress sharedscripts postrotate /bin/kill -HUP `cat /var/run/sks-db.pid 2>/dev/null` 2>/dev/null || true /bin/kill -HUP `cat /var/run/sks-recon.pid 2>/dev/null` 2>/dev/null || true endscript }
Startscripte kontrollieren
Die nachfolgenden Skripten sind nunmehr im EPEL-RPM-Paket enthalten. Irgendwie kommen dem geneigtem Leser diese sehr bekannt vor. 
sks-db
Das Datenbank-Startupscript wird im RPM Paket mitgeliefert, es sind i.d.R. keine weiteren Änderungen am Script nötig.
# less /etc/init.d/sks-db
- /etc/init.d/sks-db
#!/bin/bash # # sks-db This shell script takes care of starting and stopping # the SKS database server. # # chkconfig: - 89 11 # description: SKS is the OpenPGP Synchronizing Key Server. # processname: sks-db # config: /etc/sks/sksconf # pidfile: /var/run/sks-db.pid # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 1 # Defines DESC="the SKS Database Server" PROG="sks-db" EXEC="/usr/sbin/${PROG}" LOCK="/var/lock/subsys/${PROG}" PIDF="/var/run/${PROG}.pid" CONF="/srv/sks/sksconf" # Include config if [ -s /etc/sysconfig/sks ]; then . /etc/sysconfig/sks fi # Further defines RUN_AS="${RUN_AS:-sks}" SKS_SHUT="${SKS_SHUT:-60}" SKS_CMD="`echo ${PROG} | cut -d'-' -f2`" # Check for binaries and configs [ -x ${EXEC} ] || exit 5 [ -f ${CONF} ] || exit 6 start() { # Start daemons. cd /srv/sks/ echo -n $"Starting ${DESC}: " # daemon --user=${RUN_AS} ${EXEC} ${SKS_CMD} -debuglevel 4 -hostname key-server.nausch.org -basedir /var/lib/sks -stat_hour 1 2\>/dev/null \& daemon --user=${RUN_AS} ${EXEC} ${SKS_CMD} 2\>/dev/null \& # daemon --user=${RUN_AS} ${EXEC} ${SKS_CMD} ${OPTIONS} 2\>/dev/null \& RETVAL=${?} [ ${RETVAL} -eq 0 ] && { touch ${LOCK} sleep 3 PID=`pidof -o %PPID ${PROG}` RETVAL=${?} [ ${RETVAL} -eq 0 ] && echo ${PID} >${PIDF} } echo return ${RETVAL} } stop() { # Stop daemons. echo -n $"Shutting down ${DESC}: " PID=`pidof -o %PPID ${PROG}` RETVAL=${?} [ ${RETVAL} -eq 0 ] && { kill -TERM ${PID} TIMEOUT=0 while pidof -o %PPID ${PROG} >/dev/null; do if [ ${TIMEOUT} -ge ${SKS_SHUT} ]; then RETVAL=1 break else sleep 5 && echo -n "." TIMEOUT=$((TIMEOUT+5)) fi done [ ${RETVAL} -eq 0 ] && rm -f ${LOCK} ${PIDF} } [ ${RETVAL} -eq 0 ] && success $"${PROG} shutdown" || failure $"${PROG} shutdown" echo return ${RETVAL} } restart() { stop sleep 2 start } force_reload() { restart } rh_status() { status ${PROG} } rh_status_q() { rh_status >/dev/null 2>&1 } # See how we were called. case "${1}" in start) rh_status_q && exit 0 ${1} ;; stop) rh_status_q || exit 0 ${1} ;; restart) ${1} ;; force-reload) force_reload ;; status) rh_status ;; condrestart|try-restart) rh_status_q || exit 0 restart ;; *) echo $"Usage: ${PROG} {start|stop|status|restart|try-restart|force-reload}" exit 2 esac exit ${?}
sks-recon
Auch das SKS reconciliation server-Startupscript wird nunmehr im EPEL-RPM-Paket mitgeliefert.
# less /etc/init.d/sks-recon
- /etc/init.d/sks-recon
#!/bin/bash # # sks-recon This shell script takes care of starting and stopping # the SKS reconciliation server. # # chkconfig: - 89 11 # description: SKS is the OpenPGP Synchronizing Key Server. # processname: sks-recon # config: /srv/sks/sksconf # pidfile: /var/run/sks-recon.pid # Source function library. . /etc/rc.d/init.d/functions # Source networking configuration. . /etc/sysconfig/network # Check that networking is up. [ ${NETWORKING} = "no" ] && exit 1 # Defines DESC="the SKS Reconciliation Server" PROG="sks-recon" EXEC="/usr/sbin/${PROG}" LOCK="/var/lock/subsys/${PROG}" PIDF="/var/run/${PROG}.pid" CONF="/srv/sks/sksconf" # Include config if [ -s /etc/sysconfig/sks ]; then . /etc/sysconfig/sks fi # Further defines RUN_AS="${RUN_AS:-sks}" SKS_SHUT="${SKS_SHUT:-60}" SKS_CMD="`echo ${PROG} | cut -d'-' -f2`" # Check for binaries and configs [ -x ${EXEC} ] || exit 5 [ -f ${CONF} ] || exit 6 start() { # Start daemons. cd /srv/sks/ echo -n $"Starting ${DESC}: " # daemon --user=${RUN_AS} ${EXEC} ${SKS_CMD} -debuglevel 4 -hostname key-server.nausch.org -basedir /var/lib/sks -stat_hour 1 2\>/dev/null \& daemon --user=${RUN_AS} ${EXEC} ${SKS_CMD} 2\>/dev/null \& # daemon --user=${RUN_AS} ${EXEC} ${SKS_CMD} ${OPTIONS} 2\>/dev/null \& RETVAL=${?} [ ${RETVAL} -eq 0 ] && { touch ${LOCK} sleep 3 PID=`pidof -o %PPID ${PROG}` RETVAL=${?} [ ${RETVAL} -eq 0 ] && echo ${PID} >${PIDF} } echo return ${RETVAL} } stop() { # Stop daemons. echo -n $"Shutting down ${DESC}: " PID=`pidof -o %PPID ${PROG}` RETVAL=${?} [ ${RETVAL} -eq 0 ] && { kill -TERM ${PID} TIMEOUT=0 while pidof -o %PPID ${PROG} >/dev/null; do if [ ${TIMEOUT} -ge ${SKS_SHUT} ]; then RETVAL=1 break else sleep 5 && echo -n "." TIMEOUT=$((TIMEOUT+5)) fi done [ ${RETVAL} -eq 0 ] && rm -f ${LOCK} ${PIDF} } [ ${RETVAL} -eq 0 ] && success $"${PROG} shutdown" || failure $"${PROG} shutdown" echo return ${RETVAL} } restart() { stop sleep 2 start } force_reload() { restart } rh_status() { status ${PROG} } rh_status_q() { rh_status >/dev/null 2>&1 } # See how we were called. case "${1}" in start) rh_status_q && exit 0 ${1} ;; stop) rh_status_q || exit 0 ${1} ;; restart) ${1} ;; force-reload) force_reload ;; status) rh_status ;; condrestart|try-restart) rh_status_q || exit 0 restart ;; *) echo $"Usage: ${PROG} {start|stop|status|restart|try-restart|force-reload}" exit 2 esac exit ${?}
Workaround für SKS -basedir option
Laut dem Abschnitt Setup and Configuration aus der Programmdokumentation /usr/share/doc/sks-1.1.3/README arbeitet der SKS Keyserver mit der Option basedir. Dieses lautet bei der Installation aus dem epel-RPM einfach /srv/sks.
-- Setup and Configuration --------------------- You need to set up a directory for the SKS installation. It will contain the database files along with configuration and log files. Configuration options can be passed in on the command-line or put in the "sksconf" file in the SKS directory. the -basedir option specifies the SKS directory itself, which defaults to the current working directory.
Da wir aber, wie unter Linux üblich die Konfigurationsdateien unter /etc/ und die Logdateien unter /var/log/ vorfinden wollen, operieren wir bei unserem SKS-Keyserver mit einfachen symbolischen Links.
/etc/sks/
Für die drei zuvor angelegten Konfigurationsdateien setzen wir nun jeweils einen symlink.
# ln -s /etc/sks/mailsync /srv/sks/mailsync
# ln -s /etc/sks/membership /srv/sks/membership
# ln -s /etc/sks/sksconf /srv/sks/sksconf
/var/log/sks/
Die beiden Serverprozesse schreiben jeweils ein eigenes logfile:
- db.log
- recon.log
Diese beiden Logdateien legen wir nun als leere Files an:
# touch /var/log/sks/db.log
# touch /var/log/sks/recon.log
Die Dateiberechtigung passen wir auch noch an.
# chown sks.sks /var/log/sks/db.log
# chown sks.sks /var/log/sks/recon.log
Anschließend setzen wir auch hier jeweils einen symbolischen link in Richtung des basedir des SKS-Keyservers.
# ln -s /var/log/sks/db.log /srv/sks/db.log
# ln -s /var/log/sks/recon.log /srv/sks/recon.log
SKS-Zugriff via Port 80
Hat man eine entsprechende Anzahl von Nutzern, denen der Zugriff auf Port 11371 auf Grund von Sicherheits- und Proxyeinstellungen verwehrt ist, so haben diese natürlich ein Problem den SKS-Keyserver zu nutzen.
Aber auch diesen Anwendern kann geholfen werden. Wir nutzen hierzu einfach die rewrite-Eigenschaften eines zur Verfügung stehenden Apache-Webservers.
vHost-Konfig
Wie legen uns hierzu einen eigenen vHost auf unserem Webserver an - hierzu editieren wir unsere Konfigurationsdatei /etc/httpd/conf.d/vhosts.conf
# vim /etc/httpd/conf.d/vhosts.conf
# # key-server.nausch.org # <VirtualHost *:80> ServerAdmin webmaster@nausch.org ServerName keyserver.nausch.org:80 ServerAlias keyserver.nausch.org *.key-server.nausch.org ServerPath / <Location /> Options -Indexes FollowSymLinks Order Allow,Deny Allow from all </Location> <IfModule mod_proxy.c> RewriteEngine On RewriteLogLevel 1 ProxyRequests Off RewriteRule ^/(.*) http://sks-keyserverhost:11371/$1 [P,L] RewriteRule ^/pks/(.*) http://sks-keyserverhost:11371/pks/$1 [P,L] RewriteRule ^:11371/(.*) http://sks-keyserverhost:11371/pks/$1 [P,L] </IfModule> DirectoryIndex index.html ErrorLog logs/keyserver_error.log CustomLog logs/keyserver_access.log combined </VirtualHost>
Anschließend starten wir den Webserver einmal durch.
# service httpd condrestart
index.html
In der SKS-Webserver Datei /srv/sks/web/index.html passen wir nun noch die Portangaben an, d.h. wir entfernen dort die Portangaben :11371.
# vim /srv/sks/web/index.html
- /srv/sks/web/index.html
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>SKS OpenPGP Keyserver Suchmaschine</title> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body text="#000000" bgcolor="#eeeeee" link="#000099" vlink="#990099" alink="#000099"> <table cellpadding="2" cellspacing="2" border="0" width="100%" > <tbody> <tr> <td valign="center"> <center> <h1>SKS OpenPGP Keyserver</h1> <h2>KVM based System</h2> <h2>@keyserver.nausch.org</h2> <a href="http://keyserver.nausch.org/pks/lookup?op=stats">Keyserver Statistik</a> </center> </td> <td> <img src="keyring.png" alt="keys" width="175" align="left"> </td> </tr> </tbody> </table> <br> <table cellpadding="2" cellspacing="2" border="1" width="100%" bgcolor="#dddddd"> <tbody> <tr> <td valign="top"> <h3>Einen Schlüssel suchen</h3> <p> Sie können hier bequem nach einen Schlüssel suchen. Geben Sie hierzu beliebige Zeichen der UserID an. Möchten Sie nach die Key-ID als hexadezimale Zahlenfolge eingeben, stellen Sie einfach der schlüssel-ID die Zeichenfolge <code>("0x...")</code> voran. </p> <form action="http://keyserver.nausch.org:11371/pks/lookup" method="get"> gesuchte Zeichenfolge: <input name="search" size="40"> <br> <br> PGP fingerprints der Schlüssel anzeigen <input type="checkbox" name="fingerprint"> <br> SKS Full-Key Hashes anzeigen <input type="checkbox" name="hash"> <br> <br> Such- und Anzeigeoptionen: <br> <input type="radio" name="op" value="index"> Ausgabe der gefundenen Schlüssel in Kurzform<br> <input type="radio" name="op" value="vindex" CHECKED> <b>ausführliche</b> Ausgabe der gefunden Schlüssel anzeigen <br> <input type="radio" name="op" value="get"> Schlüssel im Format ASCII-armored anzeigen <br> <input type="radio" name="op" value="hget"> Schlüssel an Hand von Full-Key Hashes suchen <br> <br> <input type="reset" value="Eingabefeld löschen"> <input type="submit"> </form> </td> </tr> <tr> <td valign="top"> <h3>Schlüssel zum Keyserver übertragen</h3> Sie können Ihren Schlüssel zum Keyserver hochladen. Fügen Sie hierzu einfach Ihren public-key ein, den Sie mit <p> <p> <b>gpg – export –armor keyID > public-key.asc</b> </p> generiert haben (ASCII armored Version) und klicken auf den Button <u>Diesen Schlüssel zum Keyserver übertragen!</u>. </p> <form action="http://keyserver.nausch.org/pks/add" method="post"> <textarea name="keytext" rows="20" cols="66"></textarea> <br> <input type="reset" value="Eingabefeld löschen"> <input type="submit" value="Diesen Schlüssel zum Keyserver übertragen!"> </form> </td> </tr> </tbody> </table> <p> Dieser OpenPGP KeyServer läuft mit Hilfe von SKS, der <a href="http://code.google.com/p/sks-keyserver/">Synchronizing Key Server</a> Software. </p> <p> Wenn sie mit meinem Keyserver eine Partnerschaft zum Schlüsselaustausch eingehen möchten, wenn Sie Anmerkungen oder Fragen haben, oder wenn Sie den Administrator des Servers anderweitig kontaktieren möchten, dann schicken Sie einfach eine eMail an <a href="mailto:michael@nausch.org?subject=SKS Keyserver"> Michael Nausch <michael<nbr>@<nbr>nausch.org></a>. </p> <p> Benutzen Sie zum Verschlüsseln Ihrer Nachricht meinen public-key <a href="http://keyserver.nausch.org/pks/lookup?search=0x2384C849&fingerprint=on&op=index"> <b><u>0x2384C849</u></b> </a>, den Sie hier auf dem Keyserver abfragen können. </p> <hr> </body> </html>
Somit können nun die Anwender, die nur Webzugriff via Port 80 nutzen dürfen, den SKS-Keyserver über den Umweg um unseren Apache Webserver nutzen: http://keyserver.nausch.org Der direkte Zugriff via Port 11371 funktioniert natürlich weiterhin: http://keyserver.nausch.org/:11371
Datenbank initial befüllen
Download Keydump
Zur Erstbefüllung unseres SKS-Keyservers benötigen wir ein Dumpfile der kompletten SKS-Datenbank. Ohnen einen solchen Datenbank-Backup müssten sonst alle Schlüssel von den einzelnen Peering-Partnern geholt werden. Dies würde diese unnötig belasten und auch die Zeitspanne bis dies erledigt wäre, wäre kaum überschaubar. Beinhaltet doch die Datenbank mit Stand 27.12.2011 3.026.036 Schlüssel und täglich werden es mehr!
Wir legen uns also ein temporäres Verzeichnis für den Empfang der Dumpfiles an.
# mkdir /srv/sks/dump
Die Berechtigungen passen wir für das Verzeichnis auch noch an.
Anschließend wechseln wir in das Zielverzeichnis.
# cd /srv/sks/dump
Im dritten Schritt holen wir uns nun das Datenbankbackup, das in einzelne 20 MB große Häppchen aufgeteilt wurde auf unseren Server. Bis die über 4,6 GB Daten auf unseren Rechner geladen wurden, wird es ein paar Stunden dauern, je nach zur Verfügung stehender Bandbreite. Ein paar Kaffee oder CLUB-MATE sollte man hierzu griffbereit haben. ;)
# wget --recursive --timestamping --level=1 --cut-dirs=3 --no-host-directories http://keyserver.borgnet.us/dump/
Sind alle Dateien auf unseren Server geladen überprüfen wir nun noch die MD5-Checksummen, die uns unser Quellserver entsprechend bereitstellt MD5SUMS.
# md5sum -c /srv/sks/dump/MD5SUMS
Datenbank mit Hilfe des Keydump anlegen
Sind alle Dateien fehlerfrei auf unseren Server heruntergeladen worden, ist es an der Zeit die lokale Datenbank zu bauen. Hierzu wechseln wir erst einmal in das Stammverzeichnis unserer SKS-Installation /srv/sks.
# cd /srv/sks
Dort starten wir das Script sks_build.sh welches uns bei der Installation unseres SKS-RPMs mitgeliefert wurde. Hat unser Server nur begrenzt Ressourcen wie CPU und RAM zur Verfügung, so müssen wir die Werte beim Aufruf von fastbuild und pbuild unseren Systemressourcen unseres Servers anpassen.
- /usr/bin/sks_build.sh
#!/bin/bash # SKS build script. # cd to directory with "dump" subdirectory, and run # You might want to edit this file to reduce or increase memory usage # depending on your system ask_mode() { echo "Please select the mode in which you want to import the keydump:" echo "" echo "1 - fastbuild" echo " only an index of the keydump is created and the keydump cannot be" echo " removed." echo "" echo "2 - normalbuild" echo "" echo " all the keydump will be imported in a new database. It takes longer" echo " time and more disk space, but the server will run faster (depending" echo " from the source/age of the keydump)." echo " The keydump can be removed after the import." echo "" echo -n "Enter enter the mode (1/2): " read case "$REPLY" in 1) mode="fastbuild" ;; 2) mode="build /srv/sks/dump/*.pgp" ;; *) echo "Option unknown. bye!" exit 1 ;; esac } fail() { echo Command failed unexpectedly. Bailing out; exit -1; } ask_mode echo "=== Running (fast)build... ===" if ! /usr/bin/sks $mode -n 10 -cache 100; then fail; fi echo === Cleaning key database... === if ! /usr/bin/sks cleandb; then fail; fi echo === Building ptree database... === if ! /usr/bin/sks pbuild -cache 20 -ptree_cache 70; then fail; fi echo === Done! ===
Mit dem Aufruf des Shellscriptes sks_build.sh starten wir den Import des Keydumps. Als erstes werden wir gefragt, ob wir
- fastbuild Den Keydump behalten und lediglich den Datenbankindex anlegen lassen wollen
- normalbuild die Datenbank komplett neu bauen wollen.
Den Bearbeitungsstand des Datenbankbaus kann man bei Bedarf in folgenden Logdateien verfolgen:
- fastbuild.log
- clean.log
- pbuild.log
# /usr/bin/sks_build.sh
Please select the mode in which you want to import the keydump: 1 - fastbuild only an index of the keydump is created and the keydump cannot be removed. 2 - normalbuild all the keydump will be imported in a new database. It takes longer time and more disk space, but the server will run faster (depending from the source/age of the keydump). The keydump can be removed after the import. Enter enter the mode (1/2): 2 === Running (fast)build... === Loading keys...done DB time: 0.75 min. Total time: 0.83 min. Loading keys...done DB time: 0.91 min. Total time: 1.78 min. Loading keys...done DB time: 0.86 min. Total time: 1.59 min. Loading keys...done DB time: 0.85 min. Total time: 1.90 min. Loading keys...done DB time: 1.16 min. Total time: 2.05 min. Loading keys...done DB time: 0.85 min. Total time: 2.43 min. Loading keys...done DB time: 0.88 min. Total time: 2.29 min. Loading keys...done DB time: 0.83 min. Total time: 2.48 min. Loading keys...done DB time: 0.88 min. Total time: 2.68 min. Loading keys...done DB time: 0.93 min. Total time: 2.53 min. Loading keys...done DB time: 1.55 min. Total time: 3.23 min. Loading keys...done DB time: 1.15 min. Total time: 3.06 min. Loading keys...done DB time: 1.10 min. Total time: 3.92 min. Loading keys...done DB time: 1.65 min. Total time: 3.23 min. Loading keys...done DB time: 2.26 min. Total time: 4.68 min. Loading keys...done DB time: 1.65 min. Total time: 4.56 min. Loading keys...done DB time: 1.45 min. Total time: 4.02 min. Loading keys...done DB time: 1.18 min. Total time: 3.98 min. Loading keys...done DB time: 3.96 min. Total time: 6.27 min. Loading keys...done DB time: 1.51 min. Total time: 3.71 min. Loading keys...done DB time: 0.32 min. Total time: 0.37 min. === Cleaning key database... === === Building ptree database... === === Done! ===
Achtung: Das Verzeichnis dump darf auf keinen Fall gelöscht werden, wenn man sich entschlossen hat, lediglich einen fastbuild, als den Datenbankindex erstellt hat. Die originalen Schlüsseldaten werden nämlich nicht in die Datenbank kopiert - diese verbleiben nach wie vor im Verzeichnis dump!
Nachdem wir unsere Datenbank nur 1x bauen, verschieben wir wir die Logfiles, die beim Anlegen der Datenbank erzeugt wurden, einfach an Ort und Stelle, nämlich nach /var/log/sks/.
# mv /srv/sks/*log /var/log/sks/
Da unser Keyserver mit den Rechten des Users sks laufen wird, „schenken“ wir nun genau diesem User die neu generierte Datenbank.
# chown sks.sks /srv/sks/ -R
Paketfilter anpassen
Damit nun Anfragen an unseren SKS-Keyserver von diesem auch beantwortet werden können, werden wir noch unseren Paketfilter anpassen müssen.
Wir überprüfen also erst einmal die Paketfiltereinstellungen.
# iptables -L
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ldap ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ldaps REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination
Für den SKS-Keyserver, der auf den beiden Ports 11370 und 11371 lauschen wird, tragen wir also eine passende Regel in der Konfigurationsdatei des Paketfilters iptables ein.
# vim /etc/sysconfig/iptables
- /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT # Django : 2011-10-27 ldap-Zugriff freigeschaltet -A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT # Django : 2011-12-28 sks-Zugriffe freigeschaltet -A INPUT -m state --state NEW -m tcp -p tcp --dport 11370 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 11371 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT
Anschließend aktivieren wir die neue Regel, indem wir den Service iptables einmal durchstarten.
# service iptables restart
iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] iptables: Applying firewall rules: [ OK ]
Eine erneute Abfrage der Paketfilterregeln zeigt uns nun die neue Einstellung.
# iptables -L
Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT icmp -- anywhere anywhere ACCEPT all -- anywhere anywhere ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ldap ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ldaps ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:11370 ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:pgpkeyserver REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all -- anywhere anywhere reject-with icmp-host-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination
SKS-Serverdienste starten
Bevor wir nun unseren Keyserver das erste mal starten. kontrollieren und berichtigen wir noch die Berechtigungen in den Konfigurations-, Arbeits- und Logverzeichnissen.
# chown sks.sks /etc/sks/ -R
# chown sks.sks /srv/sks/ -R
# chown sks.sks /var/log/sks/ -R
erster manueller Start
SKS Datebase Server
Unseren Datenbankserver starten wir mit Hilfe unseres Startscriptes.
# service sks-db start
Starting the SKS Database Server: [ OK ]
Im Logfile des sks-db Daemons wird der Start entsprechend dokumentiert.
# tail -f /var/log/sks/db.log
2012-02-25 22:23:20 Opening log 2012-02-25 22:23:20 sks_db, SKS version 1.1.2 2012-02-25 22:23:20 Copyright Yaron Minsky 2002, 2003, 2004 2012-02-25 22:23:20 Licensed under GPL. See COPYING file for details 2012-02-25 22:23:29 Database opened 2012-02-25 22:23:29 Applied filters: yminsky.dedup, yminsky.merge
SKS Reconciliation Server
Unseren Serverdienst zur automatischen Abgleich der Datenbestände starten wir auch mit Hilfe unseres Startscriptes.
# service sks-recon start
Starting the SKS Reconciliation Server: [ OK ]
Im Logfile des sks-recon Daemons wird der Start entsprechend dokumentiert.
# tail -f /var/log/sks/recon.log
2012-02-25 22:26:22 Opening log 2012-02-25 22:26:22 sks_recon, SKS version 1.1.2 2012-02-25 22:26:22 Copyright Yaron Minsky 2002-2003 2012-02-25 22:26:22 Licensed under GPL. See COPYING file for details
automatischer Start der Serverdienste
SKS Datebase Server
Damit nun unser SKS Database Server beim Booten automatisch gestartet wird, nehmen wir noch folgende Konfigurationsschritte vor.
# chkconfig sks-db on
Anschließend überprüfen wir noch unsere Änderung:
# chkconfig --list | grep sks-db
sks-db 0:off 1:off 2:on 3:on 4:on 5:on 6:off
SKS Reconciliation Server
Damit auch der SKS Reconciliation Server beim Booten automatisch gestartet wird, nehmen wir noch folgende Konfigurationsschritte vor.
# chkconfig sks-recon on
Anschließend überprüfen wir noch unsere Änderung:
# chkconfig --list | grep sks-recon
sks-recon 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Links
~~DISCUSSION~~
django