MediaMill Blog

Kategorie: SSH

  • SSH Host Key aus der Datei known_hosts entfernen

    Wenn eine SSH-Verbindung zu einem Server aufgebaut werden soll und der Host Key des Zielservers nicht mit dem Host Key für diesen Server in der lokalen Datei known_hosts übereinstimmt, wird aus Sicherheitsgründen keine Verbindung aufgebaut, da die Identität des Zielservers nicht eindeutig sichergestellt ist.

    Beispielhafte Fehlermeldung:

    @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@       WARNING: POSSIBLE DNS SPOOFING DETECTED!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
The RSA host key for server.server.test has changed,
and the key for the corresponding IP address 88.188.188.88
is unchanged. This could either mean that
DNS SPOOFING is happening or the IP address for the host
and its host key have changed at the same time.
Offending key for IP in /root/.ssh/known_hosts:13
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
88:88:88:01:7f:f9:19:73:53:79:dd:a5:ac:88:88:88.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending RSA key in /root/.ssh/known_hosts:12
RSA host key for server.server.test has changed and you have requested strict checking.
Host key verification failed.

    Wenn man die Gründe kennt, warum der Host Key des entfernten Servers nicht mit dem lokal gespeicherten Host Key übereinstimmt, dann kann man den lokalen Host Key aus der Datei known_hosts entfernen.

    Bei älteren Linux-Systemen konnte man einfach den Key manuell aus der Datei known_hosts entfernen, da der Servername in Klartext den Key identifizierte. Da bei neueren Systemen aus Sicherheitsgründen der Servername verschlüsselt ist, geht ein manuelles Löschen des Host Key nicht mehr. Man muss nun den Host Key mit dem Programm ssh-keygen und dem Parameter -R und dem Servernamen für den Server, dessen Host Key entfernt werden soll, aus der Datei known_hosts entfernen.

    Beispiel:

    ssh-keygen -R server.server.test

    Nach dem Entfernen des Host Key aus der Datei known_hosts wird man bei einem erneuten SSH-Verbindungsaufbau gefragt, ob man dem Zielserver vertraut. Wenn diese Frage mit „ja“ beantwortet wird, dann wird der aktuelle Host Key des Remoteservers der Datei known_hosts hinzugefügt.

    Beispiel:

    The authenticity of host 'server.server.test (88.188.141.88)' can't be established.
RSA key fingerprint is 88:88:88:01:7f:f9:19:73:53:79:dd:a5:ac:88:88:88.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'server.server.test' (RSA) to the list of known hosts.

    Zukünftige SSH-Verbindungen zu dem Zielserver sollten dann ohne Sicherheitsabfrage funktionieren.

    Quelle: http://www.linuxforme.de

  • SSH Port Forwarding – SSH-Port-Weiterleitung – SSH-Tunnel durch eine Firewall – RDP-Tunnel über SSH-Port

    Aufgabenstellung: Man betreibt in seinem Heimnetzwerk einen Linux-Server und mehrere Windows-Rechner. Vom Internet aus möchte man nun auf seine Windows-Rechner per RDP (Remote Desktop Protocol Port 3389) zugreifen. Aus Sicherheitsgründen ist aus dem Internet aber kein direkter Zugriff auf den RDP Port 3389 im Heimnetzwerk möglich. Allein der Zugriff auf den Linux-Rechner per SSH ist per Port-Weiterleitung im Router des Heimnetzwerks aktiviert.

    Lösung: Tunneln der RDP-Verbindung durch das SSH-Protokoll.

    a) Nativ von einer Linux / Mac OSX Shell:

    ssh -LYYYY:NAME_DES_WINDOWS_RECHNERS:3389 BENUTZERNAME@IP_DES_ROUTERS -p XXX
