SSH - REMOTE HOST IDENTIFICATION HAS CHANGED

Jedes Mal, wenn ich mir ein neues Linux-System einrichte, muss ich erst nochmal schnell Googlen oder die Manpage wälzen; daher notiere ich es mir hier jetzt endlich mal:

Es gibt ein Sicherheitsfeature bei openSSH, welches einen warnt wenn man sich zu einem Host/einer IP verbinden möchte und sich die ID des Zieles seit dem letzten Mal verändert hat. Das macht zwar durchaus Sinn und ich finde das generell eine gute Sache. Aber es kann wirklich sehr nerven, besonders wenn man mit DHCP arbeitet und die Zielrechner dauernd Ihre IP durchtauschen, man mit virtuellen Maschinen arbeitet und diese nur kurz benutzt werden oder häufig per SSH auf Live-CD-Systeme konnektiert.

Normalerweise muss man die entsprechende Zeile in der Datei ~/.ssh/known_hosts die angemeckerte Zeile löschen; z.B. bei:

$ ssh user@192.168.1.12
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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 the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
39:b3:72:04:53:f7:17:eb:aa:8c:ed:70:db:77:8b:e9.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:3
RSA host key for 192.168.1.12 has changed and you have requested strict checking.
Host key verification failed.$

müsste man die Zeile 3 entfernen.

Hierzu muss man etwas wie

sed -i 3d ~/.ssh/known_hosts

losjagen oder die Datei in einem Editor von Hand bereinigen. Wie schon gesagt: Auf Dauer sehr nervig!

Wenn einem das nur vereinzelt passiert, kann man sich mit Kommandozeilenoptionen helfen:

ssh -o UserKnownHostsFile=/dev/null \
-o StrictHostKeyChecking=no user@192.168.1.12

ist jedoch schon eine recht sportliche Aufgabe sich das a) zu merken und b) jedes Mal wegzutippen.

Wem das permanent passiert, kann dieses Verhalten dauerhaft einstellen. Und zwar sowohl global wie auch userbasiert. In beiden Fällen müssen die beiden o.g. Optionen in die passende Config-Datei eingetragen werden:

UserKnownHostsFile=/dev/null  
StrictHostKeyChecking=no

Um diese Einstellung global zu setzen (nicht empfohlen), trägt man diese Optionen in die Datei "/etc/ssh/ssh_config" ein.

Um diese Einstellung nur für einen bestimmten User zu setzen, trägt man diese Optionen in die Datei "~/.ssh/config" ein.

Das ganze hebelt natürlich den als Sicherheitsmaßnahme gegen "Man-in-the-middle" - Attacken gemeinten Schutz vor diesem Angriffstyp aus. Um das ganze wenigstens etwas sicherer zu machen, kann man auch nur einzelne Hosts und Hostbereiche derart von dieser Regel ausnehmen. Die Beispielhafte Syntax dazu lautet dann:

Host 192.168.1.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Möchte man dieses immer und für alle Verbindungen deaktivieren, lässt man die "Host" - Zeile einfach weg.

Aber Achtung: Bitte nur anwenden wenn Ihr wisst was Ihr tut! Das ganze hebelt, wie gesagt, einen sinnvollen Schutz des SSH Systems aus.

Teilen per: TwitterEmail


Modding der Fritzbox - Teil 3

So, heute möchte ich gerne einen SSH Server auf die Fritzbox bringen, da mich der Telnetzugang dann doch ziemlich nervt.

Es wird, wie immer, die Variante gewählt, den Server beim booten der Box aus dem Web nachzuladen.

Ich richte mich hierbei weitestgehend nach diesem Tutorial.

Es wird also der Dropbear SSH Server verwendet. Diesen habe ich hier fertig kompiliert abgelegt.

Ich erweitere das Script /var/flash/debug.cfg aus Teil 2 der Reihe um ein paar Zeilen. Ausserdem ändere ich die Form ein wenig:

#!/bin/sh
APPDIR="/var/tmp/runtimeapps"
mkdir \$APPDIR
echo "ww:x:0:0:root:/:/bin/sh" >> /var/tmp/passwd
echo "ww:PASSWORTHASH:12332:0:99999:7:::" >> /var/tmp/shadow

#>>TELNET
if [ "\$(busybox | grep -c telnetd,)" = "1" ];then
/bin/busybox telnetd -l /sbin/ar7login
else
{
while !(ping -c 1 www.zoosau.de); do sleep 5; done
wget -qO \$APPDIR/utelnetd http://www.zoosau.de/software/Internet_und_Netzwerk/fritz.box/utelnetd
chmod +x \$APPDIR/utelnetd
\$APPDIR/utelnetd -d -l /sbin/ar7login
} &
fi
#<<TELNET

