SSH auf den Servern des RZ

Startseite
Suche
Lageplan
Ansprechpartner
Informationen
Reservierungen
FAQ

Anmeldung
Kurse, Workshops
Netz und Technik
SSH
Einwahldienste
PC-Support
Campuslizenzen
Drucken
Graphik, Video, Multimedia
Datenbanken
Hochleistungsrechner
Software
Hardware
Systemdienst

FTP-Server
Links

Universität Kiel

mitterhuber@rz.uni-kiel.de

Secure Shell (SSH) auf den Servern des RZ

Gesicherte Kommunikation über unsichere Netze

Auf dieser Seite wird der praktische Umgang mit SSH auf den Servern des Rechenzentrums beschrieben. Einen sehr guten einführenden Überblick zum Thema SSH bekommt man auf der SSH-Seite von Holger Trapp.
SSH im Überblick

Mit SSH bzw. Secure Shell wird sowohl ein kryptographisches Protokoll als auch eine konkrete Implementierung dieses Protokolls bezeichnet. Ursprünglicher SSH-Protokoll-Designer und Software-Autor ist Tatu Ylönen aus Finnland, der die Secure Shell an der TU Helsinki entwickelte und später die Firma SSH Communications Security Ltd. gründete.

Bis zur Version 1.2.12 war Ylönens Software zu beliebigen Zwecken frei nutzbar, später wurden die Lizenzbedingungen restriktiver. Mit OpenSSH steht heute eine für beliebige Zwecke kostenfrei nutzbare, in C geschriebene SSH-Implementierungen für UNIX zur Verfügung, die ausgehend von Tatu Ylönens Quellen der SSH 1.2.12 entwickelt wurde bzw. wird

Zum Funktionsumfang von Ylönens Secure Shell gehören:

Login auf einer entfernten Maschine,
interaktive oder nichtinteraktive Ausführung von Kommandos auf der entfernten Maschine,
Kopieren von Dateien zwischen verschiedenen Rechnern eines Netzes.

SSH ermöglicht eine kryptographisch gesicherte Kommunikation über unsichere Netze und bietet ein hohes Sicherheitsniveau: zuverlässige gegenseitige Authentifizierung der Partner sowie Integrität und Vertraulichkeit der ausgetauschten Daten.

Sie ist als kompletter Ersatz der r-Utilities rlogin, rsh und rcp gedacht, wobei es einige wenige, für die meisten Nutzer absolut irrelevante Fälle gibt, in denen rsh nicht unmittelbar durch ssh ersetzt werden kann.
In den meisten Fällen deckt die Secure Shell nicht nur den Funktionsumfang der genannten r-Utilities, sondern auch den von Telnet und teilweise sogar von FTP ab.

Gegenwärtig existieren zwei unterschiedliche und inkompatible Versionen des SSH-Protokolls: SSH 1.x und SSH 2.x.
Das SSH-Protokoll 1.x ist nicht international standardisiert und mit einigen konzeptionellen Mängeln behaftet, die durch die Version 2.x behoben werden. Die Protokollversion 1.x ist gegen einen sog. Insertion Attack empfindlich. Zur Sicherung der Integrität der zwischen Server und Client ausgetauschten Pakete wird CRC-32, ein schwacher Algorithmus, genutzt. Für Angreifer besteht die Möglichkeit durch speziell konstruierte, mit einem korrekten CRC versehene Pakete, Daten seiner Wahl unbemerkt in den verschlüsselten SSH-Kanal einzuschleusen und so z.B. beliebige Kommandos auf dem Server auszuführen. Die Implementierung von OpenSSH ab Version 2.3 ermöglichen nach heutigem Kenntnisstand auch bei Verwendung des SSH-Protokolls 1.x eine zuverlässige Integritätssicherung. OpenSSH nutzt dazu geeignete Verfahren die gefälschte Pakete erkennen.

openSSH Installation auf den Servern des RZ

