Nach einem debian Upgrade kann ich mich nicht mit ssh anmelden

[ioar]

Hallo zusammen,

nach einem server upgrade zu debian 12 und anschließendem reboot kann ich mich ich weder mit ssh, noch per sftp auf meinem Server anmelden.
Mein Anmeldeversuch wird stetig mit "connection refused" abgelehnt.

Im rescue mode des Hetzer gehosteten Servers, kann ich im chroot das system mounten:

Code: Alles auswählen

# mount --bind /dev /mount/point/dev
# mount --bind /dev/pts /mount/point/dev/pts
# mount --bind /proc /mount/point/proc
# mount --bind /sys /mount/point/sys
# chroot /mount/point/

dort versuchte ich folgendes, hat aber nicht geholfen:

Code: Alles auswählen

systemctl enable ssh

Auch in der /etc/ssh/sshd_config konnte ich nichts auffälliges entdecken. Die Firewall ist auch deaktiviert (meines wissens). Ich erkenne nicht den Grund warum mein Anmeldeversuch abgelehnt wird.

Hat jemand eine Idee mit der ich weiterkommen könnte?

Vielen Dank euch

Grüße

I.

[whisper]

• service ssh status sagt was?
  nmap deine serverip port 22 offen?
  mit ssh -v deine serverip probieren
  du kannst versuchsweise den sshd ja auch mal auf einem anderen port starten und versuchen dich da zu verbinden

[ioar]

Danke für die schelle antwort!

Wenn ich im rescue mode bin, dann bekomme ich ür

Code: Alles auswählen

root@rescue / # service ssh status
sshd is not running ... failed!

und für:

Code: Alles auswählen

root@rescue / # systemctl start ssh.service
Running in chroot, ignoring request: start

den port habe ich in der
/etc/ssh/sshd_config auf Port 2222 gesetzt und verusche es nachdem ich das system wieder rebootet habe. Dann wäre ich aus dem rescue mode wieder raus. Vorherst aber würde ich gern herausfinden, wie man den ssh service so einstellen kann, dass er beim nächsten reboot automatisch mitstartet. Gibt es eine Methode, die man aus dem rescue mode so einstellen kann?

[mat6937]

Code: Alles auswählen

root@rescue / # systemctl start ssh.service
Running in chroot, ignoring request: start

den port habe ich in der
/etc/ssh/sshd_config auf Port 2222 gesetzt und verusche es nachdem ich das system wieder rebootet habe.

Wie sind die Ausgaben von:

Code: Alles auswählen

sshd -t
systemctl status ssh
systemctl is-enabled ssh

?

[ioar]

Code: Alles auswählen

root@rescue / # sshd -t
root@rescue / #

Code: Alles auswählen

root@rescue / # systemctl status ssh
Running in chroot, ignoring request: status

Code: Alles auswählen

root@rescue / # systemctl is-enabled ssh
enabled

[mat6937]

Code: Alles auswählen

root@rescue / # systemctl is-enabled ssh
enabled

D. h. nach einem reboot sollte der sshd auch gestartet sein.

[ioar]

danke,

leider bekomme ich weiterhin:
connection refused:

Code: Alles auswählen

ssh -v  XX.XX.XXX.XXX -p 2222

debug1: Connecting to XX.XX.XXX.XXX [XX.XX.XXX.XXX] port 2222.
debug1: connect to address XX.XX.XXX.XXX port 2222: Connection refused
ssh: connect to host XX.XX.XXX.XXX port 2222: Connection refused

[mat6937]

connection refused:

Code: Alles auswählen

ssh -v  XX.XX.XXX.XXX -p 2222

Wie ist die Ausgabe von:

Code: Alles auswählen

nc -zv XX.XX.XXX.XXX 2222

?

[whisper]

Für mich sieht das so aus, als würde 2222 nicht offen,
mach doch mal nmap ip
und gucke bei hetzner, ob da eine firewall aktiv ist.
Ich nutze die von hetzner nicht, aber vielleicht ist sie warum auch immer aktiv.