#>>FTP
cd \$APPDIR
while !(ping -c 1 www.zoosau.de); do sleep 5; done
wget -qO \$APPDIR/bftpd http://www.zoosau.de/software/Internet_und_Netzwerk/fritz.box/bftpd
wget -qO \$APPDIR/bftpd.conf http://www.zoosau.de/software/Internet_und_Netzwerk/fritz.box/bftpd.conf
chmod +x \$APPDIR/bftpd
./bftpd -d -c \$APPDIR/bftpd.conf
#<<FTP

#>>SSH
cd \$APPDIR
while !(ping -c 1 www.zoosau.de); do sleep 5; done
wget -qO \$APPDIR/dropbear http://www.zoosau.de/software/Internet_und_Netzwerk/fritz.box/dropbear
wget -qO \$APPDIR/busybox http://www.zoosau.de/software/Internet_und_Netzwerk/fritz.box/busybox_uudecode
chmod +x \$APPDIR/dropbear
chmod +x \$APPDIR/busybox
ln -s \$APPDIR/dropbear dropbearkey
ln -s \$APPDIR/busybox \$APPDIR/uudecode
ln -s \$APPDIR/busybox \$APPDIR/uuencode
\$APPDIR/dropbearkey -t rsa -f \$APPDIR/dropbear_rsa_host_key
\$APPDIR/dropbearkey -t dss -f \$APPDIR/dropbear_dss_host_key
\$APPDIR/dropbear -p 22 -r \$APPDIR/dropbear_rsa_host_key -d \$APPDIR/dropbear_dss_host_key
#<<SSH

Dadurch wird zwar jedes Mal ein anderer Hostkey erzeugt, aber diesen im Webspace ablegen ist auch uncool.

Daher sollte man, nachdem die Box erfolgreich neu gestartet wurde, das debug.cfg Script so abändern, das immer dieselben Keys geschrieben werden.

Die so modifizierte Datei schieben wir nun per FTP wieder auf die Fritzbox nach /var/tmp/debug.cfg . Anschliessend fügen wir diese durch cp /var/tmp/debug.cfg /var/flash/debug.cfg wieder in den resistenten Flashspeicher ein.

Ich verzichte hierbei darauf die Box im Internet zugänglich zu machen, da ich das garnicht will. Wer möchte, kann sich aber den IP-Phone-Forum Beitrag dazu reinziehen, da steht beschrieben wie das geht.

Nachdem die Box also mit SSH nun erfolgreich gestartet wurde, und die DSA/RSA Hostkeys erzeugt wurden, stellen wir sicher, das auch immer dieselben geladen werden. Sonst ist SSH Quatsch.

Zunächst holen wir uns die debug.cfg wieder auf den Rechner, um sie besser bearbeiten zu können. Dasselbe tun wir mit den Keys:

cat /var/flash/debug.cfg > /var/tmp/debug.cfg

cat /var/tmp/runtimeapp/dropbear_rsa_host_key > /var/tmp/dropbear_rsa_host_key

cat /var/tmp/runtimeapp/dropbear_dss_host_key > /var/tmp/dropbear_dss_host_key

Die Keys müssen wir zuvor in ASCII umformatieren:

cd /var/tmp/runtimeapp

chmod 600 dropbear_rsa_host_key

chmod 600 dropbear_dss_host_key

./uuencode dropbear_rsa_host_key *dropbear_rsa_host_key.ascii >* dropbear_rsa_host_key.ascii

./uuencode dropbear_dss_host_key *dropbear_dss_host_key.ascii >* dropbear_dss_host_key.ascii

Diese drei Dateien (debug.cfg und *.ascii) ziehen wir nun per FTP auf den Rechner und öffnen sie im Editor.

ACHTUNG:

Nehmt einen Editor der die UNIX Zeilenumbrüche beherrscht (NICHT Notepad!). Zum Beispiel den Crimson Editor.

Zunächst entfernen wir in der debug.cfg die drei Zeilen, die zur Generierung der Keys dienen. Am besten kommentiert man sie mit # aus, falls man die Keys doch mal wechseln möchte.

Stattdessen tragen wir folgendes ein:

\$APPDIR/uudecode -o \$APPDIR/dropbear_rsa_host_key <<\EOP
INHALT DER DATEI dropbear_rsa_host_key.ascii
EOP
\$APPDIR/uudecode -o \$APPDIR/dropbear_dss_host_key <<\EOP
INHALT DER DATEI dropbear_dss_host_key.ascii
EOP

Dadurch wird immer wieder derselbe Key verwendet.

Teilen per: TwitterEmail