Skip to content

Aus viel mach eins

Heute wurde ich vor die Herausforderung gestellt, mehrere PDF-Dateien zu einer einzigen Datei zusammenzuführen, da sich eine einzelne Datei einfacher hochladen lässt, als jede einzeln. Nach ein wenig googeln bin ich fündig geworden. Mit dem Konsolen-Befehl pdftk ist das ganze einfach zu bewerkstelligen.

pdftk file1.pdf file2.pdf file3.pdf cat output file123.pdf

Die einzelnen PDF-Dateien werden in der angegebenen Reihenfolge in die Ziel-Datei (file123.pdf) geschrieben. Das Paket ist ausserdem unter cygwin verfügbar. So muss ich auch in einer Windows-Umgebung nicht auf den äusserst praktischen Helfer verzichten.

PuTTY und "Server refused our key"

Ich will auch von Windows Rechnern (ja, gibt's bei mir zu Hause auch) auf Linux Server zugreifen. Ich mache das mit SSH und einem RSA-Schlüsselpaar. Als Client-Software verwende ich PUTTY. Um ein Schlüsselpaar zu erstellen, startet man das Programm "PuTTY Key Generator" (puttygen.exe). Mit einem Mausklick auf den Button "Generate" und ein wenig Mausgeschubbse generiert man sich die Schlüssel. Mit den beiden Buttons "Save public key" und "Save private key" werden die Schlüssel auf die Festplatte geschrieben. Der öffentlichen Schlüssel muss nun auf den Server kopiert werden und dort in die Datei ~/.ssh/authorized_keys überführt werden.

Hier bin ich nun in die Falle getappt. Denn nach dem Einfügen des öffentlichen Schüssels in besagte Datei und einem ersten Anmeldeversuch meldet mir PuTTY "Server refused our key". Was war passiert?

Der öffentliche Schlüssel in der Datei, die aus dem PuTTY Key Generator erstellt worden ist hat folgendes Format.

---- BEGIN SSH2 PUBLIC KEY ---- Comment: "rsa-key-20110416" AAAAB3NzaC1yc2EAAAABJQAAAIB5yJ/HodElR8lAzKQGrgfNyG9s3KwCGVR5/8l0 6d9tjCdcwDqmJxL6jBlJhY6BdZHv8m8LMXmI/E9lJl8kkms3QJGUqmHMYVv1tf2w TMXeWttP1oLDWHgg7txId5ewG2vSFLKShLeuXykPaQHzYUwBFEzWmMIh8VvjxgC5 9tsTlQ== ---- END SSH2 PUBLIC KEY ----

Die ersten beiden sowie die letzte Zeile kann schon mal gelöscht werden. Ebenfalls muss der Schlüssel in eine Zeile gepackt werden. Dass sieht dann so aus: (In vim macht man das mit der Tastenkombination Shift+J / Ausserdem nicht vergessen, die Leerschläge aus dem Key zu löschen!!)

AAAAB3NzaC1yc2EAAAAB.........WmMIh8VvjxgC59tsTlQ== (gekürzt)

Ob der String nun wirklich bloss aus einer Zeile besteht, kann überprüft werden, indem in vim die Zeilennummerierung mit ":set number" eingeschaltet wird.

Zum Schluss fügt man an den Anfang der Zeile, in unserem Fall, "ssh-rsa" ein. Jetzt kann der Schlüssel in diesem Format auf dem Server in die Datei authorized_keys eingetragen werden.

ssh-rsa AAAAB3NzaC1yc2EAAAAB.........WmMIh8VvjxgC59tsTlQ== (gekürzt)

Jetzt steht einer erfolgreichen Verbindungsaufnahme mit dem Server nichts mehr im Weg. Natürlich bin ich da nicht selber draufgekommen. Wer sich den Original-Artikel anschauen möchte findet ihn hier

Wenns mal länger dauert

Meinen Homeserver administriere ich via ssh von meinem Desktop-Rechner aus. Mich hat gestört, dass ich jeweils bis zu 15 Sekunden gewartet habe, bis ich die Shell vom Server zu Gesicht bekommen habe. Heute habe ich mich des Problems angenommen und schon nach kurzer Zeit via Google eine Lösung gefunden.

Auf dem Server muss in der Konfigurations-Datei /etc/ssh/sshd_config der Wert UseDNS no gesetzt werden. Damit wird Reverse DNS Lookup ausgeschaltet und schon flutscht das Login.

Fehlersuche ssh

Heute habe ich einige Zeit damit zugebracht, eine funktionierende ssh-Verbindung zu meinem Home-Server herzustellen. Aber nun der Reihe nach... Wenn ich einen Server aufsetzte, dann richte ich gleich nach Abschluss der Erstinstallation den openssh-Server ein, damit ich den Monitor am Server auschalten und die weitere Konfigurationen des Servers von einer Arbeitstation aus via ssh-Sitzung erledigen kann. Dazu mache ich aus einem Terminal eine ssh-Sitzung zum Server auf und lasse die als "Backup" stehen. Warum? Ganz einfach. Als nächsten Schritt kopiere ich den öffentlichen ssh-Schlüssel auf den Server und schalte in der Konfiguration-Daten /etc/ssh/sshdconfig als erstes mit dem Parameter "PermitRootLogin no" die Möglichkeit ab, sich als Root am System anzumelden und als zweites nehme ich mit "PasswordAuthentication no" einem ungebetenen Benutzer die Möglichkeit, sich mittels Benutzername/Passwort anzumelden. Sobald ich nun die Konfigurationsdatei speichere, den openssh-Server neu starte und ich einen Fehler gemacht habe und dadurch die Anmeldung per Schlüssel nicht funktioniern sollte, bin ich froh, dass ich meinen "Backup"-Verbindung noch offen habe. Ok, zu Hause ist das nicht weiter schlimm. Schlimmer wird es dann, wenn der Server 459 km entfernt bei einem Provider steht. Soweit so gut. Hat bei mir alles wunderbar funktioniert. Dann habe ich damit begonnen den Samba-Server einzurichten und habe dabei einen entscheidenden Fehler gemacht, wie sich erst einige Zeit später herausstellen sollte. Mein Problem manifestierte sich in der Fehlermeldung "Permission denied (publickey)" beim Versuch eine ssh-Verbindung zum Server aufzubauen, was vor fünf Minuten noch funktioniert hat. Nach einiger Zeit kam mir in den Sinn, dass ich schon einmal Probleme damit gehabt hatte und sich zum Schluss herausstellte, dass die Rechte des Verzeichnis ~/.ssh und der Datei ~/.ssh/authorizedkeys wie folgt gesetzt werden müssen: > chmod 700 /home/your_user/.ssh

chmod 600 /home/youruser/.ssh/authorizedkeys Ich habe also die Rechte sowohl client- als auch serversseitig kontrolliert. Leider war da nichts daran auszusetzen. Bis ich mir die Log-Datei /var/log/auth.log einmal aus der Nähe angeschaut habe. Dabei bin ich auf folgenden Eintrag gestossen: Authentication refused: bad ownership or modes for directory /home/xyz Nach ein wenig googeln habe ich dann den folgenden Hinweis gefunden: SSH doesn’t like it if your home or ~/.ssh directories have group write permissions. Your home directory should be writable only by you Also noch schnell die Rechte auf dem Home-Verzeichnis mit chmod g-w /home/xyz setzten, damit bloss noch der Besitzer des Verzeichnis Schreib-Rechte besitzt. Und siehe da, nach einem erneuten Anmelde-Versuch erhielt ich den gewohnten prompt des Servers. Ich hatte den Fehler beim Einrichten des Samba-Servers gemacht als ich, gemäss Handbuch, die Verzeichnisse, die mit Samba publik gemacht werden sollen, mit den Berechtigungen 770 (rwxrwx---) versehen. Toll, Schon wieder was gelernt.

12. Linuxday in Dornbirn

Am 27. November werde ich tagsüber hier anzutreffen sein. Welche Vorträge ich mir anschauen will weiss ich noch nicht genau, obwohl mich der eine oder andere Titel neugierig gemacht hat. Ich werde mich als ersten durch die Aussteller "arbeiten" und dann spontan entscheiden. Man(n) sieht sich. Linuxday 2010