[ioar]

ich habe unter anderem:

Code: Alles auswählen

ssh -vvv  XX.XX.XXX.XXX -p 2222
debug2: ssh_connect_direct

die ports scheine geschlossen zu sein:

Code: Alles auswählen

PORT     STATE  SERVICE
2222/tcp closed EtherNetIP-1

Code: Alles auswählen

PORT   STATE  SERVICE
22/tcp closed ssh

Danke! Ich müsste den Port nun öffen im chroot?

[whisper]

Nee, bei hetzner
https://robot.hetzner.com/server
dort sollte bei dir alles auf allow stehen, aber gucke lieber mal
In deinem rescue system und dem chrooted sollte

Code: Alles auswählen

netstat -tlpn|grep 22

Ergebnisse liefern

[ioar]

bei Hetzner habe ich firewall deaktiviert und den filter ssh auf tcp, ip4 0.0.0.0/0 gesetzt

trotzdem bekomme ich:

Code: Alles auswählen

PORT   STATE  SERVICE
22/tcp closed ssh

[ioar]

Code: Alles auswählen

root@rescue / # netstat -tlpn|grep 22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      2815/sshd: /usr/sbi
tcp        0      0 0.0.0.0:222             0.0.0.0:*               LISTEN      2815/sshd: /usr/sbi
tcp6       0      0 :::22                   :::*                    LISTEN      2815/sshd: /usr/sbi
tcp6       0      0 :::222                  :::*                    LISTEN      2815/sshd: /usr/sbi

[whisper]

Blöde frage: wie bist du denn a eingeloggt?
per kvm, oder wie?

[ioar]

Hi whisper, es ist keine Virtelle Maschine sondern ein Server mit Debian. Eingelogt bin ich über putty über den secure mode.

[MSfree]

Eingelogt bin ich über putty über den secure mode.

Ich nutze putty seit vielen Jahren, aber ein "secure Mode" ist mir dort bisher nie aufgefallen. Was soll das sein?

Ansonsten, putty ist ein SSH-Client.

OK, putty beherrscht auch telnet, das wirst du hier aber wohl nicht verwenden.

[ioar]

sorry... ich meinte das "Rescue System" von Hetzer

[MSfree]

sorry... ich meinte das "Rescue System" von Hetzer

In dem Fall sind sind sämtliche Informationen (systemctl...status...), die du oben gegeben hast, wertlos, weil die sich nur auf die aktuell laufende Rettungskonsole beziehen und noch dazu in einer chroot-Umgebung (erklärbar durch das Rettungssystem) laufen.

Interessant wäre hier mal die Ausgabe des Logs:

Code: Alles auswählen

journalctl | grep sshd

Idealerweise filterst du die Ausgabe noch nach Datum, seit dem der Fehler auftritt.

[whisper]

Wie jetzt? Du kommst mit putty auf das resque system drauf?
Dann ist doch alles gut. Das ist doch auch ssh.
Wie machst du das sonst?
Immer mit putty?
Hattest du public key verfahren genutzt?
Das resque system hat ja einen anderen key und keinen von dir, das geht nur mit dem von hetzner mitgeteilten login.
Oder machst du immer user/password?

[ioar]

sorry... ich meinte das "Rescue System" von Hetzer

In dem Fall sind sind sämtliche Informationen (systemctl...status...), die du oben gegeben hast, wertlos, weil die sich nur auf die aktuell laufende Rettungskonsole beziehen und noch dazu in einer chroot-Umgebung (erklärbar durch das Rettungssystem) laufen.

Interessant wäre hier mal die Ausgabe des Logs:

Code: Alles auswählen

journalctl | grep sshd

Idealerweise filterst du die Ausgabe noch nach Datum, seit dem der Fehler auftritt.

das journalctl | grep sshd, liefert mir für die letzten 2 Tage nichts/leere Ausgabe.

Dennoch für:

Code: Alles auswählen

journalctl -b -1

fällt mir insbesondere diese Fehlermeldung auf:

Code: Alles auswählen

