Remote Batching created by Mathias Pelka / GCF Inhalt: Chapter I - Vorwort 1.1 An wen der Text gerichtet ist 1.1 An wen nicht Chapter II - Systemkonfigurartion 2.1 Serverkonfiguration 2.1.1 Vorbereitung 2.1.2 Benoetige Programme 2.1.3 Konfiguration des Servers 2.2 Clientkonfiguration 2.2.1 Vorbereitung 2.2.2 Benoetigte Programme 2.2.3 Konfigurartion des Clients Chapter III - Nachwort oder den Kram die sowieso niemand liest Chapter I - Vorwort ---- Die Idee dieses Texte kam mir sehr viel spaeter als die eigentliche Idee. Urspruenglich wollte ich eine Client/Server Kommunikation der in C geschrieben war, aber meine begrentzen C Kenntnisse und mangels Zeit verwarf ich diese Idee, als ich dann vor dem Problem stand auf ein paar Boxen in meinem LAN gleiche Software zu installieren, kamm mir die Idee es ueber SSH Tunnels laufen zu lassen, dieses System was ich hier vorstelle hat bereits in meinen LAN gute Dienste getan, und weil ich leicht vergesslich bin, hab ich meine Erfahrungen in diesen Text einfliessen lassen. Remote Batching ist meine Vorstellung zum verwalten von mehreren gleichen oder unterschiedlichen konfigurieten Computersystemen. Es setz auf Verschluesselung um Angreifern keinen Angriffspunkte zu ermoeglichen, die Schluesseluebergabe wurde bereits vollzogen, der Text geht deshalb davon aus das eine Verschluesselte Uebertragung sicher ist. Der Text behandelt nur Betriebsysteme die Unixkompatibel/Unixartig sind und ueber die Secure Shell verfuegen. 1.1 An wen der Text gerichtet ist ---- Der Text richtet sich an Systemverwalter die mehrere Unixartige Boxen verwalten, es loest Probleme die teure Software verlangen wuerde und an Lizensen gekoppelt sind. Wahrscheinlich gibt es in den weiten des Netzes tausende dieser Moeglichkeiten, aber dies ist meine Loesung dieses Problemes. Leute die gerne lesen und unterschiedliche Loesungen fuer ein Problem wissen wollen koennen aber auch gerne weiterlesen *g*. 1.2 An wen nicht ---- Der Text richtet sich nicht an Leute die meinen sie muesten Unixartige Betriebsysteme benutzen um 'cool' zu sein - das seid ihr naemlich nicht. 2.1 Serverkonfiguration 2.1.1 Vorbereitung ---- Ein Betriebsystem mit Netzwerkunterstuetzung und einen funktionierenden Netzwerk waere hier als sehr nuetzlich einzustufen, genuegend Platz auf der Festplatte und eine schlanke Betriebsysteminstallation waere auch nicht schlecht. Da ein Server immer ein Angriffspunkt ist, moechte ich darauf hinweisen das alle angebotenen Dienste auf ihre Sicherheit zu ueberpruefen sind. 2.1.2 Benoetige Programme ---- Wie oben gesagt werden wir OpenSSH benutzen (www.openssh.org), eventuell erfordet OpenSSH noch einige anderen Programme/Bibilotheken, die werden dann auch installiert. . 2.1.3 Konfiguration des Servers ---- Den SSH daemon sollte man aber generell standalone starten, weil er sonst bei jedem Systemstart einen neuen Schluessel generiert. Ein einfacher Portscan verraet ob der SSH daemon laueft, per default auf Port 22. Mit der Installation der Secure Shell ist auch ein weiteres wichtiges Programm installiert worden; scp - es ermoeglicht das Kopieren von Dateien ueber das Netzwerkinterface. ,----[ Shell ] | bash-2.04$ scp testfile1 sshuser@aggamemnon:testfile2 | sshuser@aggamemnon's password: | testfile1 100% |*****************************| 0 --:-- ETA | bash-2.04$ ls | testfile1 testfile2 `---- Sieht doch schon gut aus. Da wir aber die Autentification automatisch ablaufen lassen wollen, ist es eine kluge Idee einen eigenen User auf dem Server anzulegen, er sollte nicht allzuviele rechte haben, zusaetzliche Gruppen braucht er ebenfalls nichts. Ausloggen, Einloggen mehr braucht er nicht zu koennen. In seinen Heimtatverzeichnis koennen nachher auch die Scripte und die Packete gelagert werden. Auf unserer Test Box mennen wir ihn 'sshuser', jetzt sollten wir alle Computer in unseren Netzwerk unseren oeffentlichen Schluessel mitteilen damit die Autentification Automatisch erfolgt. Also, wir loggen uns als 'sshuser' ein, tippern 'ssh-keygen -f ~/.ssh/identity -N '''. Damit generieren wir Schluessel, der generierte Schluessel in '~/.ssh/identity.pub' muss in jede '~/.ssh/authorized_keys' eingefuegt werden die den Service nutzen wollen. Damit wird gewaehrleistet das der, der den Key erstellt der alleinige Besitzer ist, also mueste er ueber eine vertrauensvollen Umgebung auf andere Hosts uebertragen werden. (Technisch gesehen brauechten die Clients nicht den Key des Servers, das kann aber ab und an nuetzlich sein) ,----[ Shell ] | bash-2.04$ id | uid=503(sshuser) gid=100(users) Gruppen=100(users) `---- ,----[ Shell ] | bash-2.04$ ssh sshuser@aggamemnon | sshuser@aggamemnon's password: ^C `---- ,----[ Shell ] | bash-2.04$ ssh-keygen -f ~/.ssh/identity -N '' | Generating RSA keys: Key generation complete. | Your identification has been saved in /home/sshuser/.ssh/identity. | Your public key has been saved in /home/sshuser/.ssh/identity.pub. | The key fingerprint is: | f8:88:6a:2d:bb:1b:0b:b6:4d:fa:ef:cf:56:49:17:c7 sshuser@aggamemnon `---- ,----[ Shell ] | bash-2.04$ cat identity.pub >> authorized_keys `---- ,----[ Shell ] | bash-2.04$ ssh sshuser@aggamemnon | Last login: Fri Sep 27 20:51:45 2002 from aggamemnon.deadalus-node | | sshuser@aggamemnon:~ > `---- Klappt doch wunderbar und zeigt auch wies es geht. Das wars auch schon mit der Konfigurartion des Servers, durch das eigene Homeverzeichnis ist der User vor neugierigen blicken geschuetz der Account hat keine weiteren Rechte, also falls dieser Account uebernommen werden sollten, sollte es in einer gesicherten Umgebung zu keinem Schaden kommen. 2.2 Client Konfigurartion 2.2.1 Vorbereitung ---- Wie auch der Server sollte der Client ebenfalls netzwerkfaehig sein ein C Compiler zum kompilieren der Packages koennten sich ebenfalls als nuetzlich erweisen. 2.2.2 Benoetigte Programme ---- Wie benoetigen in diesem falle das Packet 'ssh' dort bekommen wir 'scp' mitgeliefert, desweiteren brauchen wir den 'cron' daemon - oder den 'at' daemon das muss jeder selber wissen. Die beiden Packete werden installiert bei 'ssh' ist drauf zu achten das der 'sshd' nicht benoetigt wird. 2.2.3 Konfigurartion ---- Auch hier empfehle ich einen eigenen Benutzer einzurichten damit er sein eigenes Heimatverzeichnis bekommt. Ausserdem faellt dadruch das Verwalten der Accounts leichter. Auf meinem Systemen heist der gute Mann 'cron' - da sich cron ueber gewisse Verzeichnisrechte hinwegsetzen kann, ausserdem kann 'cron' ist so zerstoererisch wie 'root' auch wenn nicht mehr viel fehlt. Da der Server den Key des Clients braucht um keine Passwortabfrage zu bekommen muessen wir den Key des Clients auf den Server uebertragen - also erstellen wir ihn. Selbes verfahren wie beim Servers; 'ssh-keygen -f ~/.ssh/identity -N '''. Danach fuegen wir den Key ('.ssh/identity.pub') in die '.ssh/authorized_keys' des Servers ein. ,---- | cron@aggamemnon:~ > ssh-keygen -f ~/.ssh/identity -N '' | Generating RSA keys: Key generation complete. | Your identification has been saved in /home/cron/.ssh/identity. | Your public key has been saved in /home/cron/.ssh/identity.pub. | The key fingerprint is: | 06:73:39:b7:0f:49:45:55:0d:fd:af:60:04:e8:53:e4 | cron@aggamemnon `---- ,----[ Shell ] | cron@aggamemnon:~ > scp .ssh/identity.pub sshuser@aggamemnon:file | sshuser@aggamemnon's password: | identity.pub 100% |*****************************| 345 | 00:00 `---- ,----[ Shell ] | cron@aggamemnon:~ > ssh sshuser@aggamemnon | sshuser@aggamemnon's password: | Last login: Sat Sep 28 18:01:06 2002 from aggamemnon.deadalus-node `---- ,----[ Shell ] | sshuser@aggamemnon:~ > cat file >> .ssh/authorized_keys `---- ,----[ Shell ] | sshuser@aggamemnon:~ > exit | logout | Connection to aggamemnon closed. `---- ,----[ Shell ] | cron@aggamemnon:~ > ssh sshuser@aggamemnon | Last login: Sat Sep 28 18:01:38 2002 from aggamemnon.deadalus-node | | sshuser@aggamemnon:~ > `---- So klappt das doch ohne Probleme. Nun haben wir die Moeglichkeit in einem Shellskript das vom 'cron' daemon aufgerufen wird uns auf den Server zu verbinden ein Skript runterzuladen (mittels 'scp') das den ausgefuehrt wird. Das runtergeladenen Shellskript arbeitet sich dann ab und fuehrt die Anweisungen auf. Als letzen Code ist hier mein Shellskript das von 'cron' einmal taeglich auf alles meinen Boxen aufgerufen wird. ,----[ Shellskript ] | #!/bin/sh | cd /home/cron/ | scp sshuser@aggamemnon:batchfile /home/cron/batchfile | chmod 755 /home/cron/batchfile | /home/cron/batchfile `---- Chapter III - Nachwort oder den Kram den sowieso niemand liest ---- Ich uebernehme erstmal keine Haftung ueber das was hier steht, benutzen auf eigenen Gefahr :)). SSH ist eine feine sache, aber nicht immer sicher; wenn die Schluesseluebergabe verhunzt ist kann man sich nicht auf eine abhoersichere Verbindung verlassen. Also da muest ihr aufpassen, regelmaessige Besuche auf www.openssh.org schaden bestimmt auch nicht weil dort regelmaessig neue Versionen erscheinen und eventuell auch Sicherheitspatche. Bedanken moechte ich mich hier mal bei den Programmieren von 'xemacs', 'gnus' und 'boxquote.el' dazu die ueblichen Verdaechtigen die mir geholfen haben.