Kein ssh mehr möglich

[linuxnutzer]

Ich vermute mal, er hat das auf OpenWrt ausgeführt.

Nein die Probleme sind zwischen 2 Ubuntu PCs. Ubuntu 26.04 (auf .146) zu Openwrt funktioniert.

Ich könnte auch viel schneller den .146-PC neu installieren, da ist praktisch nichts konfiguriert oder installiert, aber ich muss noch einen openwrt-Router flashen und den Router ins Frtizbox-Netz bringen. Aber ich würde schon gern wissen was da los ist.

 

[Uridium]

Dann ist der sshd in Ubuntu tatsächlich in sbin.
Dann hast Du ja jetzt alles, was Du brauchst.

 

[foofoobar]

@Uridium In #11 wurde es so aufgerufen.

$ type sshd
sshd is /usr/sbin/sshd
$ lsb_release -a
No LSB modules are available.
Distributor ID:    Linuxmint
Description:    Linux Mint 22.3
Release:    22.3
Codename:    zena
$

Ergänzung (Freitag um 22:26)

Nein die Probleme sind zwischen 2 Ubuntu PCs. Ubuntu 26.04 (auf .146) zu Openwrt funktioniert.

[ ....]

Aber ich würde schon gern wissen was da los ist.

Dann formuliere deine Probleme so das die für andere besser und einfacher nachvollziehbar sind. (Empathie)

 

[linuxnutzer]

Dann formuliere deine Probleme so das die für andere besser und einfacher nachvollziehbar sind.

Würde ich gerne machen, aber ich habe keine Ahnung was passiert ist. Eingangs habe ich geschrieben, dass schon alles problemlos war. Ich vermute, da hat sich was automatisch geändert. Ich habe den gleichen PC nochtmals, keine Probleme, der ist auch nur installiert.

Am HauptPC
.41

$ type sshd
sshd ist /usr/sbin/sshd

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 24.04.4 LTS
Release: 24.04
Codename: noble

PC
.146

$ type sshd
sshd ist /usr/sbin/sshd

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 26.04 LTS
Release: 26.04
Codename: resolute

Ergänzung (Freitag um 22:55)

Auf dem Server (da wo Du mit SSH hin verbinden willst) muss das ausgeführt werden. Wenn das richtig läuft, bleibt die Ausgabe stehen (und wartet, kein Shell Prompt). Dann vom anderen Rechner (Client) mit 'ssh 1.2.3.4' zum Server verbinden.

Also bitte jetzt nochmal die korrigierten Befehle, die ich ausführen soll.

 

[Uridium]

Rechner1 (192.168.178.146):

$ sudo systemctl stop ssh.socket
$ sudo /usr/sbin/sshd -dd

Rechner2:

$ ssh 192.168.178.146

@Uridium In #11 wurde es so aufgerufen.

Ja, ist mir nicht aufgefallen. Hat er ja auch selbst korrigiert.

 

[linuxnutzer]

Rechner1 (192.168.178.146):

$ sudo systemctl stop ssh.socket