Auf den Servern des RZ ist das Programmpaket openSSH installiert. In dem Programmpaket sind die unten aufgelisteten Programme (Kommandos) enthalten. Nährere Erläuterungen zu den Funktionsweisen und Aufruf-Optionen der Programme bekommt man über die gleichlautenden Man-Pages.

Klienten:

ssh
slogin SSH-Klient, funktionaler Ersatz für rlogin, rsh und telnet
slogin ist ein alternativer Name für ssh.
In seinem eigenen Interesse sollte jeder Anwender an Stelle von Telnet nach Möglichkeit konsequent die SSH bzw. ein Werkzeug mit einem vergleichbaren kryptographischen Niveau einsetzen.

scp sftp kopiert Files gesichert zwischen zwei Maschinen unter Nutzung von SSH; ersetzt rcp und bezüglich des reinen Dateitransfers auch FTP

Server:

sshd SSH-Dämon

Administrationswerkzeuge:

ssh-keygen erzeugt RSA-Schlüssel

ssh-agent SSH-Agent, der private RSA-Keys verwalten, dadurch Challenges des Servers entschlüsseln und somit die Authentifizierung automatisieren und folglich vereinfachen kann

ssh-add registriert neue Schlüssel beim SSH-Agenten

ssh-keyscan erstellt eine Liste mit bekannten öffentlichen Host-Keys einer Domäne

Die Kommandos ssh und scp werden gesteuert über eine zentrale- bzw. über eine user-lokale Konfigurationsdatei:
/usr/local/etc/ssh_config *)

$HOME/.ssh/config

Der SSH-Dämon wird gesteuert über die Konfigurationsdatei:
/usr/local/etc/sshd_config *)

*) Die hier und im folgenden angegebenen Pfade gelten für die Unix-Rechner des Rechenzentrums (ausnahme Linux). Auf anderen Rechnern können die Dateien in anderen Verzeichnissen stehen.

Änderungen an den zentralen Konfigurationsdateien
Folgende Parameter wurden in den zentralen Konfigurationsdateien gegenüber den Standardeinstellungen auf den Rechnern des RZ geändert:
/usr/local/etc/ssh_config

Protocol 1 Die Standardeinstellung ist Protocol 2,1.

Mit dieser Einstellung haben wir die ältere nicht so sichere Protokollversion gewählt - warum?

Erstens: Die Wahl der Protokollversion 1 erlaubt eine RhostsRSAAuthentication mit dem Server. Dadurch ist es auch unerfahrenen Benutzern möglich, sofort SSH zu nutzen. Es müssen nicht erst eigene Keys erzeugt und verteilt werden. Statt über persöhnlich Keys erfolgt die Authentifikation über die Host-Keys, die vom Systemverwalter zur Verfügung gestellt werden.

Zweitens: Die Implementierung der Protokollversion 1.x gilt bei openSSH als sicher, so dass aus Sicherheitsgründen nicht unbedingt der Zwang zur Nutzung der Protokollversion 2.x besteht.

Die Voreinstellungen in der zentralen Konfigurationsdatei können in eine User-lokale Konfigurationsdatei unter $HOME/.ssh/config kopiert und dort verändert werden. Auch über die Kommandozeile können die Voreinstellungen aus den Konfigurationsdateien mit der -o Option verändert werden. Die Reihenfolge der Auswertung ist: Kommandozeile - lokale Konfigurationsdatei - zentrale Konfigurationsdatei. Beispiel für die Übergabe von Konfigurationsparametern in der Kommandozeile:

ssh -o Protocol=2,1 -o Cipher=blowfish <rechnername>

Es wird eine Verbindung zum Rechner <rechnername> aufgebaut. Wenn der Server die Protokollversion 2 unterstützt, wird diese für die Kommunikation genutzt, anderenfalls die Protokollversion 1. Die Session wird mit dem symmetrischen Verschlüsselungsverfahren blowfish statt 3des verschlüsselt (3des - triple-des - ist das Standardmässige Verschlüsselungverfahen. blowfish ist schneller und genauso sicher).

/usr/local/etc/sshd_config

IgnoreRhosts no Die Standardeinstellung ist IgnoreRhosts yes.

