| orm@doc-tcpip.org | Erstellt: April 2000 - Letzte Modifikation: September 2003 |
Zwischen Unix-Systemen wird traditionel mit Kommandos wie telnet oder den r-Kommandos (rlogin, rsh etc.) kommuniziert. Diese Kommandos nutzen als einzige Sicherheit den Usernamen, den Hostnamen und die IP-Adresse. Diese Angaben werden in Files wie .rhosts und /etc/hosts.equiv hinterlegt, und je nach Konfiguration wird nicht mehr nach einem Passwort gefragt. Eine Passwort-Abfrage geht in diesen Fällen immer im Klartext über das Netz.
Diese Methoden lassen deshalb eine Reihe Angriffe zu, vom Mitlesen der Passwörter (Sniffing), über das Stehlen einer IP (IP-Spoofing) bis zum Fälschen von DNS-Information (DNS-Spoofing). Es ist also ein Mechanismus nötig, der die Information verschlüsselt (damit es nichts zum mithören gibt), den Partner authentifiziert (damit sich niemand einschleichen kann) und die Integrität der Daten sicherstellt (damit die Daten nicht verändert werden können).
Das Konzept beruht auf einem Schlüsselpaar, also Client und Server haben je einen privaten Schlüssel und einen öffentlichen Schlüssel. Diese werden auf der jeweilen Maschine zufallsgesteuert erzeugt. Beide Schlüssel sind mathematisch voneinander abhängig, es ist jedoch praktisch nicht möglich, den einen aus dem anderen abzuleiten. Der private Schlüssel wird sorgfältig geschützt und darf nie preisgegeben werden. Der öffentliche Schlüssel wird bekannt gegeben. Jetzt kann jede Information vom Sender mit dem privaten Schlüssel übersetzt werden. Diese verkodete Information kann vom Empfänger unter zuhilfenahme des öffentlichen Schlüssels des Senders gelesen werden.
Dieses System ist eine asymetrische Verschlüsselung. Für reine Datenübertragung nutzt man meist die schnellere symetrische Verschlüsselung, bei der beide Seiten densselben Schlüssel teilen (Das Problem des Austausches des Schlüssels ist durch das Vorschalten der SSH gelöst).
Aus historischen Gründen gibt es zwei Versionen, SSH1 und SSH2. Beide haben Vor- und Nachteile und sind momentan in Benutzung. Der Trend geht aber zu SSH2. Die Versionen sind nicht kompatibel.
SSH1 - Wurde in starker Anlehnung an die Funktion der r-Kommandos entwickelt. Folgende Methoden werden zur Authentifizierung benutzt:
Es werden die Files /etc/hosts.equiv, /etc/shosts.equiv und .rhosts bzw. .shosts ausgewertet. Auf dieser Basis wird Zugang gewährt. Diese Methode sollte man nicht benutzen, schließlich braucht man dafür kein SSH (Im Konfigurationsfile sollte RhostsAuthentication no stehen).
Auch in diesem Fall werden die Files /etc/hosts.equiv, /etc/shosts.equiv und .rhosts bzw. .shosts ausgewertet. Allerdings wird die Identität des Kommunikationspartners vom Server geprüft. Der Server sucht in den Dateien /etc/ssh/known_hosts und $HOME/.ssh/known_hosts nach einem für den Client gültigen, öffentlichen Schlüssel. Damit wird dann eine Anfrage (Challenge) verkoded, die der Client nur verstehen kann, wenn er es wirklich selbst ist und über den richtigen privaten Schlüssel verfügt. Der User kann die öffentlichen Schlüssel seiner Kommunikationspartner selbst verteilen, sind die öffentlichen Schlüssel verteilt, so tut der sshd die Arbeit für ihn. Das fällt unter das Stichwort RSA basierende Authentifizierung (Statement RhostsRSAAuthentication yes).
Richtige RSA Authentifizierung. Der User generiert sein Schlüssel-Paar (privater und öffentlicher Schlüssel). Diese stehen in den Files $HOME/.ssh/identity.pub und $HOME/.ssh/identity. Der User muß nun den öffentlichen Schlüssel auf den Server kopieren, mit dem er arbeiten möchte (File $HOME/.ssh/authorized_keys). Mit dieser Methode ist der User authentifiziert, daher ist es die Methode der Wahl. Im Konfigurationsfile ist das Statement RSAAuthtication yes.
Versagen die vorgenannten Methoden, dann wird das User-Passwort abgefragt, wie unter Standard-Telnet etc.. Dabei wird jedoch das Passwort Verschlüsselt übertragen.
SSH2 - Versucht, mit dem Unzulänglichkeiten von SSH1 aufzuräumen. Es gibt nur noch zwei Methoden den Authetifizierung (RSA-basierend und Passwort-Abfrage). Neu hinzugekommen ist die Möglichkeit, den Verkehr voll zu verschlüsseln. Dazu stehen verschiedene Algorithmen zur Verfügung: 3DES, Blowfish, CAST128 und Arcfour. Zum Erzeugen von Datei-Checksummen zur Integritäts-Prüfung werden hmac-sha1 und hmac-md5 eingesetzt. Die eingesetzten Methoden sind:
RSA Authentifizierung, jedoch unter Benutzung von DSA (weil RSA patentiert ist). Wieder wird ein Schlüssel-Paar (privater und öffentlicher Schlüssel) erzeugt. Diese stehen in den Files $HOME/.ssh/id_dsa.pub und $HOME/.ssh/id_dsa. Der User muß nun den öffentlichen Schlüssel auf den Server kopieren, mit dem er arbeiten möchte (File $HOME/.ssh/authorized_keys2).
Abfrage des User-Passwortes. Wie unter Standard-Telnet etc.. Dabei wird jedoch die Übertragung voll Verschlüsselt durchgeführt - d.h. die Daten als solche sind verschlüsselt, und die Pakete mit einem Integritätscheck versehen.
Ich beziehe mich hier ausschließlich auf OpenSSH und auf AIX. Es wird keine großen Unterschiede zu anderen Implementationen geben, aber Starten und Bedienen der Deamons dürfte doch seine Eigenheiten haben.
OpenSSH besteht aus dem Deamon, also dem Server, an sich (sshd) sowie einiger SSH-Clients, die die bekannten r-Kommandos ersetzen. Das ist einmal ssh, das auch mit dem Befehl slogin angezogen wird. Als Ersatz für rcp und in gewisser Weise für ftp dient scp. Auf jeder Maschine muß der sshd laufen, damit Anforderungen der Clients per ssh bedient werden können. Neben denn eigentlichen Diensten stehen noch eine Reihe Administrations-Befehle zur Verfügung: Einmal zu Erzeugen der RSA-Schlüssel (ssh-keygen) sowie ein SSH-Agent, der es ermöglicht, private Schlüssel zu verwalten und die Authentifizierung zu automatisieren. Dazu gehört ein Befehl, der neue Schlüssel mit dem Agenten registriert (ssh-agent, ssh-add).
Die Tools zur Verwaltung der Schlüssel sind recht vielseitig, man kann sich die Schlüssel anzeuigen lassen, die Pas-Phrasen ändern, Fingerprints anzeigen, und fehlende öffentliche Schlüssel neu erzeugen.
Zusätzlich sind noch einige modifizierte Libraries nötig, die eine Secure Socket Layer (SSL, also die Kryptographischen Algorithmen) zur Verfügung stellen, Kompressions-Algorithmen (zlib) und ein Werkzeug, das "wirkliche" (Höhöhö) Zufallszahlen generiert (Pseudo Random Number Generator Daemon). Ein eigener Deamon, der dauernd laufen muß und einen Pool an Zufallswerten zur Verfügung stellt. Der Daemon heißt prngd.
Für AIX 4.3.3 und AIX 5.1 kann man von der IBM eine angepasste OpenSSH beziehen, die sich problemlos installieren läßt. Bei der AIX 4.3.3 Version handelt es sich um RPM-Pakete, bei AIX 5.1 muß man RPM-Pakete und Installp-Images getrennt installieren. In AIX 5.2 wird das vielleicht alles besser...
Beide Versionen verlangen als Vorraussetzung die Filesets rpm.rte und perl.rte. Das Perl Fileset ist auf den Installations CDs, das RPM Fileset findet sich in der Linux-Toolbox . Man installiert beide Filesets per smitty/installp.
Es ist durchaus möglich, das sich die Filesets nicht mehr unbedingt an den genannten Adressen befinden - eine kurze Suche auf der IBM-Homepage sollte sie aber ans Tageslicht fördern.
Die RPM-Pakete der OpenSSH gibt es auch auf diese Seite. Dabei braucht man den Generator für Zufallszahlen (prngd) und die Kompressions-Bibliothek (zlib). Die Kryptographie-Teile der OpenSSH finden sich in einem eigenen Unterverzeichnis, Cryptographic Content.
Für die Installation unter AIX 4.3.3 sind folgende Pakete von der Webseite zu holen und in dieser Reihenfolge zu installieren:
rpm -i zlib-1.1.4-2.aix4.3.ppc.rpm rpm -i prngd-0.9.23-3.aix4.3.ppc.rpm rpm -i openssl-0.9.6g-3.aix4.3.ppc.rpm rpm -i openssl-devel-0.9.6g-3.aix4.3.ppc.rpm (optional) rpm -i openssl-doc-0.9.6g-3.aix4.3.ppc.rpm (optional) rpm -i openssh-3.4p1-8.aix4.3.ppc.rpm rpm -i openssh-clients-3.4p1-8.aix4.3.ppc.rpm rpm -i openssh-server-3.4p1-8.aix4.3.ppc.rpm
Für die Installation unter AIX 5.1 sind folgende RPM-Pakete von der Webseite zu holen und entsprechend zu installieren. Zusätzlich muß von folgender Seite ein Tar-File mit den Installp-Paketen der OpenSSH geholt werden: OpenSSH on AIX Bonus Pack Project . Dieses wird dann in ein Verzeichnis ausgepackt, und nach ausführen von inutoc . im Verzeichnis per Smitty installiert. Installiert wird das Base-Paket, die Lizenz und Manual- sowie Message-Katalog in der gewünschten Sprache. Wichtig ist dabei, im Smitty anzugeben, daß man neue Lizenz-Abkommen akzeptieren möchte.
rpm -i zlib-1.1.4-2.aix4.3.ppc.rpm rpm -i prngd-0.9.23-3.aix4.3.ppc.rpm rpm -i openssl-0.9.6g-3.aix4.3.ppc.rpm rpm -i openssl-devel-0.9.6g-3.aix4.3.ppc.rpm rpm -i openssl-doc-0.9.6g-3.aix4.3.ppc.rpm tar xvf openssh34p1_51.tar inutoc . smitty install
Folgende Änderungen kann man auf dem System nach der Installation festestellen:
Im $HOME des Users wird ein neues Verzeichnis angelegt: .ssh. Dieses Verzeichnis enthält zuerst nur eine Datei mit einem Startwert für den Random Number Generator (prng_seed).
# od prng_seed 0000000 155023 117543 144542 006371 000775 122220 025464 051515 0000020 037742 125770 133604 022364 032317 153133 173234 171576 ....... 0001760 061347 023115 067072 013542 127733 101002 065057 014705 0002000
Im Verzeichnis /etc werden verschiedene Dateien und Verzeichnisse erzeugt bzw. modifiziert.
In der Inittab wird ein Eintrag zum Start des
Pseudo Random Number Generator Daemons gemacht:
prng:2:wait:/usr/bin/startsrc -sprngd
In diesem Zusammenhang stehen die Dateien
prngd-seed und prngd.conf.
Die Datei prngd-seed ist wieder ein Startwert,
also ein Kristallisationskeim für den
Zufallszahlen-Generator. Die Datei prngd.conf
definiert die Unix-Kommandos, die ausgeführt werden
und deren zeitliches Verhalten als Grundlage des
Generators dient. Hier ein Ausschnitt:
# The "rate" represents the number of bits of usuable entropy per # byte of command output. Be conservative. "ls -alniR /var/adm" /usr/bin/ls 0.03 "ls -alni /var/mail" /usr/bin/ls 0.01 "ls -alni /tmp" /usr/bin/ls 0.02 "arp -a" /usr/sbin/arp 0.02 "ifconfig -a" /usr/sbin/ifconfig 0.01 "ps laxww" /usr/bin/ps 0.03 "ps -al" /usr/bin/ps 0.03 "ps -efl" /usr/bin/ps 0.03 ......... "vmstat" /usr/bin/vmstat 0.02 "iostat" /usr/bin/iostat 0.02 "vmstat -s" /usr/bin/vmstat 0.01
Es wird ein neuer Nutzer und eine neue Gruppe für
den SSH-Daemon eingerichtet:
sshd:*:205:206::/var/empty:/usr/bin/ksh
und
sshd:!:206:sshd
Die Kommandos finden sich jetzt im Verzeichnis /usr/bin. root:/usr/bin> ls ss* sscontrol ssh-add ssh-keygen ssh-keysign sswizard ssh ssh-agent ssh-keyscan ssserver
Der Start des sshd wird jetzt aus den rc-Verzeichnissen gestartet, so wie es unter SUN und Linux üblich ist - für einen AIX User zuerst etwas ungewöhnlich:
root2:/etc/rc.d/rc2.d> ls -lart total 32 drwxr-xr-x 10 root system 512 Apr 16 2001 .. -r-xr-xr-x 1 root system 308 Sep 09 11:45 Ssshd -r-xr-xr-x 1 root system 307 Sep 09 11:45 Ksshd drwxr-xr-x 2 root system 512 Sep 09 11:45 .Für jedes Runlevel des Systemes gibt es ein entsprechendes Unterverzeichnis. Alle darin befindlichen Scripte werden vom rc-Prozess abgearbeitet. Unter AIX 4.3.3 heißt das Verzeichnis übrigens noch init.d. Im vorigen Beispiel ist es das Verzeichnis rc2.d, also das für den Runlevel 2 zuständige. Unter AIX findet sich hier natürlich nur wenig, die anderen Dienste werden über die Inittab und die rc.files gestartet.
Der Aufruf dieses Mechanismus erfolgt über die
Inittab:
l2:2:wait:/etc/rc.d/rc 2
Das System legt für den sshd ein eigenes Verzeichnis für alle Konfigurations- und Key-Files an. Das Verzeichnis ist /etc/ssh.
root:/etc/ssh> ls moduli ssh_host_dsa_key.pub ssh_host_rsa_key sshd_config ssh_config ssh_host_key ssh_host_rsa_key.pub ssh_host_dsa_key ssh_host_key.pub ssh_prng_cmds
Hier finden sich die Maschinenschlüssel, wie gehabt der eigene, geheime Schlüssel und der öffentliche Schlüssel des PGP Schlüsselpaares. Im Standard-Fall ist es ein DSA und ein RSA Schlüssel. Weiterhin finden sich hier die Konfigurationsfiles für den SSH-Daemon (sshd) sowie für den SSH-Client (ssh-Kommando). Im File ssh_prng_cmds werden die für den Zufallszahlen Generator benutzten Kommandos benutzt.
Auf dem System laufen jetzt in der Regel folgende Daemons:
Subsystem Group PID Status prngd prng 16900 active sshd ssh 18286 active
Ein erstes Login auf den Localhost führt dazu, das der lokale Rechner sich den öffentlichen Schlüssel des remoten Rechners geben läßt. Will man ganz sicher sein, so muß man diese Möglichkeit selbstverständlich per Konfiguration unterdrücken und die Keys von Hand austauschen.
root:/> ssh nfsserver The authenticity of host 'nfsserver (172.16.1.2)' can't be established. . key fingerprint is RSA. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'nfsserver,172.16.1.2' (RSA) to the list of known hosts. root@nfsserver's password: * * * Welcome to AIX Version 5.1! * * * root:/>
Man wird gefragt, ob man diesen potentiell gefährlichen Schritt tun möchte, wenn man das bejaht, so wird der remote Rechner mit Namen und Key in die eigene Datei der vertauenswürdigen Rechner eingetragen. Diese Datei (known_hosts wird automatisch im Verzeichnis /$HOME/.ssh des aktiven Users erzeugt. Der entstandene Eintrag sieht so aus:
root:/.ssh> cat known_hosts nfsserver,172.16.1.2 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA1dAwna1LIDCkhyJ+Zi7V4+g9JCUdIho2tEB6Cm1Sux+mPLPVwNw2mZfAOQBor7Wn/stfRYln/B+7V/jS3srwhs5kXYltAxYBCXXMrXhmVi+WB/8ankQJFsFJzUuul9JwpjX9c4nnEdsq0Q6nmEexXuj75oR6/pCfCb8+sY+Vndk= root:/.ssh>
Diese Datei entsteht auf dem Client, im Verzeichnis und Einfluss-Bereich des Users.
Ein Login von Remote ist analog:
# ssh nfsserver The authenticity of host 'nfsserver (172.16.1.2)' can't be established. . key fingerprint is RSA. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'nfsserver,172.16.1.2' (RSA) to the list of known hosts. root@nfsserver's password: * * * Welcome to AIX Version 5.1! * * * root:/>
Auch auf diesem CLient findet sich jetzt der entsprechende Schlüssel als bekannt und Vertauenswürdig:
# cat known_hosts nfsserver,172.16.1.2 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAIEA1dAwna1LIDCkhyJ+Zi7V4+g9JCUdIho2tEB6Cm1Sux+mPLPVwNw2mZfAOQBor7Wn/stfRYln/B+7V/jS3srwhs5kXYltAxYBCXXMrXhmVi+WB/8ankQJFsFJzUuul9JwpjX9c4nnEdsq0Q6nmEexXuj75oR6/pCfCb8+sY+Vndk=
Generell gilt: ich als User muß meinen öffentlichen Schlüssel auf allen Zielsystemen hinterlegen - und zwar von Hand. Dann muß meine Maschine die Ziel-Maschine identifizieren können, das geht analog durch einen Austausch der öffentlichen Maschinen-Schlüssel. Je nach nach Konfiguration geht das auch manuell; allerdings machen die meisten Sites das automatisch. Es kommt dann nur eine Abfrage beim ersten Login. Sicher ist natürlich nur der Austausch der Schlüssel von Hand, also per Diskette (Oder abtippen ;-).
Hier ein Beispiel, um das Ganze klarer zu machen.
Ich will mich als User a von Maschine A auf B als User root
einloggen, ohne nach dem Passwort gefragt zu werden.
Dazu brauchen beide Maschinen ihren Satz an Host-Keys (ssh_host_xxx_key und ssh_host_xxx_key.pub). Natürlich braucht der User auch seine eigenen Keys, die genauso wie die Host-Keys durch den User erzeugt werden - und zwar im Verzeichnis $HOME/.ssh. Die Keys haben allergins andere Namen: id_dsa und id_dsa.pub (Für RSA gilt das gleiche..).
Soll sich nun User a von Maschine A als User root auf Maschine B einloggen können (ohne Angabe eines Passwort), dann müssen folgende Dinge vorhanden sein:
Der öffentliche Schlüssel (id_dsa.pub) von User a muß im $HOME/.ssh des User root auf der Maschine B im File authorized_keys2 (alles im Fall von DSA Verschlüsselung) stehen.
Der öffentliche Schlüssel der Maschine B muß im Verzeichnis $HOME/.ssh des Users a auf Maschine A stehen - und zwar im File known_hosts2.
Es gibt eine Reihe Möglichkeiten, das zu erleichtern oder zu erschweren: Man kann die Maschinen-Keys austauschen, also jeder Maschine einen Satz aller öffentlichen Schlüssel geben und dann jegliche User-Files abschalten. Oder man automatisiert den Austausch, der User muß dann nur noch auf Enter drücken.
Die eigentliche Zugriffskontrolle erfolgt durch die Bereitschaft der anderen Seite, den eigenen, öffentlichen Schlüssel bei sich in einem Verzeichniss zu speichern. Löscht man diese Schlüssel, dann kann niemand mehr herein...
Der User root auf der Maschine nfsclient soll ohne Passwort als User nfs-admin auf der Maschine nfsserver einloggen bzw. Kommandos ausführen können.
Dazu muß User root ersteinmal eine Schlüssel-Paar erzeugen (hier mit RSA, DSA ist aber genauso gut und man hat keine Lizenz-Probleme). Die Länge des Schlüssels kann man ganz nach gefallen bestimmen (Schalter -b), Standard ist 1024:
# ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (//.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in //.ssh/id_rsa. Your public key has been saved in //.ssh/id_rsa.pub. The key fingerprint is: 55:13:bb:7a:a5:37:8b:ba:21:30:39:e7:fd:70:5a:29 root@oepd1
Hier hat der User root eine Pass-Phrase angegeben, also einen Satz als Passwort. Diesen muß er jetzt jedesmal eintippen, wenn er auf nfsserver der User nfs-admin sein möchte. Da wird er sich gleich ärgern.
Das Verzeichnis /$HOME/.ssh sieht jetzt so aus:
# ls id_rsa id_rsa.pub known_hosts prng_seedNeu sind die Files id_rsa.pub (der öffentliche Schlüssel) und id_rsa (der geheime Schlüssel). Wenn eine zweite Person den geheimen Schlüssel sieht, so muß sie sofort sterben - sonst ist die Sicherheit des Schlüsselpaares für die Katz.
Wie sehen jetzt solche Schlüssel aus? Es ist eine lange Zahl, eigentlich. Diese Zahl wird Binär gespeichert, mit dem od-Kommando kann man sie ansehen und auswendig lernen.
# od id_rsa.pub 0000000 071563 064055 071163 060440 040501 040501 041063 047172 0000020 060503 030571 061462 042501 040501 040502 044567 040501 ....... 0000300 066520 031105 073063 070507 066553 044153 074130 030075 0000320 020162 067557 072100 067545 070144 030412 0000334 # # od id_rsa 0000000 026455 026455 026502 042507 044516 020122 051501 020120 0000020 051111 053101 052105 020113 042531 026455 026455 026412 ....... 0001640 042040 051123 040440 050122 044526 040524 042440 045505 0001660 054455 026455 026455 005000 0001667
Jetzt muß User root den User nfs-admin dazu bringen, daß dieser den öffentlichen Schlüssel des User root in seinem /$HOME/.ssh in einer Datei namens authorized_keys ablegt. Man kann das über das Netz übertragen, wenn man z.B. telefonisch Passwörter austauscht, oder man schickt eine Diskette (man kann auch ein sehr schönes und teures PKI System installieren).
Unser User root kennt das Passwort des Users
nfs-admin und überträgt die Datei per SCP.
scp id_rsa.pub nfsserver:/.ssh/authorized_keys
Jetzt ist ein Login mit Pass-Phrase über SSH möglich; es ist dabei nur nötig, den gewünschten User und die entsprechende remote Maschine anzugeben:
# ssh nfs-admin@nfsserver Enter passphrase for key '/.ssh/id_rsa': * * * Welcome to AIX Version 5.1! * * * nfsadmin:/>
Die Pass-Phrase muß entsprechend zum angegeben Schlüssel eingetippt werden. Bei vielen Keys kommt man da leicht durcheinander.
Praktischerweise hätte man in diesem Fall die Pass-Phrase weggelassen, um sofort auf die Kommandozeile zu kommen bzw. Kommandos per SSH direkt auszuführen.
Das ist dann komplett analog zu RSH:
# ssh nfs-admin@nfsserver date Tue Sep 16 12:51:20 CEST 2002 #
Zum Debuggen sollte Syslog an sein. Dazu steht etwas in
dieser Art in /etc/syslog.conf:
*.debug /tmp/syslog.out rotate size 100k files 4
Tut es das nicht, dann wird es eingetragen und das gewünschte
File angelegt sowie ein refresh gegen den Syslog-Daemon gemacht.
root:/var> touch /tmp/syslog.out root:/var> refresh -s syslogd 0513-095 The request for subsystem refresh was completed successfully.
Jetzt tauchen im Syslog Einträge dieser Art auf, die sich leicht zuordnen lassen:
Sep 9 12:57:14 nfsserver sshd[15150]: Failed password for root from 172.16.1.3 port 37722 ssh2 Sep 9 12:57:14 nfsserver syslog: ssh: failed login attempt for root from 172.16.1.3 # # Ein Versuch, sich mit dem falschen Passwort einzuloggen # Sep 9 12:57:38 nfsserver sshd[15150]: Accepted password for root from 172.16.1.3 port 37722 ssh2 # # Jetzt das richtige Passwort. # Sep 9 13:00:42 nfsserver sshd[15158]: Accepted publickey for root from 172.16.1.3 port 37723 ssh2 # Ein SSH Login mit Pass-Phrase Sep 9 13:05:04 nfsserver sshd[15182]: Accepted publickey for root from 172.16.1.3 port 37725 ssh2 # # Ein SSH Login ohne Pass-Phrase # Man kann also nur unterscheiden, ob ein öffentlicher Schlüssel # remote liegt. #
Für besonders harte Fälle läßt man zusätzlich den
SSH-Daemon noch loggen. Dazu muß er gestoppt und mit
einem Flag (-d) neu gestartet werden.
Es gibt mehrere Log-Level, die durch die Anzahl der
Schalter hochgezählt werden. Man kann den SSH-Daemon
mit dem Befehl
startsrc -s sshd -a "-d"
neu starten - dann geht der Daemon in den Hintergrund,
und die Debug-Meldungen kommen auf den Schirm. Besser
ist, den Daemon auf der Kommandozeile zu starten:
sshd -d
Dabei wird nur ein Login durchgeführt, der Daemon
bleibt im Vordergrund und steigt nach dem Login
sofort wieder aus.
root@nfsserver:/.ssh> sshd -d debug1: sshd version OpenSSH_3.6.1p2-pwexp22 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Server will not fork when running in debugging mode. # # Das erzählt der Daemon # # Jetzt kommt eine Verbindung von einem Client: # Connection from 172.16.1.3 port 37736 debug1: Client protocol version 2.0; client software version OpenSSH_3.6.1p2-pwexp22 debug1: match: OpenSSH_3.6.1p2-pwexp22 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2-pwexp22 debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): A file or directory in the path name does not exist. debug1: Failed dlopen: /usr/krb5/lib/libkrb5.a(libkrb5.a.so): A file or directory in the path name does not exist. debug1: permanently_set_uid: 205/206 debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: client->server aes128-cbc hmac-md5 none debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user root service ssh-connection method none debug1: attempt 0 failures 0 Failed none for root from 172.16.1.3 port 37736 ssh2 Failed none for root from 172.16.1.3 port 37736 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 1 failures 1 debug1: test whether pkalg/pkblob are acceptable debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file //.ssh/authorized_keys debug1: matching key found: file //.ssh/authorized_keys, line 1 Found matching RSA key: 55:13:bb:7a:a5:37:8b:ba:21:30:39:e7:fd:70:5a:29 debug1: restore_uid: 0/0 Postponed publickey for root from 172.16.1.3 port 37736 ssh2 debug1: userauth-request for user root service ssh-connection method publickey debug1: attempt 2 failures 1 debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: trying public key file //.ssh/authorized_keys debug1: matching key found: file //.ssh/authorized_keys, line 1 Found matching RSA key: 55:13:bb:7a:a5:37:8b:ba:21:30:39:e7:fd:70:5a:29 debug1: restore_uid: 0/0 debug1: ssh_rsa_verify: signature correct Accepted publickey for root from 172.16.1.3 port 37736 ssh2 debug1: monitor_child_preauth: root has been authenticated by privileged process Accepted publickey for root from 172.16.1.3 port 37736 ssh2 debug1: Entering interactive session for SSH2. debug1: fd 7 setting O_NONBLOCK debug1: fd 8 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 65536 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug1: session_new: init debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_channel_req: channel 0 request pty-req reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/4 debug1: server_input_channel_req: channel 0 request shell reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell debug1: temporarily_use_uid: 0/0 (e=0/0) debug1: restore_uid: 0/0 setsid: Operation not permitted. debug1: channel 0: rfd 10 isatty debug1: fd 10 setting O_NONBLOCK # # Das hat also funktioniert. # Dann der Logout: # debug1: Received SIGCHLD. debug1: session_by_pid: pid 17918 debug1: session_exit_message: session 0 channel 0 pid 17918 debug1: channel 0: request exit-status debug1: session_exit_message: release channel 0 debug1: channel 0: write failed debug1: channel 0: close_write debug1: channel 0: output open -> closed debug1: session_close: session 0 pid 17918 debug1: session_pty_cleanup: session 0 release /dev/pts/4 debug1: channel 0: read<=0 rfd 10 len -1 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug1: channel 0: ibuf empty debug1: channel 0: send eof debug1: channel 0: input drain -> closed debug1: channel 0: send close debug1: channel 0: rcvd close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: server-session, nchannels 1 Connection closed by 172.16.1.3 Closing connection to 172.16.1.3 root:/.ssh>
# ssh root@nfsserver * * * Welcome to AIX Version 5.1! * * * debug1: permanently_set_uid: 0/0 Environment: USER=root LOGNAME=root LOGIN=root HOME=/ PATH=/usr/bin:/etc:/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin:/usr/java130/jre/bin:/usr/java130/bin MAIL=/var/spool/mail/root SHELL=/usr/bin/ksh TZ=NFT-1DFT SSH_CLIENT=172.16.1.3 37736 22 SSH_CONNECTION=172.16.1.3 37736 172.16.1.2 22 SSH_TTY=/dev/pts/4 TERM=dtterm AUTHSTATE=compat LANG=en_US LOCPATH=/usr/lib/nls/loc NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat LC__FASTMSG=true ODMDIR=/etc/objrepos ITECONFIGSRV=/etc/IMNSearch ITECONFIGCL=/etc/IMNSearch/clients ITE_DOC_SEARCH_INSTANCE=search DEFAULT_BROWSER=netscape DOCUMENT_SERVER_MACHINE_NAME=localhost DOCUMENT_SERVER_PORT=49213 CGI_DIRECTORY=/var/docsearch/cgi-bin DOCUMENT_DIRECTORY=/usr/docsearch/html root:/> root:/> Connection to nfsserver closed by remote host. Connection to nfsserver closed. #
Server:
root:/.ssh> sshd -d debug1: sshd version OpenSSH_3.6.1p2-pwexp22 debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug1: read PEM private key done: type DSA debug1: private host key: #1 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug1: Server will not fork when running in debugging mode. Connection from 172.16.1.3 port 37737 Did not receive identification string from 172.16.1.3 debug1: Calling cleanup 0x20016cec(0x0) root:/.ssh>
Client:
# ssh root@nfsserver Protocol major versions differ: 1 vs. 2
In der Standard-Einstellung kann die Version 2 auf der Server-Seite mit RSA Tickets leben. Das ist im ersten Beispiel passiert, der Daemon registriert Fehler, geht aber sein Programm durch.
Das sind die Files, die jetzt auf der Maschine existieren:
# ls /etc/open* /etc/openssh: ssh_config ssh_host_key ssh_prng_cmds ssh_host_dsa_key ssh_host_key.pub sshd_config ssh_host_dsa_key.pub ssh_known_hosts
Konfigurationsfile des Client.
# Host * # ForwardAgent yes # ForwardX11 yes # RhostsAuthentication yes # RhostsRSAAuthentication yes # RSAAuthentication yes # PasswordAuthentication yes # FallBackToRsh no # UseRsh no # BatchMode no # CheckHostIP yes # StrictHostKeyChecking no # IdentityFile ~/.ssh/identity # Port 22 # Protocol 2,1 # Cipher blowfish # EscapeChar ~
Das Konfigurations-File des Servers:
Port 22 # Legt den Port fest, auf dem der sshd lauscht. # Das kann man für zusätzliche "Sicherheit" ändern. #Protocol 2,1 # Legt das Protokoll fest, mit dem der sshd arbeiten # soll. Hier werden beide Protokolle bedient. ListenAddress 0.0.0.0 # Adressen, auf denen der sshd lauschen soll. # Mehrere Adressen werden mit : getrennt: #ListenAddress :: HostKey /etc/openssh/ssh_host_key # Wo liegt der Host-Key? ServerKeyBits 768 # Wieviele Bits hat er? LoginGraceTime 600 KeyRegenerationInterval 3600 PermitRootLogin yes # Soll sich ein Root-User per ssh auf dieser Maschine # einloggen dürfen? IgnoreRhosts yes # Sollen die .rhosts beachtet werden? # Das sollte man natürlich ausschalten.... #IgnoreUserKnownHosts yes # Sollen User per ~/.ssh/known_hosts (zusammen mit # RhostsRSAAuthentication) bestimmen können, wer # auf die Maschine kann? StrictModes yes # Im Strict Mode ist kein automatischer Key-Austausch # möglich. Die Keys werden vom Adminsitrator verteilt # bzw. dem User zur Verfügung gestellt. X11Forwarding no X11DisplayOffset 10 # Weiterleitung von X-Sessions und Parametern dazu. PrintMotd yes KeepAlive yes # Ausgabe des Moto des Tages beim Login, Keepalive # auf die Verbindung (TCP Keepalive). SyslogFacility AUTH LogLevel INFO # Man kann die Logging Facility festlegen (alle LOCALx, # DAEMON, USER, AUTH). # Man kann den Logging Level festlegen. # Das ist ein wenig anders als beim syslog: # QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG. # DEBUG zeigt Daten und Passwörter, also wirklich nur zum # debuggen geeignet. RhostsAuthentication no RhostsRSAAuthentication yes # Steuert, ob sshd die .rhosts auswerten soll, und ob # bei dieser Auswertung die RSA-Keys berücksichtigt # werden sollen (also einmal simples r-Kommando via ssh, # im anderen Fall mit Prüfung der Keys. # Nötig ist die /etc/openssh/ssh_known_hosts. # RSAAuthentication yes # Erlaubt Benutzung von RSA Keys. PasswordAuthentication yes # Sollen Passwörter verschlüsselt über ssh ausgetauscht werden? PermitEmptyPasswords no # Soll ein einfaches ENTER als Passwort reichen? #SkeyAuthentication no #KbdInteractiveAuthentication yes # To change Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #AFSTokenPassing no #KerberosTicketCleanup no # Kerberos TGT Passing does only work with the AFS kaserver #KerberosTgtPassing yes CheckMail no #UseLogin no # S/Key, Kerberos und Mail Schalter #Subsystem sftp /usr/local/libexec/sftp-server #MaxStartups 10:30:60 # Soll das scp-Kommando zur Verfügung stehen? # Es ist möglich, die Benutzung einzuschränken.
Früher gab es die SSH-Filesets von der Bull-Seite, wo man noch viel selbst machen mußte. Die Beschreibung bleibt hier stehen, da die wichtigen Schritte immer noch ausgeführt werden, jedoch über ein Skript bei der Installation. Es schadet aber nicht, wenn man weiß, wie es geht.
Für die ersten Versionen gilt folgendes (bis 2.5.3.0, glaube ich):
Die Installationsroutine findet sich im File rc.openssh. Es ist ein Skript, das die erste Initialisierung, den Start nach einem Systemboot sowie die Deinstallation erlaubt. Dieses Skript und ein verwandetes Skript mkopenssh.sh werden bei der Installation automatisch ausgeführt.
Während der Initialisierung wird zuerst eine Zeile für den TCP Port 22 in die /etc/service eingefügt ( ). Die nötigen Konfigurationsfiles werden aus /usr/lpp/freeware-openssh in das angegebene Direktory (Standard ist /etc/openssh) kopiert. Die Host-Schlüssel werden erzeugt und abgelegt, sowie die entsprechenden Files angelegt. Darauf werden die Files shost.equiv, hosts.equiv, .shosts, .rhost dem User root und der Gruppe root zugeteilt sowie das Schreibrecht für group und others gelöscht. Anschließend wird die Startzeile in die /etc/inittab eingefügt ( rcossh:2:once:/etc/rc.openssh >/dev/console 2>&1). Nach diesem Schritt wird das Skript mkopenssh.sh aufgerufen.
Das Skript mkopenssh.sh erzeugt die nötigen Links zu den Executables, linkt also die bekannten Kommandos (ssh, slogin, scp ...) zu den ausführbaren Dateien (/usr/local/bin/openssh, openscp ...). Zusätzlich werden die Man-Pages entsprechend verlinkt.
Bei den späteren Versionen muß man die Schritte selbst machen - hier als Beispiel mit openssh.rte 2.9.2.0 und openssl.rte 0.9.6.0:
Installation -klar, wie oben...
In der /etc/inittab folgende Zeile einfügen:
ssh:2:once:/usr/local/bin/sshd > /dev/concole 2>&1
(Fährt man im Run-Level 2 hoch, wird der sshd einmal gestartet...)
In der /etc/services wird folgende Zeile eingefügt:
ssh 22/tcp
(So kann uns niemand den Port wegschnappen...)
Die PATH-Variable muß systemweit erweitert werden - und es
sollte ein Pfad auf die neuinstallierten Man-Pages gesetzt werden:
In der /etc/environment folgende Zeilen modifizieren bzw. erweitern:
PATH= .....:/usr/local/bin:...
MANPATH=/usr/share/man:/usr/local/man:/usr/dt/man
Jetzt kann man den sshd mit Default-Werten starten:
/usr/local/bin/sshd
und sich freuen (hoffentlich). Wenn irgendwelche Meldung kommen,
daß Libraries (libcrypto.a) nicht gefunden werden kann, dann
hat man eine falsche Kombination openssh/openssl installiert ...
bingo.
[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | RPi | SMTP | Tracing | GPS | LW ]
Copyright 2001-2021 by Orm Hager - Es gilt die GPL