# -LYYYY = Lokaler Port über den die RDP-Vebindung geöffnet wird.
# NAME_DES_WINDOWS_RECHNERS: Name oder IP des Windows Rechners, auf den per RDP zugegriffen werden soll, im lokalen Netz
# -p XXX = Port der vom Router fürs Internet freigegeben wurde und an den SSH Port des Linux Rechner weiter geleitet wird.
# IP_DES_ROUTERS = Öffentliche IP Adresse oder DNS-Name unter der der Router im Internet zu erreichen ist. 
# z.B: 
ssh -L5000:192.168.1.234:3389 max@mustermann.dyndns.com -p 10000

    b) Mit dem SSH-Client Putty von einem Windows-System:

    Um mit Putty das RDP-Protokoll über eine SSH-Verbindung tunneln zu können, muss man in den Sessioneinstellungen, unter Connection –> SSH –>  Tunnels den lokalen Port, den zu tunnelnden Remote Port und den Zielrechner für den Tunnel definieren:

    putty_ssh_tunnel_01 putty_ssh_tunnel_02

    Um nun also vom Internet aus auf seinen Windows-Rechner per RDP (Remote Desktop Protocol Port 3389) zuzugreifen, muss man, nachdem die SSH-Verbindung geöffnet wurde, eine RDP-Verbindung zu localhost:5000 (Localhost Port 5000) öffnen.

    rdp_tunnel_ueber_ssh

  • RSYNC Fehlermeldung: protocol version mismatch — is your shell clean? (rsync error: protocol incompatibility (code 2) at compat.c(171) [receiver=3.0.4])

    Als ich ein Script testen wollte, das ein Verzeichnis mit rsync und ssh von Server1 auf Server2 spiegeln sollte, verweigerte rsync seinen Dienst mit folgender Fehlermeldung:

    protocol version mismatch — is your shell clean?
    rsync error: protocol incompatibility (code 2) at compat.c(171) [receiver=3.0.4]

    Eine Webrecherche brachte die Lösung des Problems. Eigentlich hätte man mit der Fehlermeldung „is your shell clean?“ selbst darauf kommen können.

    Auf dem Server, auf den ich mit rsync zugreifen wollte, befand sich ein Startskript .bashrc mit folgendem Eintrag:

    LOGINSTATION=`who | cut -d“(“ -f2 | cut -d“)“ -f1`
    echo Login von: $LOGINSTATION

    Dieses Skript produzierte bei einem Login eine Ausgabe wie diese:

    Login von: 11-66-100-10-dynip.superkabel.de

    Diese Meldung brachte nun RSYNC aus dem Tritt. Anscheinend setzt rsync eine Loginshell ohne zusätzliche Meldungen vorraus. Deshalb auch die Fehlermeldung: “is your shell clean?”

    Wenn die Meldung aus der .bashrc entfernt wird, funktionierte RSYNC wieder wie gewohnt.

  • SSH Login scheitert mit der Fehlermeldung „sshd[xxxx]: fatal: daemon() failed: No such device“

    Plötzlich war bei unserem OpenSuse 10.3 Rootserver kein SSH Login mehr möglich. Der Verbindungsaufbau wurde mit der Meldung „Connection Refused“ verweigert. Glücklicherweise hatte ich noch Zugriff auf die Konsole des Servers, wo ich mich auch lokal anmelden konnte. Eine Überprüfung mit

    rcsshd status

    zeigte, dass der SSH Daemon nicht lief. Auch ließ er sich mit

    rcsshd start

    nicht mehr starten. Ein Blick in /var/log/messages zeigte folgende Fehlermeldung: sshd[27256]: fatal: daemon() failed: No such device.
    Eine Internetrecherche brachte dann die Lösung des Problems. Anscheinend war die Datei /dev/null daran Schuld, dass sich der SSH Daemon nicht starten ließ. Mit folgenden Befehlen wurde die Datei /dev/null gelöscht und neu erstellt:

    rm -rf /dev/null
    mknod /dev/null c 1 3

    Danach funktionierte das Starten des SSH Daemons mit

    rcsshd start

    wieder.

    Gefunden habe ich die Lösung unter:

    http://forums.misdivision.com/showthread.php?t=633

  • Synchronisation von einem Verzeichnis auf einem Remoteserver mit einem Verzeichnis auf dem lokalen Server mittels rsync

    Rsync ist ein Programm zum Spiegeln von Verzeichnissen. Dabei kopiert Rsync die Daten inkrementell, d.h. es werden nur veränderte Daten übertragen.

    Der Befehl

    rsync -v -a –delete -e ssh user2@remoteserver.net:/home/user2/daten/ /home/user1/backup/

    gleicht das Verzeichnis /home/user2/daten/ auf dem entfernten Server mit dem Verzeichnis /home/user1/backup/ auf dem lokalen Server ab.

    Die Optionen bedeuten im einzelnen:

    -v = verbose – Erweiterte Ausgabe, nützlich bei der Fehlersuche
    -a = Kombiniert mehrere andere Optionen. Sorgt unter anderem dafür, dass Unterverzeichnisse rekursiv mitkopiert werden, symbolische Links kopiert werden, Benutzer- und Gruppenrechte sowie Zeiten erhalten bleiben.

    –delete sorgt dafür, dass Dateien auf dem Ziel, die auf der Quelle nicht mehr existieren, gelöscht werden (Mirroring). Vorsicht bei der Verwendung dieser Option.

    -e ssh sorgt dafür, dass die rsync Verbindung durch eine verschlüsselte SSH Verbindung getunnelt wird.

  • SSH Login ohne Passworteingabe mit SSH Key Authentication

    Mit dem Befehl

    ssh-keygen -t rsa

    wird ein Schlüsselpaar aus öffentlichem und privatem Schlüssel generiert. Die beiden Dateien mit den Schlüsseln werden im Ordner ~/.ssh erstellt.
    ~/.ssh/id_rsa Privater ServerKey
    ~/.ssh/id_rsa.pub Public Key

    Nun muss noch der eigene Public Key auf dem Remote Server installiert werden. Der Befehl

    ssh-copy-id -i ~/.ssh/id_rsa.pub user@remoteserver

    hängt den eigenen Public Key an die Datei ~/.ssh/authorized_keys des Remote Servers.

    Ob das Ganze erfolgreich war, kann man nun mit dem Befehl

    ssh user@remoteserver

    testen. Wenn bei der Schlüsselgenerierung keine Passphrase angegeben wurde, sollte die ssh-Verbindung nun automatisch aufgebaut werden. Dies ist unter anderem sehr nützlich, wenn eine SSH Verbindung per Script automatisch aufgebaut werden soll.

  • Darstellung von Umlauten und Linien bei einer SSH Verbindung mit Putty zu einer openSuse Installation.

    Problem: Nach dem Umstieg von Suse Linux 9.3 auf openSUSE Linux 10.1 traten bei einer SSH Verbindung mit Putty Fehler bei der Darstellung von Sonderzeichen und Linien auf. Ein Umstellen des Zeichensatzes auf UTF-8 in Yast und bei Putty behob dieses Problem nur zum Teil. Entweder wurden die Linien richtig dargestellt, aber die deutschen Umlaute nicht, oder es wurden die Umlaute korrekt angezeigt, aber die Linien nicht.

    Lösung: Ein Hinweis in der openSUSE-de Maillingliste, half das Problem zu beheben. Wichtig ist folgende Einstellung unter Putty: Unter CONNECTION -> DATA -> TERMINAL-TYPE STRING muss der Wert XTERM mit dem Wert „linux“ (Achtung: Diese Einstellung ist Case Sensitive. Das heißt „linux“ in Kleinbuchstaben schreiben) ersetzt werden. Weiterhin wurde bei Putty der Zeichensatz unter WINDOW -> TRANSLATION auf UTF-8 geändert. Nun werden alle Umlaute und Linien, bei einer SSH Verbindung mit Putty, wieder korrekt dargestellt.

    Fehlerhafte Umlautdarstellung bei Putty

    Fehlerhafte Umlautdarstellung

    Fehlerhafte Liniendarstellung bei Putty

    Fehlerhafte Liniendarstellung

    Korrekte Darstellung

    Korrekte Darstellung