Eine RhostsRSAAuthentication soll erlaubt werden. Dazu müssen die User-lokalen Dateien $HOME/.rhosts bzw. $HOME/.shosts gelesen werden.

IgnoreUserKnownHosts no Die Standardeinstellung ist IgnoreUserKnownHosts yes.

Die User-lokale know_hosts Datei mit den öffentlichen Schlüsseln anderer Rechner wird neben der zentralen Schlüsseldatei durchsucht.

RhostsRSAAuthentication yes Die Standardeinstellung ist RhostsRSAAuthentication no.

Eine RhostsRSAAuthentication wird erlaubt. Das erleichtert unerfahrenen Benutzern den Umgang mit SSH.

RootLogin no Die Standardeinstellung ist RootLogin yes

Ein direktes Login als root über SSH wird nicht erlaubt.

PrintMotd no Die Standardeinstellung ist PrintMotd yes

Die Message of the day Meldungen sollen beim Verbindungsaufbau nicht ausgegeben werden.

PermitEmptyPasswords no Die Standardeinstellung ist PermitEmptyPasswords yes

X11Forwarding yes Die Standardeinstellung ist X11Forwarding no

SSH unterstützt den Schutz von X11-Verbindungen über einen kryptographisch gesicherten Kanal. SSH setzt dazu die DISPLAY- Variable und X11-Cookies auf geeignete Werte. Der SSH-Dämon erscheint X11-Applikationen als lokaler X11-Server. Der SSH-Dämon leitet die X11-Anforderungen über den gesicherten Kanal weiter zum tatsächlichen X11-Server.

Prinzipielle Abläufe beim Login
Im folgenden wird der prinzipielle Ablauf beim Login auf einen Server gemäss SSH-Protokoll 1.x und der Rhosts-RSA-Authentifizierung erläutert:

Der Klient baut eine TCP-Verbindung zum Server auf (Default-Port: 22).

Beide Partner tauschen die jeweils verwendete Protokoll-Version aus. Falls die Versionen inkompatibel sind, wird die Kommunikation abgebrochen.

Der Server sendet seine beiden öffentlichen RSA-Schlüssel e_H und e_S (Host- und Server-Key) sowie eine Auflistung der von ihm unterstützten symmetrischen Chiffren zum Klienten.

Bei dem Host-Key handelt es sich um einen permanenten Key, der in der Datei /usr/local/etc/ssh_host_key.pub abgespeichert ist. Der Server-Key wird beim Starten des SSH-Dämons erzeugt. Dieser Key ist nur temporär im Hauptspeicher vorhanden und wird jede Stunde neu berechnet.

Der Klient verifiziert e_H über eine lokale Datenbasis (bzw. "lernt" diesen Key, falls es der Nutzer zuläßt).

Als lokale Datenbasis dienen die Dateien

/usr/local/etc/ssh_known_hosts
$HOME/.ssh/known_hosts.

Hier stehen die öffentlichen Schlüssel der Rechner. Die Schlüssel müssen über einen vertrauenswürdigen sicheren Weg in diese Dateien geschrieben worden sein. Zunächst durchsucht der Klient die user-lokale Datei $HOME/.ssh/known_hosts nach einem passenden öffentlichen Schlüssel. Wird dort keiner gefunden, wird die zentrale Datei /usr/local/etc/ssh_known_hosts nach einem passenden Schlüssel durchsucht. Diese Datei wird vom Systemadministrator gepflegt. Wenn auch in dieser Datei der gesuchte Schlüssel nicht vorhanden ist, wird er vom SSH-Klienten, je nach eingestellter Option StrictHostKeyChecking, in die lokale known_hosts Datei eingetragen oder die Session wird beendet (siehe dazu die Beispiele weiter unten). Folgende Angaben zur Option StrictHostKeyChecking sind möglich:

