FreeBSD 4.11 im Jahre 2017: Des Trampels tölpelhafte Totenbeschwörung
Gut, damit ist alles aufgestellt. Wir könnten jetzt neu starten - oder einfach den alten SSH-Dienst abschießen und den neuen starten. Dazu müssen wir zuerst nach dem SSHd suchen und herausfinden, welche PID er hat (was sich natürlich von System zu System unterscheiden wird):
# ps aux | grep sshd
PID gefunden? Super, also immer weg damit (die aktuelle SSH-Verbindung wird von einem Kindprozess gehalten, sodass es normalerweise sicher ist, den Elternprozess abzuschießen. Dadurch büßt man nicht seine SSH-Verbindung ein). Jetzt noch die neue Instanz gestartet und nachgesehen, ob sie läuft:
# kill [PID auf Ihrem System] # /usr/local/temp/sbin/sshd # ps aux | grep sshd
Was ist los? Sieht aus, als ob der neue SSHd nicht liefe! Ja, es sieht so aus, aber eigentlich sollte er laufen... Greppen wir nochmal:
# ps aux | grep local
Dieser Aufruf spuckt ein Ergebnis aus - und vertrauen Sie mir, das ist tatsächlich unser neuer SSHd. Was hier geschieht ist dies: Die Ausgabe von ps wird abgeschnitten, da mehr nicht auf den Bildschirm passt. Und nur dieser sichtbare Teil wird an Grep durchgereicht! Der Prozess mit dem Namen /usr/local/temp, den wir gefunden haben (siehe Screenshot) ist in Wirklichkeit /usr/local/temp/sbin/sshd, bei dem nur das letzte Stück abgeschnitten ist... Aus diesem einfachen Grund konnte Grep kein "sshd" finden. Es gibt eine lustige Möglichkeit, dieses Problem zu umgehen: Maximieren Sie Ihren Terminal-Emulator, so dass mehr Platz verfügbar ist. Dann findet Grep auch den sshd!
Jetzt können wir die alte SSH-Sitzung beenden, um anschließend eine Verbindung zum neuen SSH-Server aufzubauen. Dabei können wir unsere Screen-Sitzung offenlassen, müssen dazu aber vorher die Verbindung zu dieser trennen, indem wir zuerst STRG-A und dann D drücken. Anschließend loggen wir uns auf vierelf aus:
[detached] # logout > exit Connection to 192.168.1.5 closed.
Jetzt muss auf der Arbeitsstation die known_hosts-Datei editiert werden, um die vorige Host-ID für vierelf zu löschen, da sonst beim neuen Verbindungsversuch die berüchtigte SSH-Warnung auftaucht und die Verbindung verweigert wird. Oh, und übrigens kann diese Kompatibilitätsoption für ssh-dss ab jetzt weggelassen werden - was schonmal ein großer Fortschritt ist! Wieder eingeloggt können wir die Screen-Sitzung wiederaufnehmen:
% ssh kraileth@192.168.1.5 > su - # screen -r