Kleine und große Linux AHAs
Beiträge getaggt mit sicherheit
Simpler Zugang zum Netz, oder nicht? CaptivePortal in einfach
23. Feb
Viele kennen es aus Hotels, Bahnhöfen, Cafes oder öffentlichen Plätzen. Es gibt ein offenes WLAN zum Internet und wenn man sich damit verbindet landet man zuerst einmal auf einer speziellen Seite. Auf dieser muss man sich dann irgendwie registrieren oder halt bezahlen. Aber wie funktioniert sowas und macht das vielleicht auch Sinn für ein Unternehmen intern?
Warum kann das unternehmensintern Sinn machen?
Also hier geht es nicht um Provider oder Firmen die das ganze öffentlich anbieten. Es gibt beispielsweise die Anforderung in Unternehmen die Produktionsstraßen besitzen, Großraumhallen, Fertigungshallen oder ähnliches. Oft gibt es dort viele Geräte verschiedener Hersteller die gewartet werden (nur ein Beispiel). Es kommen also externe Dienstleister um Updates einzuspielen oder Support zu leisten. Diese müssen mittlerweile, um vernünftig arbeiten zu können, Kontakt mit Ihrer Firma haben. Das kann über 3G geschehen, ist allerdings schneller über WLAN. Für solche Dienstleister macht ein WLAN Zugang also Sinn. Das auch für einen “normalen” Besprechungs- oder Schulungsraum schon Sinn machen.
Nun hat man ein Problem. Das WLAN offen zu lassen ist quasi grob fahrlässig. Das WLAN schützen macht es umständlich – je nach Anzahl der verschiedenen Benutzer. Dann haben wir da noch den Aspekt des Loggings. Prinzipiell muss man die Verbindungsdaten mitloggen, da man je nach dem in die Beweispflicht genommen werden kann. Um zu loggen muss ich auch wissen wer zu welchem Gerät gehört, da mir ansonsten die Information nichts bringt. Das alles kann ich mit der Anmeldung quasi erledigen. Ich weiß wer zu welchem Gerät gehört und kann auch mitloggen. Bevor der Nutzer sich über das WLAN mit dem Internet verbindet, muss er einer entsprechenden Nutzungserklärung zustimmen (wegen logging etc.).
Wie kann sich so was mit Linux darstellen?
Diese Portale sind gar nicht so kompliziert wie man denkt. Um so etwas unter Linux zu realisieren kann man sich fertiger Software bedienen oder auch einfach das ganze selbst – relativ schnell – programmieren. Ein Projekt mit einer “CaptivePortal” Funktion ist beispielsweise pfsense. Die meisten CaptivePortal Funktionen befinden sich im Bundle mit Firewalls und bieten weit mehr als eine einfach Authentifizierung für einen Netzzugang.
Um so etwas mit Linux Mitteln darstellen zu können habe ich folgende Komponenten genutzt:
- einen Apache Webserver
- MySQL Datenbank
- iptables
- DHCP Server (Standardkonfig mit Netz 192.168.199.0/24)
Das ganze funktioniert nach folgendem Ablauf:
- Gerät verbindet sich mit dem Netz (dabei ist unerheblich ob per WLAN oder per Kabel)
- das Gerät bekommt eine IP per DHCP
- per Default werden alle Verbindungen geblockt, Verbindungen zu Port 80 (egal wohin) werden auf den Webserver des Gateways umgeleitet, bis das Device registriert ist
Zur Registrierung benötigt man einen Schlüssel (5 Stellen, Alphanumerisch). Diesen kann man sich an eine interne Mailaddresse schicken lassen. Also können nur interne Accounts quasi den Zugriff genehmigen. Wenn man einen Schlüssel besitzt, dann kann man sich über das Portal registrieren (Name, Firma und Schlüssel werden abgefragt). Mit der Registrierung – richtiger Schlüssel vorausgesetzt – wird der Zugang für einen Tag freigegeben.
Genauer??
Der Client bekommt eine IP Adresse vom DHCP Server. Alle Zugriffe ins (bspw.) Internet werden erst einmal geblockt, außer Zugriffen auf Port 80 – diese werden umgeleitet auf den Webserver des Gatewyas – das CaptivePortal erscheint. Hat man noch keinen Schlüssel zum registrieren, so muss dieser angefordert werden. Man trägt eine eMail Adresse ein und sendet die Anfrage. Im Hintergrund wird per Perl Script geprüft ob die Empfängeradresse ok ist (bspw. interne Domain oder in einer Liste) und ein Schlüssel generiert. Dieser Schlüssel inkl. Mailadresse wird in der Datenbank hinterlegt und per Mail an den Empfänger geschickt.
Mit dem Schlüssel registriert sich der Client am Portal (inkl. Name, Firma). Mit dem Klicken des Buttons “registrieren” wird der Schlüssel geprüft und deaktiviert. MAC Adresse, Name und Firma des Anforderers werden in die Datenbank geschrieben. Danach wird ein iptables Befehl abgesetzt, der dem Client mit der betreffenden MAC Adresse den Zugriff zum Netz gewährt. Ebenfalls wird in der Datenbank ein Zeitstempel gespeichert, dadurch ist es möglich über ein iptables-update den Zugriff generell nur für eine gewisse Zeit freizugeben und dann automatisch wieder zu sperren. In der Datenbank gibt es ein Flag um zu definieren, ob dieser Eintrag überhaupt abläuft oder nicht (expires yes/no). Damit kann man also auch das ganze für interne Mitarbeiter statisch freigeben, damit diese sich nicht immer wieder neu registrieren müssen.
Die Komponenten
(Die Scripte liegen bei mir unter /opt/captivePortal – der Pfad ist in manchen Scripten zu finden)
iptables
iptables ist ja quasi auf jedem Linux System vorhanden und muss auch nicht groß konfiguriert werden.
Script 1 (Initiales iptables Script / iptables.sh):
#!/bin/bash # Initial Iptables Script to enable captivePortal # # Ronny Becker, 02.2012 IPTABLES=/sbin/iptables # the interface to authenticate PORTAL_INT=eth2 # the interface where traffic goes through OUTPUT_INT=eth0 # PortalIP (for captivePortal website) PORTAL_IP=192.168.199.201 # clear all rules iptables -F iptables -X iptables -t nat -F iptables -t nat -X iptables -t mangle -F iptables -t mangle -X iptables -P INPUT ACCEPT iptables -P FORWARD ACCEPT iptables -P OUTPUT ACCEPT # Create captivePortal chain $IPTABLES -N captivePortal -t mangle # All traffic goes to this chain $IPTABLES -t mangle -A PREROUTING -j captivePortal ###### captivePortal CHAIN ########## # get allowed MACs out of the database (maybe persistent or in time) /opt/captivePortal/iptablesFromDB.pl # DNS is allowed for all $IPTABLES -t mangle -A captivePortal -i $PORTAL_INT -p udp --dport 53 -j RETURN # Mark packets that are not allowed till here $IPTABLES -t mangle -A captivePortal -i $PORTAL_INT -j MARK --set-mark 99 # redirect port 80 to captivePortal $IPTABLES -t nat -A PREROUTING -m mark --mark 99 -i $PORTAL_INT -p tcp --dport 80 -j DNAT --to-destination $PORTAL_IP # drop all marked with 99 $IPTABLES -t filter -A FORWARD -m mark --mark 99 -j DROP # masquerading (if needed) iptables -t nat -A POSTROUTING -o $OUTPUT_INT -s 192.168.199.0/24 -j MASQUERADE
Das iptables.sh Script muss bei jedem Systemstart ausgeführt werden. Des Weiteren muss ip_forward (/etc/sysctl.conf) gesetzt sein, damit der Server routen kann.
Script 2 (Perl Script zum Auslesen der aktuellen Berechtigungen aus der Datenbank / iptablesFromDB.pl):
#!/usr/bin/perl
# captivePortal
# Script to get registered MACs out of DB
use DBI;
# get Config from central conf file
BEGIN { require "/opt/captivePortal/captivePortal.conf" };
# database connection
$connectionInfo="DBI:mysql:database=$db;$host:$port";
$dbi = DBI->connect($connectionInfo,$userid,$passwd);
# select datasets
$sql="select mac from registered where expires='no' or ((UNIX_TIMESTAMP()-timestamp) < $tte)";
$sth = $dbi->prepare($sql);
$sth->execute() or die("Cannot get MACs");
$sth->bind_columns(undef, \$db_mac);
while ( $sth->fetch() ) {
# and run iptables
`/sbin/iptables -t mangle -A captivePortal -m mac --mac-source "$db_mac" -j RETURN`;
}
$sth->finish();
$dbi->disconnect();
Config (Konfig für die Perl Scripte (s. Script 2 / captivePortal.conf):
# captivePortal - central config # this conf file is used in perl scripts use vars qw( $tte $db $host $port $userid $passwd $iptables_if ); # Time To Expire for dynamic subscriptions $tte="86400"; # Database Information $db="captivePortal"; $host="localhost"; $port="3306"; $userid="portal"; $passwd="captive"; # portal interface $iptables_if="eth2";
Script 3 (Updatescript für iptables um abgelaufene Registrierungen zu löschen / iptables_update.sh):
#!/bin/bash # captivePortal # Update iptables rules to delete expired registrations IPTABLES=/sbin/iptables # the interface to authenticate PORTAL_INT=eth2 # clear the chain $IPTABLES -t mangle -F captivePortal # run the rules out of the db /opt/captivePortal/iptablesFromDB.pl # add default rules (see iptables.sh) $IPTABLES -t mangle -A captivePortal -i $PORTAL_INT -p udp --dport 53 -j RETURN $IPTABLES -t mangle -A captivePortal -i $PORTAL_INT -j MARK --set-mark 99
Das Update Script sollte per cron alle Xmin / Xstunden ausgeführt werden, damit abgelaufene Registrierungen den Zugriff verlieren. Wenn man den cronjob nicht gerade jede Minute laufen lässt, ist damit natürlich nicht gewährleistet dass eine Registrierung genau so lange gültig ist, wie es in der Konfiguration steht. In meinem Fall läuft das Script jede Stunde – das ist für meine Zwecke ausreichend.
MySQL
Die Datenbank besteht aus zwei Tabellen -> captivePortal.sql
Apache
Wir benötigen lediglich ein CGI Script. Auf dieses muss per Default umgeleitet werden sobald der Server eine Anfrage bekommt. Das kann man auf verschiedenste Weisen machen – also nicht schimpfen
Redirect
Damit das ganze mit iPhone und Android funktioniert, habe ich folgende Apache config am Start:
<VirtualHost 192.168.199.201:80>
ServerAdmin webmaster@localhost
Servername captivePortal
DocumentRoot /var/www
Redirect /index.html http://192.168.199.201/cgi-bin/captivePortal.pl
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI Indexes -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^/$ http://192.168.199.201/cgi-bin/captivePortal.pl [L,R]
</IfModule>
ErrorLog ${APACHE_LOG_DIR}/error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
Dem entsprechend liegt das CGI (captivePortal.pl) unter /usr/lib/cgi-bin.
Das CGI
#!/usr/bin/perl
# captivePortal
#
# This is the cgi for the simple captivePortal
#
# Do not forget to change
# line 51: valid domain to send regkey to
# line 58: sender adress
#
#
#
# Ronny Becker, 02.2012
use CGI qw(:all);
use DBI;
# get Config from central conf file
BEGIN { require "/opt/captivePortal/captivePortal.conf" };
# connect to DB
$connectionInfo="DBI:mysql:database=$db;$host:$port";
$dbi = DBI->connect($connectionInfo,$userid,$passwd);
# params
$thisscript=$ENV{'SCRIPT_NAME'};
# cgi params
$para_req_sendto=param('req_sendto');
$para_req_submit=param('req_submit');
$para_reg_company=param('reg_company');
$para_reg_name=param('reg_name');
$para_reg_key=param('reg_key');
$para_reg_submit=param('reg_submit');
# print some headers
print "Content-type: text/html\n\n";
print '
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>WLAN Gastzugang</title>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
</head>
<body style="font-family: courier,courier-new">
<h2>WLAN Gastzugang</h2><br>';
# request for key
if ( $para_req_submit ) {
# address valid?
if ( $para_req_sendto ) {
if ( $para_req_sendto =~ /.*\@mydomain\.de/i || $para_req_sendto =~ /.*\@mydomain2\.de/ ) {
# generate a key
my @chars=('a'..'z','0'..'9');
foreach (1..5) {
$secret.=$chars[rand @chars];
}
# send key to recipient
$result=`export EMAIL="gastzugang\@mydomain.de"; echo "Der Registrierungsschluessel fuer Ihren Gast lautet: $secret" | mail -s "WLAN Gastzugang" $para_req_sendto`;
print "$result";
# Insert Key into DB
$sql="insert into regkeys(regkey,sendto,datetime) values('$secret','$para_req_sendto',NOW())";
$sth = $dbi->prepare($sql);
$sth->execute() or die("Fehler beim schreiben in die Datenbank");
$sth->finish();
print "<div style='background-color: green; color: white'><p><b>Registrierungsschluessel wurde zugeschickt</b></p></div>";
}
}
}
# request for registration
if ( $para_reg_submit ) {
# name given?
if ( length($para_reg_name) <= 5 || length($para_reg_key) != 5 ) {
print "<div style='background-color: red; color: white'><p><b>Sie muessen einen Namen und den Registrierungsschluessel angeben.</b></p></div>";
} else {
# Check DB for regkey
$sql="select sendto from regkeys where regkey='$para_reg_key' and isActive='1'";
$sth = $dbi->prepare($sql);
$sth->execute() or die("DB: Cannot run select");
$sth->bind_columns(undef, \$db_sendto);
$sth->fetch();
$sth->finish();
if ( $db_sendto ) {
# disable key
$sql="update regkeys set isActive='0' where regkey='$para_reg_key'";
$sth = $dbi->prepare($sql);
$sth->execute() or die("DB: Cannot update");
$sth->finish();
# get MAC
open (ARP,"</proc/net/arp");
while (<ARP>) {
$line = $_;
$line =~ s/ */;/g;
($arp_ip,undef,undef,$arp_mac,undef,undef) = split(";",$line);
if ( $arp_ip eq $ENV{'REMOTE_ADDR'} ) {
$mac=$arp_mac;
}
}
close ARP;
# write data into db
$sql="insert into registered(name,guestof,mac,timestamp,expires) values('$para_reg_name, $para_reg_company','$db_sendto','$mac',UNIX_TIMESTAMP(),'yes')";
$sth = $dbi->prepare($sql);
$sth->execute() or die("DB: Cannot insert");
$sth->finish();
$output=`sudo /sbin/iptables -I captivePortal 1 -t mangle -m mac --mac-source $mac -j RETURN`;
print "<div style='background-color: green; color: white'><p><b>erfolgreich registriert</b><br>$output</p></div>";
} else {
print "<div style='background-color: red; color: white'><p><b>Registrierungsschluessel nicht gefunden</b></p></div>";
}
}
}
# disconnect from DB
$dbi->disconnect();
# print form etc.
print '
<form method=get action='.$thisscript.'>
<b>Registrierungsschluessel anfragen</b><br>
senden an: <input type=text name=req_sendto size=40> <input type=submit name=req_submit value=zusenden></form>
<hr><br>
<form method=get action='.$thisscript.'>
<b>Registrieren</b><br>
<b><u>Achtung! Registrieren Sie sich mit dem Geraet, mit dem Sie Zugriff benoetigen</b></u><br>
<table>
<tr><td>Name:</td><td><input type=text name=reg_name size=30></td></tr>
<tr><td>Firma:</td><td><input type=text name=reg_company size=30></td></tr>
<tr><td>Registrierungsschluessel:</td><td><input type=text name=reg_key size=10></td></tr>
<tr><td colspan=2 align=center><font color=red><b><u>Nutzungsbedingungen:</u><br>
Mit klicken auf den Button "registrieren" stimmen Sie zu,dass die ihre Verbindungsdaten (Zeitpunkt und Dauer einer Verbindung, Addressierungsdaten) mitprotokolliert werden.
Dies dient lediglich zur Fehleranalyse und zur Sicherheitsueberpruefung.
Es werden keine Daten an dritte weitergegeben oder weiterverarbeitet.<br><br><br>
Sie haben (per Default) ab dem Zeitpunkt der registrierung Zugriff fuer 24 Stunden.
<input type=submit name=reg_submit value=registrieren></td></tr>
</table>
</form>
</body>
</html>';
Das Webinterface ist recht einfach gehalten damit es auch mit mobilen Endgeräten keine Probleme gibt. Das ganze ist natürlich nach belieben anzupassen oder zu ändern
Ich hoffe ich hab nix vergessen – falls doch einfach fragen.
Unleserliches debuggen, oder: Fehlersuche in verschlüsselten Protokollen
03. Mai
Immer mehr Datenverkehr wird verschlüsselt. Einerseits natürlich richtig und gut. Andererseits ein Problem. Früher konnte man mit Hilfe von Tools wie Wireshark (Ethereal) oder tcpdump relativ schnell Probleme (z.B.) in der Kommunikation zwischen Programm und Server herausfinden. Einfach den Netzwerkverkehr mitschneiden, ansehen / auswerten und es zeigten sich Fehler die man im Programm möglicherweise nicht zu Gesicht bekommen hat.
Mittlerweile sind die Pakete weitestgehend verschlüsselt und man kann nicht mehr einfach so “mit schreiben” – naja, man kann natürlich; aber lesen kann man es nicht. Also fällt ein mitschreiben – einfach mal so – flach.
Eine andere Möglichkeit die Kommunikation zwischen Programmen zu debuggen ist, sich einfach manuell zu verbinden und die Kommandos direkt einzugeben um zu prüfen ob der Server richtig reagiert. Dazu nahm man früher telnet … Auch telnet ist kein Kandidat mehr für verschlüsselte Protokolle.
Verbindung zu einem SSL geschützten Dienst
Eine Möglichkeit sich auf einen solchen Dienst zu verbinden bietet der Befehl
openssl s_client -connect <Zielrechner>:<Port>
Mit diesem Befehl kann man sich beispielsweise direkt auf einen per SSL geschützten IMAP Server (Port 993) verbinden und manuell Kommandos absetzen. Das ganze über eine SSL geschützte Verbindung – die nicht mitgeschnitten werden kann
Ganz wie früher mit telnet *freu*
Daten auf NAS – aber bitte sicherererer
12. Apr
Vor genau einem Jahr habe ich einen Artikel geschrieben der sich mit einem NAS für zu Hause mit iSCSI beschäftigte (s. Teil I, Teil II, Teil III). Mittlerweile habe ich mir ein neues NAS gekauft – ein Synology DS411slim (Link). Was hat mich nun zu diesem NAS System gebracht? Kurz gesagt: Denny
Nee, im Ernst. Die Unterschiede zwischen den Systemen (und ich spreche nur von den Home NAS Systemen) ist sehr identisch. Man bekommt sehr billige die – laut Beschreibung – sämtliche Protokolle unterstützen und auch schnell sein sollen. Man bekommt teure die das gleiche versprechen.
Natürlich gibt es Unterschiede. Ein wichtiger Faktor ist beispielsweise die Lautstärke. Hat das System Lüfter? Welche größe haben sie? Laufen sie immer? Auch die Plattendimension macht einen Unterschied bei der Lautstärke – 3,5″ oder 2,5″? Für uns hier interessant: Mit welchem OS wird das System betrieben? Linux? Bei komplett fertigen Systemen ist auch die Frage welche Festplatten eingebaut sind oder ob 2x die gleiche oder verschiedene eingebaut sind. Das kenne ich aus dem Enterprise Umfeld, wo man zusieht dass in einem Plattensystem nicht eine komplette Serie verbaut ist – hat die einen Fehler, so hat mein ganzes System ein Problem. Das zu Hause zu bedenken mag dem ein oder anderen übertrieben erscheinen, allerdings ist das recht kostenneutral 2 oder mehrere Platten von verschiedenen Serien oder Herstellern zu nehmen – also warum nicht?
Das aber nur als kleines Vorwort
Darum Synology für mich
Ich habe mich für Synology entschieden, weil
- OS ist Linux
- Shellzugriff (bisher nicht benötigt aber möglich)
- erweiterbar über Pakete
- intuitive Benutzeroberfläche
- sehr nützliche Softwarefeatures
- das Gerät wurde als extrem leise getestet (stimmt auch)
- extrem klein, da nur 2,5″ Festplatten eingebaut werden können
- Raid im nachhinein erweiterbar
- geringer Stromverbrauch, gerade auch wegen den 2,5″ Platten
Nun kann man sagen das ganze sind keine Alleinstellungsmerkmale und diese Features haben viele NAS Systeme verschiedener Hersteller. Richtig. Aber:
- Von Synology gibt es gibt Apps für Android und iPhone, mit denen man bequem auf die Bilder, Musik und auch die Dateien auf der Box von überall zugreifen kann
Das war für mich das ausschlaggebende Argument.
Sicherheit der Daten
Das eigentliche Thema dieses Beitrags ist die Datensicherheit auf einer solchen Box. Ich habe einiges an Dokumenten die eine gewisse Sicherheit benötigen. Kann ich diese dann einfach per NFS oder Samba auf eine NAS Box legen? Meiner Meinung nach nicht.
Was passiert wenn die Box gehackt wird? Was wenn sie gestohlen wird? Der Hersteller muss nur einen Softwarefehler in der Firmware haben und die Daten stehen jedem offen. Alles natürlich nur dann, wenn die Box per DynDNS von Außen erreichbar ist (Apps!).
Nun bietet Synology an, die Daten eines “Gemeinsamen Ordners” per integriertem AES Chip zu verschlüsseln. Gut. Aber wie funktioniert das? Naja, so wie es eben nur möglich ist. Das Volume ist verschlüsselt. Um darauf zuzugreifen muss man entweder vorher per Benutzeroberfläche das Volume entsperren oder man lässt es beim booten entsperren. Hmmm… Also der Sinn das ganze beim Booten automatisch machen zu lassen erschließt sich mir auf Anhieb nicht und vor jedem Zugriff das Volume über die Benutzeroberfläche zu entsperren, bzw. danach wieder zu sperren, ist nicht wirklich benutzerfreundlich. Eine andere Möglichkeit gibt es jedoch so direkt nicht.
Container?
Am Anfang dachte ich, man könnte das ganze mit einem Container machen. Beispielsweise mit TrueCrypt. In Nautilus auf den Container klicken, Passwort eingeben und glücklich sein. Nada. TrueCrypt kann nicht mit Samba Laufwerken umgehen
(wenigstens nicht so über Nautilus).
Also das Verzeichnis direkt beim Booten mounten? Auch unschön. Der NetworkManager ist bei mir für die Netze verantwortlich. Also ist ein mounten von Laufwerken über die fstab nicht so einfach möglich.
iSCSI!!
Tja, nach einigem überlegen bin ich dann auf meinen eigenen Artikel gekommen
. Warum nicht iSCSI? Die Box macht das und ich könnte – mit Linux Standardmitteln – die Daten verschlüsseln. Gedacht, getan. Ein iSCSI Target auf der Box angelegt. Und wie schon in meinem anderen Artikel das LUKS Device angelegt, formatiert und gut.
Sobald der NetworkManager ein Device konfiguriert hat, erscheint in Nautlilus ein neues Gerät. Anklicken, Passwort eingeben (oder beim ersten Mal speichern) und schon bin ich auf der Box in einem verschlüsselten Volume.
Problem
Es gibt an sich nur ein Problem mit der Lösung. Es kann immer nur einer darauf zugreifen (zur selben Zeit). Das ist für mich kein Problem, da es sich nur um die Sicherheitsbedürtigen Daten handelt. Alle anderen Dateien sind von mehreren Rechnern gleichzeitig zugreifbar.
HDYUYD Teil III: Lila Täubchen gut integriert – Pidgin
10. Feb
Instant Messenger gibt es mittlerweile sehr viele. Ich habe mich vor einiger Zeit schon für Pidgin entschieden.
Einige Gründe sprechen für Pidgin in meiner Umgebung (z.B. Gnome).
Pidgin (ehemals Gaim) unterstützt nahezu alle bekannten Chat-Protokolle und kann sich gleichzeitig bei verschiedenen Netzwerken anmelden. Die Funktionsvielfalt ist groß. Pidgin kann über diverse Plugins erweitert werden und sich dadurch prima in die Desktopumgebung einfügen. Da Pidgin sehr bekannt ist, können auch andere Programme an Pidgin andocken. Beispielsweise Gnome-Do aus dem letzten Artikel.
Integration in den Desktop
Pidgin integriert sich sehr gut in den Gnome Desktop. Wie es mit anderen (KDE,…) aussieht kann ich leider nicht sagen. Natürlich gibt es im Systemabschnitt des Panels oder Docks das Statusicon. Natürlich blinkt das wie wild wenn offene Nachrichten vorhanden sind. Das sind jedoch die Standardfunktionen die ein solcher Client unter einem aktuellen Desktop bringen muss.
Anders sieht es aus wenn es beispielsweise um die “Senden an …” Funktion geht.
Diese Funktion ermöglicht es, Dateien direkt aus Nautilus oder vom Desktop aus an einen Chatpartner zu schicken (soweit vom Protokoll unterstützt). Diese Möglichkeit wird nicht von allen Clients angeboten, ist jedoch sehr nützlich
Beim Dateitransfer über IM wird direkt zwischen den Clients eine Verbindung aufgebaut und die Datei somit direkt von PC zu PC übertragen. Im Unternehmensnetz macht dies absolut Sinn – einiges was vorher als Email verschickt wurde wird nun über IM verschickt. Dadurch werden die Mailserver entlastet und vor allen Dingen wird kein teurer Speicherplatz dafür verschwendet (seien wir mal ehrlich – die meisten Emailanhänge sind es nicht Wert gesichert zu werden).
Auch Gnome-Do interagiert mit Pidgin. Wie bereits im letzten Artikel beschrieben – naja per Screenshot – kann man über Gnome-Do seinen Chatpartner auswählen und direkt eine neue Konversation starten. Es ist ebenfalls möglich über Do seinen Status zu setzen; allerdings habe ich das noch nie genutzt.
Es gibt einige weitere Beispiele für die Integration wie beispielsweise die Zusammenarbeit mit dem Indicator Applet (Ubuntu) oder einem Plugin für den Avant Window Navigator.
Wichtiger Punkt – für mich
Ein wichtiges Feature für mich ist, dass Pidgin HTML anzeigen kann. Wir nutzen das ganze für Nagios Benachrichtigungen. Das ganze habe ich auch schon einmal beschrieben (Ein bisschen grün, ein bisschen gelb und möglichst wenig rot – Nagios per Jabber live und in Farbe [fixed]).
Ohne HTML würde man den Nagios Meldungen nicht direkt ansehen welchen Status sie vermitteln. Bei meinem letzten Test konnte z.B. Empathy (der Gnome IM) mit den HTML Nachrichten nichts anfangen.
Plugins
Obwohl Pidgin sehr viele Plugins bereits von Hause aus mitbringt, habe ich nur wenige in Benutzung.
- libnotify Popups (zeige neue Nachrichten per Bubble (Ubuntu) / OSD an)
- Off-the-Record Messaging (extra Verschlüsselung zwischen Clients durch vorherigen Schlüsselaustausch)
Naja, wie gesagt nutze ich derzeit nicht so wahnsinnig viele Plugins
Alien vergewaltigt: SSH Keys verwalten mit RPM und Debian Paketen
10. Sep
Sascha hatte vor einiger Zeit beschrieben, wie man mit Hilfe von RPM Paketen die authorized_keys auf Servern verwalten kann. Das ganze ist wirklich angenehm und macht die Verwaltung von Zugängen um einiges einfacher. Wird ein neuer Admin eingestellt, so wird einfach das RPM mit dem public Key auf den Servern installiert, wo er Zugriff haben sol – fertig. Verlässt er das Unternehmen wieder, so wird das RPM deinstalliert – wieder fertig.
Nun arbeite ich in einer “Welt”, in der RPMs und Debian Pakete genutzt werden. Blöd, wenn man dann zwei Pakete bauen muss. Aber es geht recht einfach und braucht auch gar nicht viel
Prerequisites
Die Pakete werden auf einem Debian System gebaut. Des Weiteren wird alien benötigt. Der Rest sollte standardmäßig vorhanden sein.
Ordnerstruktur
Erstellt euch ein Verzeichnis, in dem ihr die Keys verwalten/erstellen möchtet. Darunter wird folgende Struktur erstellt:
./ssh-rootkey-template./ssh-rootkey-template/DEBIAN./packages
Das war es schon.
Dateien
Folgende Dateien legen wir an:
./ssh-rootkey-template/DEBIAN/copyright ./ssh-rootkey-template/DEBIAN/postrm ./ssh-rootkey-template/DEBIAN/rules ./ssh-rootkey-template/DEBIAN/control ./ssh-rootkey-template/DEBIAN/changelog ./ssh-rootkey-template/DEBIAN/postinst
copyright
This package provides authorized_keys management Copyright: Information from the binary package: Name : ssh-rootkey-<username> Packager : Ronny Becker <ronny.becker@linux-aha.de> URL : http://www.linux-aha.de Summary : root access over ssh for <full_username> (<username>) Description : This package adds access for direct root-login for: <full_username> (<username>)
postrm
#!/bin/bash
RPM_INSTALL_PREFIX=
export RPM_INSTALL_PREFIX
HOMEDIR=/root
umask 077
timestamp=`date +%Y%m%d-%H%M%''S`
echo "Deinstallation of package 1.0.0-1 started on $timestamp" >>/var/log/rpm_ssh-rootkey-#username#.log
# finding out authkeyfile
if grep -q ^AuthorizedKeysFile /etc/ssh/sshd_config; then
AUTHFILE=$(grep ^AuthorizedKeysFile /etc/ssh/sshd_config | awk {'print $2'})
else
AUTHFILE=".ssh/authorized_keys"
fi
echo "Using authorized keys file: $AUTHFILE" >>/var/log/rpm_ssh-rootkey-#username#.log
# remove key from config file
echo "Removing key for #full_username# (#username#)" >>/var/log/rpm_ssh-rootkey-#username#.log
mv $HOMEDIR/$AUTHFILE $HOMEDIR/$AUTHFILE.tmp_ssh-rootkey-#username#
grep -v " #ssh_key# " $HOMEDIR/$AUTHFILE.tmp_ssh-rootkey-#username# >$HOMEDIR/$AUTHFILE
rm -f $HOMEDIR/$AUTHFILE.tmp_ssh-rootkey-#username#
echo "Deinstallation of package 1.0.0-1 completed" >>/var/log/rpm_ssh-rootkey-#username#.log
echo "" >>/var/log/rpm_ssh-rootkey-#username#.log
rules
#!/usr/bin/make -f
# debian/rules for alien
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
# Use v4 compatability mode, so ldconfig gets added to maint scripts.
export DH_COMPAT=4
PACKAGE=$(shell dh_listpackages)
build:
dh_testdir
clean:
dh_testdir
dh_testroot
dh_clean -d
binary-indep: build
binary-arch: build
dh_testdir
dh_testroot
dh_clean -k -d
dh_installdirs
dh_installdocs
dh_installchangelogs
# Copy the packages's files.
find . -maxdepth 1 -mindepth 1 -not -name debian -print0 | \
xargs -0 -r -i cp -a {} debian/$(PACKAGE)
#
# If you need to move files around in debian/$(PACKAGE) or do some
# binary patching, do it here
#
# This has been known to break on some wacky binaries.
# dh_strip
dh_compress
# dh_fixperms
dh_makeshlibs
dh_installdeb
-dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary
control
Source: ssh-rootkey-#username# Section: alien Priority: extra Maintainer: Ronny Becker <ronny.becker@linux-aha.de> Package: ssh-rootkey-#username# Architecture: all Depends: coreutils Version: 1.0 Description: root access over ssh for #full_username# (#username#) This package adds access for direct root-login for: #full_username# (#username#)
changelog
ssh-rootkey-<username> (1.0.0-2) experimental; urgency=low * Initial release -- Ronny Becker <ronny.becker@linux-aha.de> Wed, 01 Sep 2010 10:42:36 +0200
postinst
#!/bin/bash
RPM_INSTALL_PREFIX=
export RPM_INSTALL_PREFIX
HOMEDIR=/root
umask 077
timestamp=`date +%Y%m%d-%H%M%''S`
echo "Installation package ssh-rootkey-#username#-1.0.0-1 started on $timestamp" >>/var/log/rpm_ssh-rootkey-#username#.log
# finding out authkeyfile
if grep -q ^AuthorizedKeysFile /etc/ssh/sshd_config; then
AUTHFILE=$(grep ^AuthorizedKeysFile /etc/ssh/sshd_config | awk {'print $2'})
else
AUTHFILE=".ssh/authorized_keys"
fi
echo "Using authorized keys file: $HOMEDIR/$AUTHFILE" >>/var/log/rpm_ssh-rootkey-#username#.log
# creating dir
[ -d $(dirname $HOMEDIR/$AUTHFILE) ] || mkdir -p $(dirname $HOMEDIR/$AUTHFILE)
# checking key
if [ -f $HOMEDIR/$AUTHFILE ] ; then
echo "Removing older sshkey from #full_username# (#username#)" >>/var/log/rpm_ssh-rootkey-#username#.log
mv -f $HOMEDIR/$AUTHFILE $HOMEDIR/$AUTHFILE.tmp_ssh-rootkey-#username#
grep -v " #ssh_key# " $HOMEDIR/$AUTHFILE.tmp_ssh-rootkey-#username# >$HOMEDIR/$AUTHFILE
rm -f $HOMEDIR/$AUTHFILE.tmp_ssh-rootkey-#username#
fi
# adding key
echo "Adding sshkey for #full_username# (#username#)" >>/var/log/rpm_ssh-rootkey-#username#.log
cat >>$HOMEDIR/$AUTHFILE <<!EOFAUTHFILE!
ssh-rsa #ssh_key# #full_username# (#username#)
!EOFAUTHFILE!
echo "Installation package 1.0.0-1 ended with Exit Code $1" >>/var/log/rpm_ssh-rootkey-#username#.log
echo "" >>/var/log/rpm_ssh-rootkey-#username#.log
Variablen/Build
#!/bin/bash
#
# Script to create .deb and .rpm SSH-rootkey Packages
#
# You must provide:
# - unique username
# - full username
# - rsa Key (only the key, without comment and ssh-rsa!)
#
#set -x
echo -n "username: "
read KEY_USERNAME
echo -n "full name: "
read KEY_FULL_USERNAME
echo -n "ssh key (ssh-rsa): "
read KEY_SSH_KEY
echo ""
echo " copying ${KEY_USERNAME} ..."
cp -a ssh-rootkey-template ssh-rootkey-${KEY_USERNAME}
echo ""
echo " working on ${KEY_USERNAME} ..."
for I in ssh-rootkey-${KEY_USERNAME}/DEBIAN/postrm ssh-rootkey-${KEY_USERNAME}/DEBIAN/control ssh-rootkey-${KEY_USERNAME}/DEBIAN/postinst
do
sed -i "s/#username#/${KEY_USERNAME}/g" $I
sed -i "s/#full_username#/${KEY_FULL_USERNAME}/g" $I
sed -i "s#\#ssh_key\##${KEY_SSH_KEY}#g" $I
done
echo ""
echo " creating .deb package ..."
dpkg -b ssh-rootkey-${KEY_USERNAME}
echo ""
echo " creating .rpm package ..."
alien -c -r ssh-rootkey-${KEY_USERNAME}.deb
mv ssh-rootkey-${KEY_USERNAME}-1.0-2.noarch.rpm ssh-rootkey-${KEY_USERNAME}.rpm
mv *.deb packages/
mv *.rpm packages/
echo ""
echo "Done"
echo ""
Openvpn: Tür auf, Tür zu, Tür auf, Tür zu …
20. Aug
Betreibt man einen Openvpn Server – beispielsweise zur Einwahl von Dienstleistern oder auch einfach nur für “normale” Benutzer – so sollte man das ganze mit einem Zertifikat abgesichert haben. Das ganze geht unter Debian/Ubuntu (und auch anderen) recht einfach mit easy-rsa. Jeder Client bekommt seinen eigenen Key und kann damit den Tunnel aufbauen.
Tür zu?
Was nun, wenn man einen Client aussperren möchte? Der Dienstleister ist ab sofort “böse”. Die Zusammenarbeit beendet. Er hat noch seinen Key und kann sich damit per Openvpn verbinden und ins interne Netz (soweit die Firewall den Zugriff zulässt). Eigentlich ganz einfach. Der Key des Benutzers wird “revoked” – das geht auch per easy-rsa recht einfach. Ist der Key revoked, so ist der Key für Openvpn ungültig und die Verbindung kann nicht mehr aufgebaut werden. Fertig.
Tür wieder auf?
Ganz anders sieht das aus, wenn man einen Benutzer hat der sich einwählen können soll, jedoch nur dann wenn man es möchte. Man vereinbart quasi einen Termin an dem irgendetwas gemacht werden soll und zu diesem Termin hat der Client Zugriff. Ist der Key eines Benutzers einmal “revoked”, dann ist das erstmal so. Einen Key wieder freizuschalten ist nicht so einfach zu machen.
Tür zu, Tür auf: Openvpn Switching
Ganz einfach ist das ganze zu machen, indem man den Parameter ccd-exclusive dazu benutzt. Dieser Parameter lässt nur Clients zu, die eine Konfigurationsdatei im sogenannten client-config-dir (Parameter in der openvpn Konfig) besitzen. Man kann diese Dateien nutzen, um Clientkonfigurationen zu setzen. Dazu wird in dem Verzeichnis eine Datei mit dem CN (der eindeutige Name/Zeritifikat) des Benutzers angelegt.
Der Parameter ccd-exclusive bewirkt nun, dass nur Clients sich verbinden dürfen, für die eine Datei im ccd vorhanden ist – mit dem genauen Namen (CN). Ob diese Datei nun gefüllt ist mir einer Clientspezifischen Konfiguration oder leer ist, das macht dabei keinen Unterschied. Um einen Client zu sperren muss man also lediglich die Datei im ccd beispielsweise in “disabled-<CN>” umbenennen. Das ganze funktioniert ohne Neustart des Daemons
Wäre doch schade drum: Google Kalender sichern
25. Mai
Ein Google Account in Verbindung mit einem Smartphone hat schon seinen Reiz. Man kann über viele Wege auf diverse Daten zugreifen und hat immer alles automatisch synchron. Und das auch noch ohne Kosten – schön.
Wenn man das nun jeden Tag nutzt füllt man seinen Account immer mehr mit Leben. Was nun, wenn diese Daten verschwinden? Die Mails werden per IMAP abgefragt, davon eine Sicherung zu machen halte ich für übertrieben. Wenn mal eine private Mail gelöscht wird sollte das nicht so schlimm sein (wenn doch sollte man sich ganz andere Gedanken machen). Mir geht es hier erst einmal um den Kalender – weil einfach. Warum den Google Kalender sichern? Ist doch alles bei Google mit seinen Millionen von Rechnern und … gut gesichert! Ja. Ich denke schon, dass Google ein gutes Backup hat und es so schnell nicht zu Datenverlust kommen kann. Allerdings bin da immer noch ich. Ich kann meine Daten löschen – vielleicht auch dann, wenn ich das gar nicht möchte.
Beispielsweise hatte ich mit meinem Smartphone einmal Probleme mit der Synchronisation. Während dieses Problems hab ich mir echt Sorgen gemacht, ob denn jetzt überhaupt die Daten noch da sind oder ob jetzt alles “weggesynct” ist … Für den Fall lege ich mir nun immer ein Backup an.
Ich nutze ein NAS System um meine Datensicherung zu machen (s. Home NAS mit iSCSI). Per rsync werden dabei die Daten meines lokalen Systems auf das NAS Device synchronisiert. Den rsync Aufruf habe ich dazu in ein Script gepackt. Dieses Script wurde nun um folgendes erweitert:
# go to $HOME
cd $HOME
# default file name
GCAL_FILE="google_kalender.ics"
# get the ics file from google
wget -nc -O ${GCAL_FILE}.tmp -c <URL>
# rotate/rename files
if [ $? == 0 ]
then
[ -e ${GCAL_FILE}.4 ] && rm -f ${GCAL_FILE}.4
[ -e ${GCAL_FILE}.3 ] && mv ${GCAL_FILE}.3 ${GCAL_FILE}.4
[ -e ${GCAL_FILE}.2 ] && mv ${GCAL_FILE}.2 ${GCAL_FILE}.3
[ -e ${GCAL_FILE}.1 ] && mv ${GCAL_FILE}.1 ${GCAL_FILE}.2
[ -e ${GCAL_FILE} ] && mv ${GCAL_FILE} ${GCAL_FILE}.1
mv ${GCAL_FILE}.tmp ${GCAL_FILE}
fi
Dieses Snippet legt quasi 5 Versionen der Sicherung im home Verzeichnis des Users an.
ACHTUNG! Woher kommt die URL?
Die URL für den Download könnt ihr aus den Google Kalender Einstellungen entnehmen:
- Einstellungen
- Kalender
- den betreffenden Kalender auswählen
- in dem Bereich “Privatadresse” den Link zu ICAL kopieren – das ist die URL
Und die Kontakte?
Tja, da waren sie wieder meine drei Probleme. Sollte irgendjemand eine Idee haben, wie man das Adressbuch ohne manuellen Eingriff herunterladen kann, dann bitte melden!! So wie ich das sehe muss man sich dazu anmelden und sich durch das Menü (Auswahl des Dateityps) hangeln.
[UPDATE]
Wie in dem Kommentar von Andy zu lesen, hat er ein Perl Script mit dem er das Google Adressbuch sichert. Ich habe es gerade selbst ausprobiert und nach einer kleinen Anpassung des Pfades (/tmp/… ist im Home Verzeichnis nicht bei jedem vorhanden) hat es auch bei mir einwandfrei funktioniert. Das Script findet ihr hier.
xdrp: auch ne Möglichkeit für Remote Zugriff
26. Feb
Es gibt unter Linux viele Möglichkeiten sich remote an einem System anzumelden – auch viele das grafisch zu tun. Da gibt es zum Beispiel XDMCP, X11 über einen ssh Tunnel, VNC, freenx oder das kommerzielle Pendant, … All diese Möglichkeiten waren mir bisher bekannt und ich habe sie auch schon mal ausprobiert. Aus irgendeinem Zufall bin ich nun auf was – für mich – neues gestossen: xrdp.
xrdp kann quasi VNC in das RDP Protokoll umschreiben und dadurch VNC über RDP zur Verfügung stellen. Das ganze ist recht interessant, da der RDP Client bekannterweise in einem von mir nicht zu nennenden “Betriebssystem” zur Standardausrüstung gehört und somit von diesen Clients aus keine extra Software / Installation benötigt wird.
Installation
Die Installation unter Ubuntu ist denkbar simpel -> apt-get install xrdp.
Konfiguration
xrdp läuft nach der Installation automatisch. Allerdings muss man um Zugriff auf den Rechner zu gewähren über die Gnome Desktop Einstellungen den VNC Server starten. Das ganze findet sich unter Menü-System-Einstellungen-Entfernter Bildschirm. Dort muss man “Anderen Benutzern erlauben, Ihren Bildschirm anzuzeigen” und “Anderen Benutzern erlauben, Ihren Bildschirm zu steuern” aktivieren. Des Weiteren sollte man ein Passwort setzen. Dieses hat jedoch nichts mit dem Anmeldepasswort des Accounts zu tun.
Anmeldung per RDP
Nun wird der RDP Client mit dem Rechner verbunden. Es erscheint ein Menü, in diesem man den Typ “Console” für die Sitzung wählt und kann dann mit dem vergebenen Passwort auf seine Sitzung zugreifen.
Naja
Also so wie ich es beschrieben habe gefällt es mir an sich selbst nicht. Ein großer Nachteil der Lösung ist, dass der Vino-Server (VNC Server unter Gnome) bei einem gesperrten Bildschirm versagt -> einen schwarzen Bildschirm zeigt. Des Weiteren ist in diesem Szenario der RDP Port als auch der VNC Port auf der Maschine offen. Gepaart mit dem “schwachen” Passwort welches wie oben konfiguriert haben, ist das nicht wirklich Sicher.
Man kann den Vino-Server auch deinstallieren und dafür x11vnc nehmen. Damit funktioniert das ganze auch bei gesperrtem Bildschirm. Leider ist damit die Performance um einiges schlechter. Ich habe keine Einstellung gefunden mit der x11vnc über xrdp so flüssig läuft wie mit dem Vino-Server. Da beißt sich die Katze in den Schwanz.
sftp Server Teil II – “Jail made easy”
08. Feb
Im ersten Teil haben wir das aktuelle openssh Paket für RHEL gebaut und sollten das auch mittlerweile installiert haben. Die Konfiguration des SSH-Servers hat sich nur wenig geändert. Es gibt eigentlich auch nur wenig neue Stellen die hier für uns interessant sind. Aber wir beginnen am Anfang:
Gruppe für sftp
Die Steuerung ob ein Benutzer in einer “gechrooteten” Umgebung landet wird über eine Gruppe gesteuert. Diese könnte man beispielsweise “sftpchroot” nennen. Diese Gruppe wird also angelegt:
groupadd sftpchroot
Benutzer anlegen
Als nächstes muss der Benutzeraccount angelegt werden, der sich auch in der Gruppe sftpchroot befindet:
useradd testuser -G sftpchroot
(Passwort setzen oder disablen, je nach dem ob sich per Key oder Passwort eingeloggt werden soll. Eine Shell benötigt der User auch nicht unbedingt.)
Benutzerhome anpassen
Das Benutzerhome (/home/testuser) muss von den Rechten her angepasst werden, damit das “chrooten” funktioniert. Gleichzeitig legen wir ein Verzeichnis (exchange) an, in welches der Benutzer über sftp schreiben darf.
chown root:sftpchroot /home/testuser mkdir /home/testuser/exchange chown testuser:testuser /home/testuser/exchange
Möchte man die Authentifizierung per Key machen, so muss folgendes ebenfalls eingerichtet werden:
mkdir /home/testuser/.ssh chown testuser:testuser /home/testuser/.ssh
Der Key kommt dann in die authorized_keys; die Rechte werden auf 0600 gesetzt und fertig.
Logging
Wir möchten genau sehen, welche Befehle auf dem SFTP Server abgesetzt werden. Daher muss auch das Logging aufgesetzt werden. Dazu ist es nötig, dass in jedem Home ein dev Verzeichnis angelegt wird (-> mkdir /home/testuser/dev). Dort wird dann vom dem Syslog Server des Vertrauens eine Pipe angelegt und damit ist das Logging im System.
Wir verwenden den syslog-ng (syslog-ng). Die Konfiguration dafür sieht wie folgt aus:
source s_sftpchroot {
# Please add each chrooted environment here
# These logs stay on the local machine; not sended to the syslog-server
unix-stream ("/home/testuser/dev/log");
};
destination d_sftplog { file("/var/log/sftp_chrooted.log"); };
log { source(s_sftpchroot); destination(d_sftplog); };
Jede Chroot Umgebung muss hier im Abschnitt “source” eingetragen werden. Damit fließen alle sftp logs in eine Datei. Alternativ kann natürlich auch für jeden Benutzer ein eigenes Log geschrieben werden. Welche Konfigteile dazu angepasst werden müssen sollte ersichtlich sein
Openssh Chroot
Nun zu dem früher schwierigsten, heute jedoch einfachsten Teil. Das Openssh Chroot. Ich zeige einfach die Konfiguration – it`s that easy !
Subsystem sftp internal-sftp Match group sftpchroot X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp -l VERBOSE ChrootDirectory /home/%u
Mit dieser Konfiguation am Ende der sshd_config (/etc/ssh) bekommt jeder Benutzer, der sich in der Gruppe sftpchroot befindet, besondere Optionen. Unter anderem wird lediglich der interne sftp-server (internal-sftp) zugelassen, der mit dem Parameter “-l VERBOSE” sämtliche Befehle des Benutzers loggt. Fertig.
sftp Server Teil I – RPM bauen “made easy”
04. Feb
Ein SFTP Server ist heutzutage eigentlich nichts besonderes mehr – kommt auf die Anforderungen an. Ich möchte in zwei Teilen erklären, wie man einen sicheren “SFTP only” Server aufbaut. Das ist an sich auch wirklich nicht so schwierig.
Wenn googelt wird man schnell sehen, dass es wahnsinnig viele Anleitungen gibt um sowas zu machen. “chrooted sftp” ist da das Stichwort und es sind diverse Patches notwendig. Allerdings sind die meisten dieser Anleitungen hinfällig, da die aktuellen Version von Openssh (5.3p) bereits alles mitbringt, was man benötigt.
Unter RHEL 5 gibt es zur Zeit Openssh Version 4.3p2 als aktuellstes Package. Damit kann man weder ein “Gefängnis” (Jail -> chrooted User) bauen, noch ist das Logging so, dass man damit auch im Problemfall etwas nachvollziehen kann. Da es sehr einfach ist, das Paket selbst zu bauen, bin ich auch gar nicht erst auf die Suche gegangen um irgendwo ein fertiges zu finden.
Quellen besorgen
Die Quellen für Openssh gibt es natürlich unter openssh.org – bzw. die Mirrorliste hier. Bei Erstellung war die aktuelle Version openssh-5.3p1.tar.gz
Prerequisites
yum install gcc openssl-devel pam-devel rpm-build
Auspacken und los
tar zxvf openssh-5.2p1.tar.gz cp openssh-<VERSION>/contrib/redhat/openssh.spec /usr/src/redhat/SPECS/ cp openssh-<VERSION>.tar.gz /usr/src/redhat/SOURCES/ cd /usr/src/redhat/SPECS # askpass wird nicht benoetigt perl -i.bak -pe 's/^(%define no_(gnome|x11)_askpass)\s+0$/$1 1/' openssh.spec rpmbuild -bb openssh.spec
Fertige RPMs
Die fertigen RPMs sind dann unter
cd /usr/src/redhat/RPMS/`uname -i`
zu finden.
Vor der Installation sollten die alten (alle !) Pakete deinstalliert werden oder die neuen mit “rpm -U” als Update installieren.