memory453: /usr/lib/udev/rules.d/73-seat-late.rules:13 Failed to import properties 'ID_SEAT' from parent: Operation not permitted

Ich habe heute um 18:00 Uhr einen Termin bei Hetzner für das KVM bekommen. Da würde ich versuchen ins Betriebsystem zu kommen, denn es könnte sein, dass das kaputte System irgendwo hängt?

Danke für eure Hilfe!

Grüße

Ioar

[ioar]

Wie jetzt? Du kommst mit putty auf das resque system drauf? <---- ja
Dann ist doch alles gut. Das ist doch auch ssh.
Wie machst du das sonst?
Immer mit putty? <--- ja
Hattest du public key verfahren genutzt? <-- nein
Das resque system hat ja einen anderen key und keinen von dir, das geht nur mit dem von hetzner mitgeteilten login.
Oder machst du immer user/password? <-- ja

Das public key verfahren kenne ich nicht so gut. Ich habe vor einiger zeit mal sowas gemacht aber meine Kentnisse sind nicht so dass ich problemlos das wieder einrichten kann.

[ioar]

Im KVM sehe ich für swap und /boot und /home folgende meldungen

Code: Alles auswählen

Dependency failed for /swap  /boot /home
Dependency failed for Local File Systems
TIme Timed out waiting for device ##8-11111-1111......11....

/etc/fstab

Code: Alles auswählen

proc /proc proc defaults 0 0
# /dev/md/0
UUID=8f8118-11111-1111......11.... none swap sw 0 0
# /dev/md/1
UUID=6a8f8118-11111-1111......11....  /boot ext3 defaults 0 0
# /dev/md/2
UUID=c18f8118-11111-1111......11....  / ext4 defaults 0 0
# /dev/md/3
UUID=bf68f8118-11111-1111......11....  /home ext4 defaults 0 0

die uuids die blkid ausgibt sind die, die auch in der fstab stehen?
das system hängt sich auf bevor es zuende booten kann. was kann ich machen, habt ihr mir einen Tipp?

[whisper]

Für mich sieht das nach Plattenschaden aus.
KAnnst du auch ins Bios? Wenn das geht gucke da was die platten sagen, oder gleich Den Techniker bei Hetzner bitten mal zu gucken.
Backup hast du hoffentlich
Aber vielleicht weiß ein Forist ja noch mehr.

[ioar]

Ich hoffe das ist kein Plattenfehler. Wenn ich die uuid Einträge im fstab auskommentiere, komme ich ja ins System über KVM und auch über PuTTY und sehe auch meine Dateien! Dennoch kann ich die Dateien lesen aber nicht beschreiben.

Über das KVM kann ich wenn die normale fstab (nicht auskommentiere Einträge) in den emergency Mode gelangen und auch auf meine Daten zugreifen.
Ich gehe davon aus, dass die uuids nach dem Upgrade nicht korrekt sind. Aber ich weiß nicht genau wie ich das untersuchen soll

Sollte ich meine Daten schnellmöglichst sichern? Ich hab nicht alles als Backup. Die Datenbanken würde ich gerne Backupen.

[whisper]

Ich hoffe das ist kein Plattenfehler. Wenn ich die uuid Einträge im fstab auskommentiere, komme ich ja ins System über KVM und auch über PuTTY und sehe auch meine Dateien! Dennoch kann ich die Dateien lesen aber nicht beschreiben.

Über das KVM kann ich wenn die normale fstab (nicht auskommentiere Einträge) in den emergency Mode gelangen und auch auf meine Daten zugreifen.
Ich gehe davon aus, dass die uuids nach dem Upgrade nicht korrekt sind. Aber ich weiß nicht genau wie ich das untersuchen soll

Sollte ich meine Daten schnellmöglichst sichern? Ich hab nicht alles als Backup. Die Datenbanken würde ich gerne Backupen.

So ganz steige ich nicht dahinter,
aber ein Backup ist immer eine gute idee.
was sagt denn smartctl -a /devt/sda ?