orm@doc-tcpip.org

Erstellt: April 2000 - Letzte Modifikation: September 2003

[ Main | Local ]


Einrichten und Benutzen von SSH unter AIX


SSH - Basics

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 SSH (Secure Shell) Protokoll

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).

Die beiden SSH Versionen

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.

Die Komponenten von SSH

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.

Installation unter AIX

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

Was passiert bei der Installation?

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

Was passiert beim ersten Login?

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=

Benutzungsbeispiele

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:

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...

Ein praktisches Beispiel

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_seed
Neu 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
#

Debuggen der SSH

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.

Ausgabe des Server sshd

 
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> 

Ausgabe des Client 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.
# 

Ein beliebter Fehler: Server SSH-Version 2, Client SSH-Version 1

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.

Konfiguration unter AIX

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.

Die Installationsroutine der alten SSH von der Bull-Seite

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:


[ Main | Local ]

[ Allgemein | UNIX | AIX | TCP-IP | TCP | ROUTING | DNS | NTP | NFS | FreeBSD | Linux | SMTP | Tracing | GPS ]

Copyright 2001-2014 by Orm Hager - Es gilt die GPL
Feedback bitte an: Orm Hager (orm@doc-tcpip.org )