$ sudo /usr/sbin/sshd -dd
debug1: sshd version OpenSSH_10.2, OpenSSL 3.5.5 27 Jan 2026
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 4308
debug2: parse_server_config_depth: config /etc/ssh/sshd_config len 4308
debug2: /etc/ssh/sshd_config line 24: new include /etc/ssh/sshd_config.d/*.conf
debug2: /etc/ssh/sshd_config line 24: no match for /etc/ssh/sshd_config.d/*.conf
debug1: private host key #0: ssh-rsa SHA256:...
debug1: private host key #1: ecdsa-sha2-nistp256 SHA256:---
debug1: private host key #2: ssh-ed25519 SHA256:...
Missing privilege separation directory: /run/sshd

Rechner2:

$ ssh 192.168.178.146
ssh: connect to host 192.168.178.146 port 22: Connection refused

Ergänzung (Freitag um 23:18)

Das ist jetzt neu:

ping -c4 192.168.178.41
PING 192.168.178.41 (192.168.178.41) 56(84) bytes of data.
64 bytes from 192.168.178.41: icmp_seq=1 ttl=64 time=19.6 ms
64 bytes from 192.168.178.41: icmp_seq=2 ttl=64 time=8.99 ms
64 bytes from 192.168.178.41: icmp_seq=3 ttl=64 time=5.63 ms
64 bytes from 192.168.178.41: icmp_seq=4 ttl=64 time=4.37 ms

--- 192.168.178.41 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 4.366/9.654/19.629/6.001 ms

Aber auch vom .146 ssh zu .41

$ ssh 192.168.178.41
ssh: connect to host 192.168.178.41 port 22: Connection refused

 

[Uridium]

Missing privilege separation directory: /run/sshd

Da stimmt was ganz gewaltig nicht mit deinem System. Das ist nicht richtig eingerichtet. Den Fehler kannst Du temporär hiermit korrigieren. Das macht normalerweise 'tmpfiles.d' automatisch bei Systemstart. Das sieht irgendwie nach Core/Netinstall/Custom Version aus. Nichts für Anfänger.

$ sudo mkdir -p -m0755 /run/sshd

Das könnte auch schon der Fehler gewesen sein. Der Ordner ist, wie man sieht, obligatorisch.

 

[linuxnutzer]

Ich bin mir sicher, nichts umkonfiguriert zu habenm nur Ethernetkabel mehrmals umgesteckt. Netzwerke wurdem mehrmals neu gestartet.

Ich habe in der Zwischenzeit einen Openwrt-Router auf das Fritzbox-Netz umgestellt. Davor hat ssh zum openwrt-Netz funktioniert und ich konnte alles am Router via ssh machen. Jetzt komme ich vom .146 PC nicht mehr via ssh zum router, vom ,41 schon. Es dürfte also irgendwie mit dem FB-Netz zusammen hängen.

Also neu installieren, wäre sowieso die schnellste Lösung gewesen, aber wenn die Probleme beim Flashem des 2. Routers wieder passieren, ist das nervig.

Ob es ein Versuch wäre "apt purge ssh" ?

 

[zelect0r]

debug1: load_hostkeys: fopen /home/ab/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory

was ist denn damit?

 

[Uridium]

Jetzt komme ich vom .146 PC nicht mehr via ssh zum router, vom ,41 schon.

Du kommst also nicht auf den .146 (das ursprüngliche Problem) und Du kannst jetzt auch nicht von diesem PC auf den OpenWrt via SSH zugreifen (neues Problem).

Ersteres Problem ist identifiziert (fehlender Ordner /run/sshd). Das zweite sollte mit 'ssh -v openwrt.ip' Aufschluss bringen (der sshd von OpenWrt läuft ja nachweislich korrekt). Das kann ebenfalls ein fehlender Ordner sein, der den ssh client(!) 'ssh' blockt.

Was sagt denn 'journalctl -u systemd-tmpfiles-setup.service' (im .146)?

 

[redjack1000]

Ich habe ein bisschen rumgetrickst beim Netzwerk, aber sollte nichts verändert haben.

Ich bin mir sicher, nichts umkonfiguriert zu habenm nur Ethernetkabel mehrmals umgesteckt.

Ahhh ja.

CU
redjack

 

[linuxnutzer]

Ahhh ja.

Vor allem weil es heute in beiden Richtungen funktioniert, zeigt das, dass ich nichts verkonfiguriert habe.

Von .41 zu .146 funktionieren ssh-keys wie immer
von .146 zu .41 brauche ich ein PW, funktioniert auch

Zugriff auf den openwrt-Router .13 funktioniert heute von .41 und .146
Könnte ein arp-cache mich zum Verzweifeln gebracht haben? Ich hatte vor einiger Zeit das Problem, dass verschiedene Ubuntu 26.04 Varianten mit ssh problemlos waren, aber kubuntu nicht. Die ssh.Verbindung mit kubuntu war möglich, aber extrem langsam und unbrauchbar für simple Shell-Befehle, Zeichen für Zeichen mit Pausen konnte man zuschauen.

Ergänzung (Samstag um 11:29)

Hmmh, kann es damit zusammen hängen?

Erhalte gerade am .41 diese Meldung, gestern problemlos.

$ ssh root@192.168.178.11
** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.
** The server may need to be upgraded. See https://openssh.com/pq.html
root@192.168.178.11: Permission denied (publickey).

Ich weiß jetzt aber nicht, wer diese Meldung ausgibt. Der Client von .41 ?

Ich bin gerade dabei den Router .11 akutell mit openwrt zu flashen, der .13 ist schon aktuell, der hat gestern gezickt. Jetzt ist. 13 problemlos und fehlerfrei.

Ergänzung (Samstag um 11:58)

Ist zum Durchdrehen, jetzt funktioniert der Zugriff auf .11 fehlerfrei ohne diese Quantum-Meldung.