yes Die Session wird beendet, wenn kein passender Eintrag gefunden wurde.
no Der öffentliche RSA-Schlüssel wird in die user-lokale Datei ohne besondere Hinweise eingetragen. Da die Übertragung des RSA-Schlüssel unverschlüsselt läuft, kann er dabei manipuliert werden. Hier besteht also eine Sicherheitslücke.
ask Der öffentliche RSA-Schlüssel wird nach Rückfrage eingetragen. Hier besteht die gleiche Sicherheitslücke wie unter no beschrieben. Durch den Rückfragemechanismus kann man aber bewusst entscheiden, ob man das Risiko akzeptieren will oder nicht.

Wurde e_H akzeptiert, so generiert der Client einen zufälligen Sitzungsschlüssel, chiffriert diesen mittels der beiden RSA-Keys e_H und e_S und sendet das Resultat zusammen mit der Angabe, welches der angebotenen symmetrischen Verfahren er gewählt hat, an den Server.
Ab jetzt läuft die gesamte Kommunikation verschlüsselt ab.

Der Klient authentifiziert sich mit einem der jeweils unterstützen Verfahren (siehe unten). Welche benutzt werden sollen, wird durch Einstellungen in den Client-Konfigurationsdateien bestimmt. Wenn die hier betrachtete Rhosts-RSA-Authentifikation durchgeführt wird, schickt der Client dem Server seinen öffentlichen Schlüssel. Der Server versucht nun den Client über seine lokale Datenbasis (/usr/local/etc/ssh_known_hosts bzw. $HOME/.ssh/known_hosts zu verifizieren. Wenn ein bevorzugtes Authentifikationverfahren fehlerhaft verläuft, wird das nächststärkere Verfahren versucht. Beispielsweise wird nach einer erfolglosen Rhosts-RSA-Authentifikation die Passwort-Authentifikation versucht.

Nach erfolgreicher Authentifizierung wird für den Nutzer eine Arbeitsumgebung auf dem Server-Rechner hergestellt. Dazu gehört z.B. das Setzen von Umgebungsvariablen (u.a. TERM und DISPLAY) sowie die Umleitung von X11- und ggf. auch beliebigen TCP-Verbindungen.

Der Austausch der Nutzerdaten beginnt.

Verfahren zur Authentifizierung des Klienten
Die Secure Shell unterstützt in der Grundversion die vier nachfolgend genannten Verfahren zur Authentifizierung des Klienten, wobei die Nutzung der einzelnen Verfahren durch Kommandozeilen-Optionen bzw. Einträge in den Konfigurationsdateien gezielt zugelassen bzw. unterdrückt werden kann. Die in einer konkreten Konstellation verfügbaren Verfahren werden nacheinander bis zum ersten Erfolg oder bis zum definitiven Mißerfolg versucht:

Rhosts-Authentifizierung
Dieses Verfahren entspricht der Authentifizierung bei rlogin und rsh. Es basiert auf den Einträgen in den Dateien /etc/hosts.equiv oder /etc/shosts.equiv bzw. $HOME/.rhosts oder $HOME/.shosts.
Warnung: Diese Methode ist absolut unsicher und wird daher sinnvollerweise vom Server in der Regel nicht unterstützt!!

Rhosts-RSA-Authentifizierung
Hierbei handelt es sich um eine Kombination der Rhosts-Authentifizierung (Verfahren 1) mit einer RSA-basierten Authentifizierung des Klienten-Rechners. Die bekannten öffentlichen Schlüssel der Klienten werden beim Server in den Dateien $HOME/.ssh/known_hosts und /usr/local/etc/ssh_known_hosts gespeichert. Der Klient muß in einem Challenge-Response-Dialog nachweisen, daßer den zugehörigen privaten Schlüssel kennt.
Der private Schlüssel eines Hosts (Rechners) wird im File /usr/local/etc/ssh_host_key gespeichert. Dieses File darf nur für den Superuser root lesbar sein!

reine RSA-Authentifizierung
Sie stellt die flexibelste und potentiell sicherste Methode dar. Hierbei weist der Nutzer die Kenntnis seines privaten Schlüssels und damit seiner Identitätüber ein Challenge-Response-Verfahren nach, das sich unter Verwendung des SSH-Agenten automatisch abwickeln läßt.
Die zur Authentifizierung nutzbaren öffentlichen Schlüssel stehen auf dem Server im File $HOME/.ssh/authorized_keys. Das Schlüsselpaar des Nutzers wird beim Klienten in einer Datei, standardmäßig in $HOME/.ssh/identity, gespeichert.

Paßwort-Authentifizierung
Die Authentifizierung erfolgt durch Angabe eines Nutzerpaßworts, wobei dieses immer verschlüsselt übertragen wird.

Beispiele

ssh <rechnername>

Interaktiver Zugang zu einem anderen Rechner unter dem gleichen Account.

ssh -v <account>@<rechnername>

Interaktiver Zugang zu einem anderen Rechner unter einem anderen Account. Durch die -v Option werden die wichtigsten Ereignisse beim Verbindungsaufbau als Protokoll auf die Standardausgabe ausgegeben. Diese Option ist sehr hilfreich bei der Fehleranalyse.

ssh <rechnername> <kommando>

Das angegebene Kommando oder Programm wird ausgeführt. Anschliessend wird die Verbindung beendet.

scp -r <verzeichnis-lokal> <account>@<rechnername>:<verzeichnis-remote>

Ein ganzer Verzeichnisbaum wird vom lokalen Rechner auf den Remote-Rechner unter dem angegebenen Account in das angegebene Verzeichnis kopiert.

scp -r <account>@<rechnername>:<verzeichnis-remote> <verzeichnis-lokal>

Das Gleiche wie oben, nur in die andere Richtung.

Im folgenden wird ein SSH-Dialog mit einer fehlerhaft verlaufenden Rhosts-RSA-Authentifikation gezeigt. Häufigste Fehlerursache sind nicht gültige Public-Key-Einträge in den Dateien /usr/local/etc/ssh_known_hosts bzw. in $HOME/.ssh/known_hosts sowohl auf der Client- als auch auf der Server-Seite.
1. Fall: Fehlerhafte known_hosts Einträge auf der Server-Seite.
ssh -v service
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /home/szrzs080/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /swlinks/openssh-3.0.2p1/etc/ssh_config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 40185 geteuid 0 anon 1
debug1: Connecting to service [134.245.10.21] port 22.
debug1: temporarily_use_uid: 40185/401 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 40185/401 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/szrzs080/.ssh/identity type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.0.2p1
debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH
debug1: Local version string SSH-1.5-OpenSSH_3.0.2p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
debug1: Host 'service' is known and matches the RSA1 host key.
debug1: Found key in /swlinks/openssh-3.0.2p1/etc/ssh_known_hosts:60
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying rhosts or /etc/hosts.equiv with RSA host authentication.
debug1: Remote: Accepted by .rhosts.
debug1: Remote: Your host key cannot be verified: unknown or invalid host key.
debug1: Server refused our rhosts authentication or host key.
debug1: Doing challenge response authentication.
debug1: No challenge.
debug1: Doing password authentication.
szrzs080@service's password:

Der Grün markierte Bereich zeigt die Ausgaben von SSH während der Server-Authentifizierung auf der Client-Seite. Die Authentifizierung verläuft erfolgreich. Der öffentlich Key des Servers ist in der Datenbasis des Clients enthalten und zwar in /usr/local/etc/ssh_known_hosts.
Der Rot markierte Bereich zeigt die Ausgaben von SSH während der Client-Authentifizierung auf der Server-Seite. Die Authentifizierung verläuft fehlerhaft. Der öffentlich Key des Clients ist nicht in der Datenbasis des Servers enthalten, weder in /usr/local/etc/ssh_known_hosts noch in $HOME/.ssh/known_hosts. Eine Rhosts-RSA-Authentifizierung kann also nicht durchgeführt werden. Als nächstes wird daher die Passwort-Authentifizierung versucht.
2. Fall: Fehlerhafte known_hosts Einträge auf der Client-Seite.
ssh -v service
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /home/szrzs080/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /swlinks/openssh-3.0.2p1/etc/ssh_config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 40185 geteuid 0 anon 1
debug1: Connecting to service [134.245.10.21] port 22.
debug1: temporarily_use_uid: 40185/401 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 40185/401 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/szrzs080/.ssh/identity type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.0.2p1
debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH
debug1: Local version string SSH-1.5-OpenSSH_3.0.2p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
Warning: Permanently added 'service,134.245.10.21' (RSA1) to the list of known hosts.
debug1: Encryption type: 3des
debug1: Sent encrypted session key.
debug1: Installing crc compensation attack detector.
debug1: Received encrypted confirmation.
debug1: Trying rhosts or /etc/hosts.equiv with RSA host authentication.
debug1: Remote: Accepted by .rhosts.
debug1: Received RSA challenge for host key from server.
debug1: Sending response to host key RSA challenge.
debug1: Remote: Rhosts with RSA host authentication accepted.
debug1: Rhosts or /etc/hosts.equiv with RSA host authentication accepted by server.
debug1: Requesting pty.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting shell.
debug1: Entering interactive session.
Last login: Thu Feb 21 10:20:49 2002 from sysadm.rz.uni-k
Sun Microsystems Inc. SunOS 5.7 Generic October 1998
******* Rechenzentrum der Christian-Albrechts-Universitaet zu Kiel ********
* *
* U n e r l a u b t e r Z u g a n g / Z u g r i f f v e r b o t e n ! *
* *
* U n a u t h o r i z e d a c c e s s p r o h i b i t e d ! *
* *
* Computer: Sun SPARCstation-10, named service. OS: Solaris 2.7 *
* *
***********************************************
You have mail.
X-application possible
DISPLAY=service:10.0

Der Rot markierte Bereich zeigt die Ausgaben von SSH während der Server-Authentifizierung auf der Client-Seite. Der öffentliche Key des Servers wird in der lokalen Datenbasis des Clients nicht gefunden. Da in der Client-Konfigurationsdatei die Option StrictHostKeyChecking=no gesetzt ist, wird der Public-Key des Servers in die lokale $HOME/.ssh/known_hosts Datei übernommen. Die Rhosts-RSA-Authentifizierung wird fortgesetzt und verläuft schliesslich erfolgreich.
3. Fall: Fehlerhafte known_hosts Einträge auf der Client-Seite mit der Option StrictHostKeyChecking=yes.
ssh -v service -oStrictHostKeyChecking=yes
OpenSSH_3.0.2p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f
debug1: Reading configuration data /home/szrzs080/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /swlinks/openssh-3.0.2p1/etc/ssh_config
debug1: Seeding random number generator
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: restore_uid
debug1: ssh_connect: getuid 40185 geteuid 0 anon 1
debug1: Connecting to service [134.245.10.21] port 22.
debug1: temporarily_use_uid: 40185/401 (e=0)
debug1: restore_uid
debug1: temporarily_use_uid: 40185/401 (e=0)
debug1: restore_uid
debug1: Connection established.
debug1: read PEM private key done: type DSA
debug1: read PEM private key done: type RSA
debug1: identity file /home/szrzs080/.ssh/identity type -1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.0.2p1
debug1: match: OpenSSH_3.0.2p1 pat ^OpenSSH
debug1: Local version string SSH-1.5-OpenSSH_3.0.2p1
debug1: Waiting for server public key.
debug1: Received server public key (768 bits) and host key (1024 bits).
No RSA1 host key is known for service and you have requested strict checking.
Host key verification failed.
debug1: Calling cleanup 0x4e380(0x0)

Der öffentlich Key des Servers ist nicht in der Datenbasis des Clients enthalten, weder in /usr/local/etc/ssh_known_hosts noch in $HOME/.ssh/known_hosts. Aufgrund der Client-Konfigurations-Option StrictHostKeyChecking=yes wird der öffentliche Key des Servers nicht erlernt und in $HOME/.ssh/known_hosts abgespeichert. Die Sitzung ist damit beendet.

12.3.2002