Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Die ssh-Verbindung zwischen einem Ubuntu 24.04-PC und 26.06 PC hat schon ganz normal funktioniert, seit kurzem funktioniert sie meistens gar nicht bzw. extrem langsam.
Möglich ist alles, auch ein Hardware-Problem. Allerdings funktioniert von beiden PCs eine Internetverbindung via Ethernet ganz normal. Ping zwischen den PCs ist auch problemlos. Beide PCs sind im gleichen lokalen Netz.
Die Identifizierung funktioniert mit Keys.
Code:
ssh-keygen -t rsa -b 4096
Kann ich nun einen 2. Key erstellen:
Code:
ssh-keygen -t ed25519
Und beide in ~/.ssh/authorized_keys eintragen? Oder ist es besser den public-key am anderen PC nur 1x einzutragen?
Wie gesagt, es funktioniert manchmal perfekt, manchmal sehr langsam, aber man merkt es beim Schreiben. Oder es funktioniert gar nicht. Meistens schaffe ich es nicht bis zum Prompt. Es könnte ein Update was angestellt haben, da es ja nach der Installation völlig problemlos war. Ohne ed25519 mit Ubuntu 26.04 können immer wieder Fehlermeldungen kommen, aber nicht zwischen Ubuntu-PCs, außer, dass gemeckert wird, dass es unsicher ist.
Vorerst ist meine Frage einfach zur Verwendung von 2 unterschiedlichen Key-Typen.
Habe ich vor, jetzt wollte ich mal wissen, ob ich bei den Keys was falsch machen kann.
Ich hatte ziemliche Problem mit ssh zu einem Mikrotik-Router unter Ubuntu 26-04, unter 24.04 völlig problemlos, ähnlich zu openwrt-Router. Da gibt es die Default-Umstellung zu ed25519 bei 26.04
Vor einiger Zeit hatte ich schon ähnliche Probleme, worauf ich den AP durch eine andere Hardware ersetzte. der PC hängt am Wifi-AP via Ethernet-Kabel., der andere PC hängt direkt im Ethernet-Netzwerk.
Nach dem Wechsel des AP war für einige Zeit alles problemlos, warum auch immer. Der alte AP funktioniert an anderem Standort auch ohne Probleme.
Nachdem nun die Internetverbindung von beiden PCs problemlos ist, sollte man NIC und Kabel ausschließen könnnen. Es hakt nur zwischen diesen PCs. Vor ein paar Tagen habe ich noch 1 TB via rsync übertragen, langsam, aber hat funktioniert. Gestern war dann die Situation, meist keine Verbindung, aber dann vielleicht nach 2 Minuten.
Ich verwende IP-Adressen, also Namensauflösung kann es auch nicht sein.
Doppelte IP kann man ausschließen, ich verwende DHCP mit static leases, Ich check nochmal die static leases, aber sicher keine Änderung seitdem es funktioniert hat. Ein Netzwerkscan mit dem Handy findet nichts doppeltes.
Ich setze auf verbose. Vielleicht sollte ich erstmal keine keys verwenden.
Doppelte IP kann man ausschließen, ich verwende DHCP mit static leases, Ich check nochmal die static leases, aber sicher keine Änderung seitdem es funktioniert hat.
Sollte klappen, aber fixe IPs wären hier sicherer. Wenn das jetzt keine Container etc. sind, und feste Server, würde ich hier eh immer nur fixe IPs verwenden, da muß keine Instanz weiter etwas machen. Bei Static leases mußt Du Dich darauf verlassen, daß der Server oder Router das immer korrekt macht, und das tut es leider manchmal im Consumerbereich nicht richtig.
bitte nicht verschiedene Dinge vermischen.
wenn eine Verbindung aufgebaut wird, die dann aber langsam ist, dann liegt es garantiert nicht an den Keys.
in den allermeisten Fällen, wenn Leute von solchen Probleme berichten, ist eigentlich immer "das Netzwerk" bzw. falsche IP Konfiguration Schuld.
und wenn ich sowas lese wie: DHCP mit static leases und den ganzen AP Problemen, dann bin ich mir eigentlich sicher, dass da jemand sein Netzwerk "kaputt konfiguriert" und statt nach der Wurzel des Übels zu suchen, neue ssh keys generiert...
In der DHCP-Konfiguration gibt es bei den static leases auch keine doppelten Einträge.
Wenn da eine falsche MAC eingegeben wäre, dann würden die PCs eben eine andere IP bekommen. Wäre kein großes Problem, dann funktioniert der Ping über die angegebene IP nicht.
Ich habe heute noch gar nichts umkonfiguriert, sondern nur probiert und zufällig funktioniert es (rasch).
Code:
$ ssh -v 192.168.178.31
OpenSSH_9.6p1 Ubuntu-3ubuntu13.18, OpenSSL 3.0.13 30 Jan 2024
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 192.168.178.31 [192.168.178.31] port 22.
debug1: Connection established.
debug1: identity file ~/.ssh/id_rsa type 0
debug1: identity file ~/.ssh/id_rsa-cert type -1
debug1: identity file ~/.ssh/id_ecdsa type -1
debug1: identity file ~/.ssh/id_ecdsa-cert type -1
debug1: identity file ~/.ssh/id_ecdsa_sk type -1
debug1: identity file ~/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file ~/.ssh/id_ed25519 type -1
debug1: identity file ~/.ssh/id_ed25519-cert type -1
debug1: identity file ~/.ssh/id_ed25519_sk type -1
debug1: identity file ~/.ssh/id_ed25519_sk-cert type -1
debug1: identity file ~/.ssh/id_xmss type -1
debug1: identity file ~/.ssh/id_xmss-cert type -1
debug1: identity file ~/.ssh/id_dsa type -1
debug1: identity file ~/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.18
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.2p1 Ubuntu-2ubuntu3.5
debug1: compat_banner: match: OpenSSH_10.2p1 Ubuntu-2ubuntu3.5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.178.31:22 as 'ab'
debug1: load_hostkeys: fopen ~/.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
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: sntrup761x25519-sha512@openssh.com
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:Re-------------------------TU
debug1: load_hostkeys: fopen ~/.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
debug1: Host '192.168.178.31' is known and matches the ED25519 host key.
debug1: Found key in ~/.ssh/known_hosts:65
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: Sending SSH2_MSG_EXT_INFO
debug1: expecting SSH2_MSG_NEWKEYS
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256>
debug1: kex_ext_info_check_ver: publickey-hostbound@openssh.com=<0>
debug1: kex_ext_info_check_ver: ping@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_ext_info_client_parse: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256>
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 1 keys
debug1: Will attempt key: ~/.ssh/id_rsa RSA SHA256:VC-------------------------tL/Nv...Eg agent
debug1: Will attempt key: ~/.ssh/id_ecdsa
debug1: Will attempt key: ~/.ssh/id_ecdsa_sk
debug1: Will attempt key: ~/.ssh/id_ed25519
debug1: Will attempt key: ~/.ssh/id_ed25519_sk
debug1: Will attempt key: ~/.ssh/id_xmss
debug1: Will attempt key: ~/.ssh/id_dsa
debug1: Offering public key: ~/.ssh/id_rsa RSA SHA256:VC-------------------------tL/Nv...Eg agent
debug1: Server accepts key: ~/.ssh/id_rsa RSA SHA256:VC-------------------------tL/Nv...Eg agent
Authenticated to 192.168.178.31 ([192.168.178.31]:22) using "publickey".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: client_input_hostkeys: searching ~/.ssh/known_hosts for 192.168.178.31 / (none)
debug1: client_input_hostkeys: searching ~/.ssh/known_hosts2 for 192.168.178.31 / (none)
debug1: client_input_hostkeys: hostkeys file ~/.ssh/known_hosts2 does not exist
debug1: client_input_hostkeys: no new or deprecated keys from server
debug1: Remote: ~/.ssh/authorized_keys:2: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Remote: ~/.ssh/authorized_keys:2: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug1: Sending environment.
debug1: channel 0: setting env LC_ADDRESS = "C.UTF-8"
debug1: channel 0: setting env LC_NAME = "C.UTF-8"
debug1: channel 0: setting env LC_MONETARY = "C.UTF-8"
debug1: channel 0: setting env LC_PAPER = "C.UTF-8"
debug1: channel 0: setting env LANG = "de_DE.UTF-8"
debug1: channel 0: setting env LC_IDENTIFICATION = "C.UTF-8"
debug1: channel 0: setting env LC_TELEPHONE = "C.UTF-8"
debug1: channel 0: setting env LC_MEASUREMENT = "C.UTF-8"
debug1: channel 0: setting env LC_TIME = "C.UTF-8"
debug1: channel 0: setting env LC_NUMERIC = "C.UTF-8"
debug1: pledge: fork
Welcome to Ubuntu 26.04.1 LTS (GNU/Linux 7.0.0-30-generic x86_64)
* Documentation: https://docs.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/pro
Erweiterte Sicherheitswartung (ESM) für Applications ist nicht aktiviert.
0 Aktualisierungen können sofort angewendet werden.
30 zusätzliche Sicherheitsupdates können mit ESM Apps angewendet werden.
Erfahren Sie mehr über die Aktivierung des ESM Apps-Dienstes at https://ubuntu.com/esm
Last login: Thu Aug 27 19:56:51 2026 from 192.168.178.41
So, und jetzt darf kreativ überlegt werden, warum der ssh-Befehl manchmal in der Konsole nicht beendet wird oder sehr lange dauert bis der Prompt kommt. Die Verwendung eines anderen Typs war ja nur eine Idee.
Da kenne ich mich zuwenig aus, aber es gibt keine User, die viel Traffic verbrauchen. Im Netz bin beim Testen nur ich. Der Ping ist immer ähnlich schnell. Direkt vom PC ist die Internetverbindung auch akzeptabel.
An das habe ich auch schon gedacht, dass da irgendwas anderes bremst. Nur die lokale Verbindung soll doch nicht deutlich langsamer als die Verbindung ins Internet. Ich schaffe es ja nicht bis zum Prompt innerhalb von Minuten. Keine Ahnung, vielleicht hätte es nach 10 Minuten eine Verbindung gegeben, so lange habe ich nicht erwartet.
Wenn die lokale Verbindung überlastet ist, dann sollte der Ping ja auch extrem langsam sein.
Ich glaube, ich komme nur weiter, wenn das Problem wieder auftritt.
Könnte es mit dem Energiesparmodus zu tun haben? Ich vermute eher nicht, denn ich hatte das Problem auch nach einem Neustart.
Sehe ich folgendes richtig:
Wenn beide PCs eine Internetverbindung ganz problemlos schaffen, dann ist es unwahrscheinlich, dass die Hardware defekt ist.
Also:
Netzwerkkarte ok
Netzwerkkabel ok
Beteiligte Router ok
Netzwerkkonfiguration grundsätzlich funktionierend.
Ping zwischen beiden PCs zeigt akzeptable Zeiten
Kein wesentlicher Netzwerkverkehr bekannt
Die beiden PCs sind also im Netzwerk grundsätzlich bekannt und erreichbar
Wenn nun die ssh-Verbindung nicht erfolgreich ist, dann gibt es vermutlich bei ssh Probleme, welche auch immer.
Da ping funktioniert, ist eher die Router-Konfiguration nicht das Problem?
das kann soviel sein, ping sagt jetzt nicht soviel aus.
wobei in einem lokalen Netz (WLAN oder Kabel?) ohne viel Traffic bei 3 pings der mittlere über 4ms schon eher "auffällig" ist. Das muss jetzt kein Problem sein, ist ja noch völlig im Rahmen, aber in einem "leeren" Netz liegst du normalerweise im Bereich oder unter 1ms.
wenn du von einem "betroffenen" PC mit nmap "kontrollierst", wirst du wahrscheinlich auch keinen Fehler sehen. Man müsste sich mal die ARP Tabellen ansehen.
ping schickt ja nur 56/64 byte ICMP Pakete, die payload kannst du mit -s mal hoch setzen, z.B. 1024 (noch unter der Standard mtu von 1500) und dann mal 2048, 10240 oder so und mal sehen ob das Imme noch so problemlos läuft.
wie sieht es mit den firewall Einstellungen aus, irgendwelche anderen "komischen" Dinge wie managed Switch oder so?
Auch eine schwierige Sache. Ich mache viel ssh mit PCs im anderen Stockwerk und die Mauern sind zum Teil über 1/2m dick. Das ist gegeben. Ich hatte vorhin gerade getestet, so jeder 10. ping liegt bei 10ms und dann wieder bei 1ms. Alles ok, das erklärt nicht warum ssh Minuten dauern kann.
Gerade ist der Download von flatpak (handbrake) sehr langsam. Ca. 150KB/s. Der .31 hängt direkt via Switch direkt am DSL-Router. Der .41 hängt am Wireless-AP via Ethernet-Kabel.
Mickey Mouse schrieb:
aber in einem "leeren" Netz liegst du normalerweise im Bereich oder unter 1ms.
Da spielt wahrscheinlich meine schlechter WLAN-Situation eine Rolle. Aber ich habe ein Gefühl für Geschwindigkeiten und im Terminal einen Befehl abzusetzen, ist normalerweise kein Problem. Wenn das Tippen im Terminal gebremst ist, stimmt was nicht.
Ja, da wurde ich auch schon zum Narren gehalten, war aber schon lange kein Problem mehr, seitdem die Fritzbox nicht mehr DHCP-Server ist und so viel wie möglich über openwrt läuft.
In dieser Richtung kann ich mir schon was vorstellen. Früher dauerte es mal so 30sec-1min nach dem Start bis Internet funktionierte, das ist aber weg.
Hmmh, nicht wirklich was besonderes bei der Fritzbox. Bei openwrt gibt es VLANs, aber das betrifft diese Verbindung überhaupt nicht. Jedes IOT-Gerät hat ein eigenes Netz. Die IOT-Geräte hängen en einem eigenen Openwrt-Router.
Gute Frage- Ich wollte einen Zyxel managed switch unkonfiguriert verwenden, da hat eine Verbindung gar nicht funktioniert. Mit einem unmanaged Switch von Netgear danach auch nicht gleich, aber dann am nächsten Tag. Sind wir wieder bei einem ARP-Problem.
Ich habe über WLAN im besten Fall bei Videos 16MB/s, sonst die Hälfte. Ist nicht viel, aber reicht. Alles kein Grund, dass der Prompt vom entfernten PC nicht erscheint.
Ergänzung ()
Hier noch ping-Zeiten, wenn nichts im Netz los ist. Immer wieder Einbrüche, aber ist das der Grund, warum ssh nicht fertig ausgeführt wird? Zur Zeif läuft es aber.
Code:
$ ping -c30 192.168.178.31
PING 192.168.178.31 (192.168.178.31) 56(84) bytes of data.
64 bytes from 192.168.178.31: icmp_seq=1 ttl=64 time=8.98 ms
64 bytes from 192.168.178.31: icmp_seq=2 ttl=64 time=1.46 ms
64 bytes from 192.168.178.31: icmp_seq=3 ttl=64 time=1.41 ms
64 bytes from 192.168.178.31: icmp_seq=4 ttl=64 time=1.27 ms
64 bytes from 192.168.178.31: icmp_seq=5 ttl=64 time=1.55 ms
64 bytes from 192.168.178.31: icmp_seq=6 ttl=64 time=1.45 ms
64 bytes from 192.168.178.31: icmp_seq=7 ttl=64 time=1.46 ms
64 bytes from 192.168.178.31: icmp_seq=8 ttl=64 time=1.80 ms
64 bytes from 192.168.178.31: icmp_seq=9 ttl=64 time=28.9 ms
64 bytes from 192.168.178.31: icmp_seq=10 ttl=64 time=2.40 ms
64 bytes from 192.168.178.31: icmp_seq=11 ttl=64 time=1.49 ms
64 bytes from 192.168.178.31: icmp_seq=12 ttl=64 time=1.76 ms
64 bytes from 192.168.178.31: icmp_seq=13 ttl=64 time=9.76 ms
64 bytes from 192.168.178.31: icmp_seq=14 ttl=64 time=1.74 ms
64 bytes from 192.168.178.31: icmp_seq=15 ttl=64 time=1.46 ms
64 bytes from 192.168.178.31: icmp_seq=16 ttl=64 time=19.3 ms
64 bytes from 192.168.178.31: icmp_seq=17 ttl=64 time=1.53 ms
64 bytes from 192.168.178.31: icmp_seq=18 ttl=64 time=1.49 ms
64 bytes from 192.168.178.31: icmp_seq=19 ttl=64 time=1.95 ms
64 bytes from 192.168.178.31: icmp_seq=20 ttl=64 time=1.42 ms
64 bytes from 192.168.178.31: icmp_seq=21 ttl=64 time=32.4 ms
64 bytes from 192.168.178.31: icmp_seq=22 ttl=64 time=6.63 ms
64 bytes from 192.168.178.31: icmp_seq=23 ttl=64 time=1.60 ms
64 bytes from 192.168.178.31: icmp_seq=24 ttl=64 time=1.51 ms
64 bytes from 192.168.178.31: icmp_seq=25 ttl=64 time=1.75 ms
64 bytes from 192.168.178.31: icmp_seq=26 ttl=64 time=33.5 ms
64 bytes from 192.168.178.31: icmp_seq=27 ttl=64 time=4.43 ms
64 bytes from 192.168.178.31: icmp_seq=28 ttl=64 time=1.73 ms
64 bytes from 192.168.178.31: icmp_seq=29 ttl=64 time=5.69 ms
64 bytes from 192.168.178.31: icmp_seq=30 ttl=64 time=1.84 ms
--- 192.168.178.31 ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29018ms
rtt min/avg/max/mdev = 1.266/6.124/33.547/9.288 ms
Ergänzung ()
So, ist das gerade ein anderer Zufall. Befehl wird via ssh ausgeführt, aber eigentlich betirfft das die Internetverbindung:
Code:
Warnung: Fehlschlag beim Holen von http://download.opensuse.org/repositories/graphics:/darktable/xUbuntu_26.04/InRelease Temporärer Fehlschlag beim Auflösen von »download.opensuse.org«
Aber:
Code:
ping -c2 download.opensuse.org
PING download.opensuse.org (2a07:de40:b250:131:10:151:131:30) 56 data bytes
64 bytes from 2a07:de40:b250:131:10:151:131:30: icmp_seq=1 ttl=57 time=17.0 ms
64 bytes from 2a07:de40:b250:131:10:151:131:30: icmp_seq=2 ttl=57 time=16.8 ms
--- download.opensuse.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1002ms
rtt min/avg/max/mdev = 16.824/16.923/17.022/0.099 ms
Also DNS sollte bei mir funktionieren. Ist jetzt gerade der entfernte Server down?
Jetzt lief es vom OBS durch:
Code:
apt install darktable
Ich mache alles via ssh zum anderen PC, aber das sollte dafür doch egal sein.
Gute Frage- Ich wollte einen Zyxel managed switch unkonfiguriert verwenden, da hat eine Verbindung gar nicht funktioniert. Mit einem unmanaged Switch von Netgear danach auch nicht gleich, aber dann am nächsten Tag.
genau DA würde ich ansetzen, da scheint die Ursache zu liegen!
grundsätzlich ist ein "out of the box" consumer switch wie die Zyxel auch nur ein "ganz normaler" Switch, der "vielleicht noch ein paar Sicherheits-Checks macht".
wenn es mit dem nicht geht, dann ist nicht die richtige Vorgehensweise: so lange suchen, bis man einen Switch gefunden hat, der dumm genug ist "ein bisschen" zu funktionieren, sondern eben die eigentliche Ursache finden.
dabei hilft es, soviel wie mögliche Unbekannte ausklammern. WLAN raus, wenn man z.B. wegen DHCP drauf angewiesen ist, erstmal nur den Router und einen Rechner, Switch dazu, zweiter Rechner, AP und WLAN ohne Clients, dann die Clients usw. usf. und Imme gucken, was
Ergänzung ()
eine Sache ist mir gerade noch eingefallen: beide Rechner verwenden denselben NTP (Zeit) Server und das funktioniert auch?
Zur Zeit verwende ich einen alten unmanaged Netgear-Switch im Metallgehäuse.
Es liegen ein paar Zyxel GS1900-8H herum. Werkseinstellung und neueste Firmware. Die funktionieren auch grundsätzlich Nur gerade die Verbindung zum 2. "Hauptrouter" war tot. Ich kann mir gut vorstellen, dass der Zyxel auch am nächsten Tag funktioniert hätte. Ich hatte bis zum nächsten Tag nichts probiert oder umkonfiguriert.
Zum Verständnis, die Fritzbox 7630 ist DSL-Modem und den Rest habe ich ihr weggenommen. Die FB ist nur der Internetzugang. DHCP läuft auf einem Asus TUF-AX6000 mit OpenWrt 25.12.5
Der .31, der zeitweise eben keine ssh-Verbindung schafft, hängt am Switch. Der Switch verbindet sich zur Fritzbox, zum AX6000 und zu einem weiteren openwrt-Router Zyxel WSM20.
Der AX6000 ist "Hauptrouter" und stellt per WDS wireless eine Verbindung zu verschiedenen APs her, zB wieder ein (anderer) Zyxel WSM20 an dem via Ethernetkanel der .41 hängt. Die WDS-Verbindung läuft über 2.4GHz, ist auch bei den dicken Wändern nicht anders möglich.
Nachdem die Zyxel GS1900-8H rumliegen, dachte ich mir, ich verwende 1 davon unmanaged.
Alle openwrt-Router haben iperf installiert, falls da wer was testen will.
Zur Zeit funktioniert alles völlig problemlos. Da ist Fehlersuche schwierig.
Packet-Loss sieht anders aus, check mal die Logs vom dem Hobel wo der ssh-server läuft (dmesg && journal-ctl).
Und wenn das Problem auftritt kann man auch mal Teile vom dem ganzen Gelumpe isolieren (ETH-Stecker ziehen)
Ich schreibe ja, zur Zeit schwierig da was zu entdecken. Mein Bauchgefühl meint irgendein arp-Problem oder irgendwas mit ssh und Kommunikation mit alter / neuer Typ. Ich verwende jetzt ed25519
Ich stelle jetzt bald von 24.04 auf 26.04 um, muss mir aber eine neue Partitionierung überlegen.
Mal ne Frage!
Warum eigentlich SSH-Keys im eiegenen LAN?
Willst du das syncen nur automatisieren, sprich keine Passwörter mehr eingeben müssen?
Oder traust du deinem eigenen LAN nicht?
Ich frage mich, ob irgendwas externes stören könnte.
Läuft die Mikrowelle im Nachbarraum, ist Internet fast unbrauchbar. Zum einen lief die Mikrowelle nicht und zum anderen war surfen völlig problemlos. Was mir aber auffiel, seit einiger Zeit "spinnt" die BT-Tastatur, Fallweise mehrere Meldungen pro Sekunde "verbunden / getrennt". Ich habe vorübergehend auf Kabeltastatur umgestellt, damit langsames Tippen in der Konsole nicht ein BT-Problem lst.
