unerklärliches "connection refused"

[Homesick Alien]

Ich besitze zwei Rechner. Auf meinem Client läuft Kubuntu, auf meinem Server läuft Xubuntu in der Server-Version. Nun greife ich mit SSH auf meinem Server zu, was auch einige Tage (einige male) einwandfrei funktioniert.

Doch plötzlich ohne, dass ich etwas konfiguriere, bekomme ich beim connecten folgende Fehlermeldung: "ssh: connect to host 192.168.1.34 port 22: Connection refused".
Wenn ich dann den Server komplett neu installiere funktioniert alles einwandfrei. Woran liegt das?

[Homesick Alien]

Also jetzt habe ich rausbekommen woran es lag: Meine beiden Rechner haben ihre IP-Adressen vertauscht. Nun funktioniert alles wieder. Mir ist die Sache jedoch unheimlich. Was hat das zu bedeuten?

[bla!zilla]

Das DHCP zugeschlagen hat?

[Homesick Alien]

...und was ist DHCP?

[stefan.becker]

Datt wissen die Kumpels von Goggel!

[bla!zilla]

...und was ist DHCP?

Siehe RFC 2131.

[Homesick Alien]

sorry...aber was ich da finde ist mir zu hoch. Verratet mir doch bitte, was ich tun muss, damit die Adressen konstant bleiben.

[bla!zilla]

Einfach statische IP-Adressen vergeben, und nicht die IP-Adresse zuweisen lassen.

[marce]

oder im DHCP-Server (dein Router?) einstellen, dass statische dynamische IPs vergeben werden...

[buffoon]

Zu SSH:
SSH speichert bei der 1. verbindung mit einem pc den fingerprint (Ist so ne Art "Unterschrift"). Wenn sich jetzt die IP adressen von 2 systemen vertauschen vergleicht SSH diese Unterschriften und wenn die abweichen sperrt er verbindungen. zum lösen dieses Problems gibt es 2 Möglichkeiten: hostnames anstelle von IP Adressen verwenden oder statische IP adressen vergeben

[zeromancer1972]

Zu SSH:
SSH speichert bei der 1. verbindung mit einem pc den fingerprint (Ist so ne Art "Unterschrift"). Wenn sich jetzt die IP adressen von 2 systemen vertauschen vergleicht SSH diese Unterschriften und wenn die abweichen sperrt er verbindungen. zum lösen dieses Problems gibt es 2 Möglichkeiten: hostnames anstelle von IP Adressen verwenden oder statische IP adressen vergeben

Oder aber die
~/.ssh/known_hosts löschen ;)

Zur statischen IP:
In
/etc/network/interfaces
stellst Du die Betriebsart ein.
Such dort Dein Interface (z.B. eth0) - dort ist eine Zeile zu sehen, in der "DHCP" am Ende steht. Tausche dies aus gegen "static"
Darunter packst Du folgendes:

address 192.168.1.34
netmask 255.255.255.0
gateway 192.168.1.0

Beziehungsweise: statt 192.168.1.34 eben die andere Adresse des 2. Rechners (meinetwegen .35 am Ende) und als Gateway die IP Deines Routers (die 192.168.1.0 war nur geraten).

[pehta]

Hallo ihrs!

Mein 1. Beitrag. Ich denke ich habe etwas Ähnliches verbrochen bei unserem Agenturserver. Er hatte ursprünglich die 192.168.0.10 und wurde ins Switch von 192.168.1.xxx gestöpselt. Nachdem er nicht erreichbar war habe ich mit ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up die IP geändert und gibt nun einen positiven Response beim Ping, allerdings laüft ssh nicht mehr. bekomme immer Connection refused

known_hosts unter osx habe ich bereits editiert und den RSA Key für 0.10 entfernt. Was kann ich jetzt tun ? Habe den Server noch nicht neugestartet, allerdings irgendwo gelesen dass eine solche IP änderung nur temporär sei. Auf dem server läuft Dapper Drake 6.06


Nachtrag:

Hab jetzt Zugriff über die lokale Console. hab in /etc/network/interfaces auch die restlichen konfigurationen vorgenommen wie den Broadkast auf 255 + gateway und DNS auf 1.1 am Ende. Wie kann ich den Server diese Datei neu auslesen lassen ?

[encore]

vllt haste auch einfach deine Firewall eingestellt und vergessen diese anzupassen, also Port 22 freizugeben? Ist mir schon paar mal passiert ^^

[pehta]

SSH stand auf Listen (alte ip) deswegen bekam ich ein connection refused sowohl bei sftp als auch ssh

[ThorstenS]

Beim manuellen Ändern der IP hilft unter debian meist ein

/etc/init.d/networking restart
Überprüfen wo welcher Dienst horcht, kannst du mit

lsof -ni | less
Wenn da noch eine alte Adresse auftaucht (anstelle z.b. eines Sternchens), musst du den Dienst neu starten.

[cane]

Oder aber die
~/.ssh/known_hosts löschen ;)


Besser nur die betreffende Zeile, vor allem wenn man viele Hosts drinne hat.


cane@cane:~$ wc -l .ssh/known_hosts
135 .ssh/known_hosts

Wenn ich das File wegpuste hieße das in den nächsten Tagen 135 mal "yes" tippen :ugly:

mfg
cane

[marce]

Da könnte man ja auch den Client ja gleich so konfigurieren, dass er derlei Überprüfungen einfach nicht macht :-)

[ThorstenS]

Du kannst in dem file auch selektiv löschen.
Bis debian/sarge war es im Klartext zu lesen, seit etch sind die Einträge verschlüsselt.

Du kannst aber die entsprechende Zeile finden:

~# ssh-keygen -F hostname.domain.tld
# Host hostname.domain.tld found: line 824 type RSA
|1|U+U9oemchsmrdFBJBkdQfImvfnk=|bBxKPpi7ta/koG5MTXwUkoFE9U4= ssh-rsa AAAAB3NzaC1yc2EAAAABIwABCIEAtv6+NhUPPn5hezkS83/QYuv3DxP2F6OBhCLwIDeOW5IJJ+G4hbz3Z4awAXtaiKEDSIMhU rQjj/yeLj8/1Bq4/ni0piYAWXuR1ytB+aH0TKAgVSmVttBo/xr0UwvoQuIpQ0N8oZQDku2hXku/r3aeri9MPyf/n9N9vJ2kDj08WKk=

die Zeile 824 kannst du dann löschen - auch automatisiert, dafür hab ich mir neulich ein kleines Script gebastelt:

#!/bin/sh
#
# Loescht einen Host aus der known_hosts, wenn diese
# im hashed Format vorliegt.
# eine Umwandlung erfolgt mit: ssh-keygen -H
#
HOST=$(echo ${1:-keinHorstGesetzt})
HASH=$(ssh-keygen -F $HOST | grep -v ^# | awk -F '|' '{print $3}')
sed -i -e "/$HASH/d" ~/.ssh/known_hosts
echo -e "Eintrag $HOST entfernt"

[bla!zilla]

Da könnte man ja auch den Client ja gleich so konfigurieren, dass er derlei Überprüfungen einfach nicht macht :-)

Mir sind Installationen bekannt da wird der Key _händisch_ eingetragen, um ganz sicher zu gehen. Aber Sicherheit wird eh überbewertet.