UPDATE1: Többetek szerint a túloldalt valamilyen módon blokkolva lehetünk, úgyhogy megpróbálok beszélni velük. Köszönöm mindenkinek a segítséget!
UPDATE2: Végre sikerült beszélni a "céggel", és az ip-t véletlenül blokkolták.
Belefutottam egy érdekes hibába. Adott egy iroda, amiben lokálisan van egy Debian 12-es szerver. Ez osztogatja az ipke-t a helyi hálón és a wifire csatlakozó Widows-os gépeknek, és raspberry pi-knek (ezek más hálón vannak).
Egyik partnerünk adott egy sftp-s hozzáférést a szerverükhöz, amire nem tudok csatlakozni (minden más partnerére, és a mi szervereinkre igen) egy Windows 11-es notival. Ha lecsatlakozok a helyi hálóról, és mobillal adok netet, akkor simán tudok csatlakozni. Ha a szerveren közvetlenül adom ki az ssh -vvvvA user@x.y.z.w -p 8822 -re, akkor az alábbiakat kapom:
OpenSSH_9.2p1 Debian-2+deb12u3, 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 *
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/user/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/user/.ssh/known_hosts2'
debug3: ssh_connect_direct: entering
debug1: Connecting to x.y.z.w [x.y.z.w] port 8822.
debug3: set_sock_tos: set socket 3 IP_TOS 0x10
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.2p1 Debian-2+deb12u3
kex_exchange_identification: Connection closed by remote host
Connection closed by x.y.z.w port 8822Vagyis kex_echange_identification problémája van. És bár a szerveren az ssh szerver configban vannak korlátozások erre vonatkozóan, de ott se a kliens oldali részben, amúgy meg a hálózaton levő összes Windows-os gépről sem lehet oda sftp-vel csatlakozni. A szerveren amúgy van nftables és fail2ban, de az nbftables loggolásakor sem látok olyat, hogy valamilyen forgalmat blokkolna.
Van bárkinek ötlete, hogy ez mitől lehet? :)
Hozzászólások
Ha jól látom, a kapcsolat létrejön, de nem találja a kulcsot a kliens, így nem küld semmit a szervernek, ezért key exchange hiányában a szerver bontja a kapcsolatot. De ez nem jelent semmit, hisz lokálban futtatod.
Ehhez a szervert kéne debug és verbose módban indítani, és ott nézni, mi a különbség az üzenetekben. Lehet, hogy alapból olyan címmel mész a szerverre, ami le van tiltva, és az ssh meg sem kapja a kérést? Mobilnet esetén nyilván más lesz a forráscím. Esetleg még a helyi géped routing tábláját nézd meg, lehet rosszul van route-olva az a célcím (talán "netsh route" windows-on, ha jól emlékszem).
Szóval:
1. kimegy-e a gépedről a kérés? (kliens oldali tűzfalgond esetleg, vagy routing)
2. eljut-e a szerverig? (netsh trace talán? Rég használtam netsh-t, bocs)
3. szerveren látod-e megérkezni a nyers kapcsolatot? (iptraf, ha nem, akkor biztos routing baj)
4. szerveren futó sshd megkapja-e a kérést? (sshd log, ha nem, akkor szerver oldali tűzfalgond is lehet)
Ha ez mind oké, akkor nézelődhetsz az ssh konfig táján:
1. megtalálja-e a kliens a kulcsát és a szervert a knownhosts fájlban
2. sshd részletes logja miben tér el helyi hálózat ill. mobilnet kliens esetén.
Ezzel egy bajom van, hogy ezen iroda hálózatára csatlakozó összes Windowsos noti, vagy számítógépnél jelentkezik ez a probléma, így nem hiszem, hogy a windows-os kliensekkel lenne a gond. Egyébként az én linuxos notimmal is kipróbáltam ezen a hálózaton, és dettó ez a gond.
sshd.log-ot meg maximum a mi szerverünkön tudok nézni, ami biztosítja nekünk a netet, de a partner szervere ahova csatlakoznánk, ahhoz nyilván nem férek hozzá, így azon nem tudok logot nézni. Viszont a mi szerverünk ssh szerverén ugye ezek a hívások nem futnak be.
GO TO 3.
Pedig az kellene, nagyon úgy fest. Egyeztess velük, hogy egy adott időpontban próbálod, és közben beszélsz telefonon a rendszergazdájukkal, hogy ő mit lát akkor ott az ő logjukban.
https://hup.hu/node/172387
Nekem a szerver az ip route list -re a következőket írja ki:
Ebben én nem látok több 0.0.0.0-ás maszkot. Maga a tábla is jónak tűnik, mert a 192.68.88.0/24-es hálón vannak a Windows-os gépek, és a wifi-re csatlakozott eszközök, és a szerveren ehhez a 192.168.88.1 -es ipjű hálókártya van rendelve, a 192.168.99.0/24-es háló a raspberry pi-s háló, és a szerveren ehhez a 192.168.99.99-es hálókártya tartozik. Egyébként ezek a pi-k tftpboot-al állnak fel.
Ez miatt szerintem a route-metric-nek nincs relevenciája, mert a route tábla alapján megy az enp5s0f3-as hálókártyára, amire az internet van kötve. Vagy valamit félrenéztem?
Meg ha a metric-el lenne gond, akkor meg nem értem, hogy minden máshova fel tudok sftp-zni, kapcsolódni, csak erre az egy szerverre nem.
Két gép, mindkettő szerver mindkettőben több hálókártya (azokon internettel). Egyiken felépül a kapcsolat és -gondolom-, majd a másikon akart kommunikálni, erre volt ez a hibaüzenet.(valami ilyesmi volt a gond. De metric beállítás után minden jó lett.)
Ugyanezt a hibát kapod akkor is ha aktív a /etc/hosts.deny.
Igen, ezt néztem, de a hosts.deny alatt csak a default kikommentezett szövegek vannak.
nem a te gepeden... az ssh hoszton... :D kerdezd a tuloldali uzemeltetot.
megpróbálom, de a céget ismerve valszeg halott ügy lesz. Egyelőre áthidaltam egy másik szerverrel a problémát (helyileg máshol van), így legalább nem sürgős a dolog :)
Egyik partnerünk adott > akkor miert nem oket kerdezed mi a hiba?
ahogy latom natoltok az irodaban. nezd at kit/mit/merre/hogy.
ha lehet/kell tcpdumpolj a celhosztraa szurve.
Két okból nem kérdem őket. Ha jól tudom nincs informatikusuk helyben, csak időnként megy ki valaki :) A másik, hogy nem hiszem, hogy náluk va na gond, mivel csak a mi hálózatunk alatt jelentkezik ez a hiba. Máshol (otthoni hálózatomon, főnököm hálózatán szintén otthon, mobilnetről) gond nélkül csatlakozik.
TCPDump-hoz sajni nem értek. lekérni még le tudnám, de, hogy melyik csomag mit hogyan...
hinni a templomban kell.
nincs informatikusuk helyben > akkor menjen be ssh-n es nezze meg a logokat...
csak a mi hálózatunk alatt jelentkezik ez a hiba. > irtam mit nezz meg. ha meg bedobtak a (felteszem static) ipteket egy denylistbe, goto 10, kerdezd a tuloldali uzemeltetot.
TCPDump-hoz sajni nem értek. > akkor hajra, ideje elkezdeni ha halozatot uzemeltetsz.
es nezd meg nem-e MTU gond, ssh-nal jellemzoen random hibakat tud okozni. :)
Köszi, de a deny list sem valószínű, hisz amit bevágtam logot, az alapján azt mutatja, hogy a kapcsolat létrejött:
MTU-nak utánanézek.
a denylist akkor ellenozrodik, ha letrejott a kapcsolat. be kell csatlakozz a tuloldali sshd-re, hogy aztan az eldontse "honnan gyutte', ki vo'na'" :)
Megpróbálok írni nekik, de abból kiindulva, hogy a cég kicsoda, gyanítom halott esett. Egyelőre beállítottam a kolléganőmnek egy külső szerverünket, amire tud távolizni, és így megy neki, aztán lehet hogy így marad.
Windows kliensemen meg akkor holnap megnézem a tcp csomagokat, hátha abból ki tudok valami hámozni. Bár lehet hogy inkább a debian-os notit fogom erre használni, mert a win-es gépemen jóval nagyobb a forgalom, így arra a pár másodpercre is lenne pár ezres sor a logban.
mint mondottam szurj a target IP-re :)
es, mint javasoltam, en azon a gepen csinalnam, ami natol a halozatodon.
jaes hint (man sshd_config):
ezzel lehet mindenfele modon innen-onnan, ezert-azert ezt-meg-azt kondicionalisan rahuzni, pl. source IP-re is :)
Ami nálunk NAT-ol, az a szerver, ami kap netet is és továbbítja a 192.168.88.0-ás és 192.168.99.0-ás hálózatra. Ennek az sshd_config-jában van pár restrict, de egyik sem ip-re, max a Kex, hostkey, Ciphers és MAC-re van beállítva, hogy mely típusokat fogadja el, de ezeket már kikommenteztem, de sajnos úgy sem jó.
Amúgy a mi szerverünk sshd_configjában ez van (ami előtt nincs komment jel):
irrelevans nalad mi van az sshd konfban, azert irtam, h ertsd, csomo modja van eldobni egy ssh kapcsolatot. tobbek kozt ip alapon, vagy akar user/ip kombinaciok alapjan, stb.
"gyanítom halott esett. " > akkor mit foglalkozol a dologgal? ha nekik nem fontos, szarj bele. jelezd, hogy nem megy az irodabol, nezzek/oldjak meg. naluk van a szolgaltatas. routing hibat mar kizartad, ezzel is elorebb vannak :)
Ezt értem és tudom, hisz én is szabályozom a szervereinken, hogy mely típusú hitelesítéseket fogadjon el, de nem feltételezhetem első körben, hogy a túloldalt szar, hanem először meg akarok bizonyosodni, hogy nálunk minden rendben, mert nem akarok nekik szólni, hogy valamit elkűrtak, aztán kiderül, hogy mégse.
Akkor a win-es notin wireshark, ablakos, kattintgatós, pofonegyszerű használni. Ha a kéréseidre érkezik bármiféle válaszcsomag, azt látnod kell a kliens gépen. Ha meg nem jön semmi válasz (syn+ack vagy close se), akkor egyértelműen náluk van a szerver elkefélve (tűzfal vagy routing).
vagy sajat maguknal, de a lenyeg ugyanaz. :)
Igen. Ahhoz, hogy a náluk lévő kimenő router hibát biztos kizárjuk, tudni kéne, hogy megérkezik-e az ügyfél szerverére a csomag. A "netsh trace" meg tudja szerintem ezt mondani, hacsak nincs letiltva az ICMP is.
Én sem értek hozzá, de keresni tudsz te is. How to capture and analyze traffic with tcpdump | TechTarget .
Nem a tcpdump, vagy wireshark stb használatával van a gond, az megy, hanem a tcp csomagok megértése a probléma. Ahhoz igen magas TCP működésének ismerete kellene, azt youtube-ról nem szedi össze az ember, meg egy-két pdf-ből.
Nem feltétlenül, elég annyit tudnod, hogy amikor megszólítod a szervert, akkor látnod kell egy olyan TCP csomagot, aminek a forrása a te ip-d, a célja a szerver ip-je, és a fejlécben a SYN flag be van billentve. (Az ilyen szűrőkre millió példát találsz, csak copy'n'paste és ip átír.)
Ha erre érkezik egy olyan csomag, aminek a forrása a szerveré, a célja a te ip-d, és a fejlécében mind a SYN, mind az ACK be van billentve, akkor nem routing probléma (és nagy valószínűséggel nem is szerver oldali tűzfal, hanem szerver oldali sshd konfig gond). Ha nem jön semmiféle válasz 2 percen belül, akkor tudhatod, hogy náluk van a baj, méghozzá routing vagy tűzfal.
Ezt ismételd mobilnetes címmel is (ahol megy), meg helyi címmel is (ami meg nem) és látni fogod a különbséget.
tcpdump csak ennyit látok, mikor csatlakozni szeretnék:
Ebből az abc.host.hu a mi szerverünk és a hablaty.fixip.t-online.hu az övéké :D
Ezzel szerintem nem mész semmire, azt eddig is tudtuk, hogy szerveretek és az ő szerverük között nincs routing gond. (Az eredeti posztodban a "debug1: Connection established." alapján)
Ugyanez a notidon kéne, wireshark-al. Egyébként jó úton jársz, Az első csomag a SYN ("[S]"), látszik, hogy tőletek megy hozzájuk, majd erre jön a második csomag, tőlük hozzátok (SYN+ACK "[S.]"), szóval itt nincs routing probléma. Ha a notidon is látsz hasonló válasz csomagokat, akkor a routing problémát egyszer és mindenkorra kizárhatjuk, marad a szerver oldali tűzfal (ha nem SYN+ACK jön elsőnek vissza, hanem bármi más), illetve az sshd félrekonfigurálás. Ha semmi nem jön, akkor az lehet routing és tűzfal probléma is, de valószínűleg nem sshd konfig.
ugyanez volt a notin is, és a windows-os gép wsl-jében is.
A handshake rendben van, (S/S./.) a P(USH)-ra viszont F(IN)+R(ESET) jön, úgyhogy ez mindenképp a túloldalon alkalmazás szinten van elkaszálva úgy, hogy a sftp-n küldött első csomagot sem válaszolja meg protokollon belül, hanem helyből elutasítja a kapcsolatot. (Ha túloldali tűzfal lenne, akkor a syn-re vagy nem jönne válasz (azaz syn, syn, syn, timeout), vagy reset érkezne, esetleg egy *prohibited icmp válasz)
EZt mondtam, és erről beszéltek páran. Ezért mondtam, hogy egyelőre elengedem ezt a problémát, mert a megoldást áthidaltam mással, így a kolléganő fog tudni csatlakozni, és fileokat feltölteni. A céggel legalábbis ami van kapcsolattartónk annak jelzem a gondot, és hogy továbbítsák az ottani IT-snak. A céget ismerve ez hetek lesznek, de legalább máshogy meg tudtam oldani, addig lehet azt használni.
Ez "az SFTP kapcsolatot kaptam", ez tartalmaz egy leírást, hogy hova,milyen módon kell csatlakozni?
Például SSH kulcs, vagy jelszóval kell, mert erről nincs információ a topik nyitóban.
Debian esetében nincs meg a privát kulcs a csatlakozáshoz az alapértelmezett helyeken (jelszót nem kért a log alapján, feltételezem tiltva van).
Ha van privát kulcs a kapcsolathoz, akkor a "-i út/a/kulcsfájlhoz" opcióval kell megpróbálni csatlakozni. Én ezt gondolom első körben hibának, mert a kapcsolat kiépül.
A Windows-os gépeken vagy szintén a kulcs hiányzik vagy a tűzfal viccelhet meg. Nemrég kerestek meg azzal, hogy egy program nem tud csatlakozni valahová. Néztem a Windows tűzfalat, ott ki van engedve, máshonnan minden megy. Kis idő múlva rájöttem, hogy itt valami nem stimmel és a Windows tűzfalból töröltem az érintett szabályokat, majd a program újraindulása után a tűzfal ablak felugrott, ott engedélyeztem a kapcsolatot és ment rendesen.
Windows alól milyen programmal próbálsz csatlakozni?
Nincs kulcs. Simán jelszóval kell. Tűzfal a klienseken ki van kapcsolva, mert a Bitdefender működik helyette. Minden más partnerhez, saját szervereinkhez rendben megy a kapcsolat. Amúgy linuxos kliensről sem megy, amin még csak tűzfal sem megy (kipróbáltam egy friss konténerrel is...)
kontener szinten irrelevans, az a dokkerhoston keresztul natolodik (by default).
Lehet hülyeség, de te ssh paranncsal teszteltnél sftp kapcsolatot.
Kipróbálnád Linuxon sftp paranccsal?
https://linuxize.com/post/how-to-use-linux-sftp-command-to-transfer-fil…
Windows-on egy Total Commanderben SFTP pluginnel?
Windows-on putty, de mivel sftp-ről van szó, winscp-t javaslok - ezek kattogtatósok. Bár ugye egy ideje van már nekik ssh és sftp parancssorból is :-) Natívan is, meg WSL-en keresztül is ;-)
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?
A WinSCP jó ötlet ha nincs fent a TC akkor egyszerűbb is valóban.
A WSL-lel nem tudom mennyire zavartam volna össze a kérdezőt, illetve mennyire érte volna meg egy felrakatnom egy komplett WSL-t egy sftp teszt parancs miatt, ezért nem írtam azt egyből. Ettől függetlenül természetesen ez is járható út Windows-on.
Köszönöm szépen a kiegészítést!
Értelemszerűen az volt az első, hogy TC-n majd WinSCP-n próbáltam, hisz azt feltételeztem, hogy minden facca. Amúgy meg ssh-n is megy, legalábbis míg felvenné a known_hostba a gépet, ha mobilneten van, szal ellenőrzésnek jó az ssh.
De amúgy próbáltam Debian. Windows 11, és Windows 11 WSL-es debian alatt is. Ugyaaz a jelenség. Épp ezért gondoltam hogy ide írok, mert ez nagyon nem szokványos hibajelenség. Egyre inkább hajlok arra, hogy annál a cégnél van a mi ip-nk valamiért szűrve, bár el nem tudom képzelni hogy miért.
Az a helyzet, hogy mindenhol csak magyarázkodsz, de nem kapunk túl sok infót, logot. Lehet, hogy te látod a dolgokat, de én nem. Így csak találgatni lehet, üveggömbből jósolni, amivel nem leszel előrébb.
Lássunk pár konkrét parancsot, amit le kéne futtatni a Debianon és WSL alatt is. A kimeneteket pedig tedd be ide.
Tűzfal ellenőrzés:
nmap -Pn -p 8822 <távoli szerver címe>
SSH-t nézzük részletesebben, mert nem kér jelszót sem.
ssh -o PubkeyAuthentication=no -o PreferredAuthentications=password -vvv -p 8822 user@<távoli szerver címe>
BitDefender nem tiltja valahol a portot kimenő irányban? Itt is jó lenne látni egy logot a kapcsolódásról.
1. Nem magyarázkodom
2. Ezt is veheted magyarázkodásnak, de a bitdefender sem játszik, mert csak Win klienseken van, linuxos gépen nincs és ott is gond van, ráadásul mint írtam a legelső posztban, más hálón nincsen gond, tehát ha a Bitdefenderrel lenne a gond a kliensen, akkor más hálón sem menne. Amúgy meg tudom mi szerepel a Bitdefender configjában, mert a felettesemmel együtt csináltuk
3. Tűzfalat természetesen próbáltam, de ugyanaz a tűzfalbeállítás van egy másik szerveren is, és onnan megy, tehát már csak ez miatt sem játszik a dolog. Ráadásul bár te azt állítod hogy semmilyen logot nem adtam, azért valahogy a tcpdump logjából is látható, és az ssh és sftdebug logjéból is látható, hogy a kapcsolat létrejön.
4. már pár ember megírta a logok alapján, hogy úgy néz ki a túloldalon ennek az irodának a külső ipje, vagy hostja tiltva van. Hétfőn megpróbálok a kapcsolattartónkón keresztül beszálni az IT-ssal.
" úgy néz ki a túloldalon ennek az irodának a külső ipje, vagy hostja tiltva van. "
Méghozzá protokoll szinten, ha minden igaz, mert tcp-n azért beszélgetnek, de magasabb szinten már nem.
A puttyban ne SSH protokollt válassz, hanem TELNET-et (a port maradjon ugyanaz!), és nézd meg, hogy mit kapsz. Vagy Linux alól is tesztelhetsz, ott van sima telnet, azzal rácsatlakozol a szerver portjára (telnet ip port).
Elvileg egy SSH kezdetű bannernek kéne jönnie. A debug logodban nem látszik ez a banner, gyanús, hogy a kliens el sem jut odáig, hogy a szerver megszólaljon. Szerintem az történik, hogy a kapcsolat megnyílik, majd a szerver bármiféle kommunikáció nélkül be is csukja a kapcsolatot.
Szolgaltatoi oldalon (vagy valahol utkozben) nincs szures a 8822-es portra? Ha van a halozaton elerheto geped, annak a megadott portjara tudsz csatlakozni?
Nincs valami "tul okos" security eszkozotok, ami vagy szuri, vagy a titkositott kapcsolatokat probalja valami hackkel figyelni (https-en pl. kamu alairt tanusitvanyokat szoktak hasznalni), aminek nem tetszik a csatlakozas, es bontja?
A strange game. The only winning move is not to play. How about a nice game of chess?
Hétfőn írok az Invitech-nek, de kétlem. Legalábbis a tanusítvány figyelését, mert minden más cég megy. 8822-es portra nem tennék mérget, de majd írok a műszakisoknak. A tapasztalat szerint az lesz vagy röpke 4-5 nap :D
Szia!
Szerintem ez valamilyen MTU/PMTU probléma lesz.
Még ezeknek a beállításoknak nézz utána a te oldaladon ami a NAT -t csinálja.
Ezt kipróbálom majd (pmtu-s sysctl.conf beállítást), de az iptables-t nem fogom tudni, mert azona szerveren csak nftables van.
Debian 12-ben kikerült az egyik rsa kulcscsere a támogatottak közül. Sajnos arra nem emlékszem, melyik. Belefutottam én is pár hónapja, serveroldalon kellett visszatenni a sshd.conf file-ba. Ez gyanúsan hasonlít hozzá.
Ha a szerver oldalon kikerült, akkor kliens oldalon illene utánamenni, de mivel ugyanaz a kliens az ehyik network felől működik, a másik felől meg nem, így én nem erre indulnék el.
A kliensen mindenképp parancssori sftp és sok "-v"-vel meg lehet nézni, hogy a szerver milyen kekszet :-) javasol, és a klienssel miért nem tudnak megállapodni :-)
A logika ezt diktálná, de nem. Mint ahogy sz ssh-nál is bevágtam ide, hogy mi zajlik, beteszem ide neked az sftp kimenetét is, de nyilván pontosan ugyanaz.
Akkor ide is beírom: a logod szerint a szerver meg sem szólal. Ugyan a kliens kex_exchange-ről beszél, de valójában ez el sem kezdődik, mert a szervertől nem jön meg az első üzenet (sem).
Ez alapján az a tippem, hogy ez nem ssh-szintű probléma lesz, hanem routing, tűzfal, /etc/hosts.{allow,deny}, vagy valami hasonló.
Ott a pont - a kérdés az, hogy tcp-szinten összeáll-e a kapcsolat (ehhez kéne tcpdump/wireshark), vagy sem, ha nem, akkor hol akad el, ha igen, akkor miért nem válaszol _érdemben_ a túloldal.
Ez már megtörtént. Lapozz feljebb, és ott a tcpdump log. Érdemben kvázi semmi nem látható benne, csak hogy létrejön a kapcsolat.
Egyre inkább erre gondolok én is, csak fura, mert még nem volt dolgunk velük, miért lennénk tiltva, dehát kár ezen logikáznom. Hétfőn a kapcsolattartónkon keresztül megpróbálok az IT-ssal beszélni. Addig csináltam egy alternatív megoldást, azzal fog működni.
Emlékeim szerint az ssh-rsa került ki. Rá tudnám erre fogni, viszont akkor azt nem tudom megmagyarázni, hogy más egyéb helyi hálozaton meg gond nélkül lehet csatlakozni ugyanazon Debian 12-es notin.
No, akkor szépen, módszeresen kezdj hozzá a hibahely megkereséséhez. Mivel hálózati forgalom akad el valahol, így nem úszod meg, hogy a hálózati forgalmat valamilyen módon lementsd és elemezd.
Mivel Debian 12-ről beszélsz, hogy onnan sem megy, így adja magát, hogy első körben ott egy jól irányzott tcpdump-ot kellene csinálni, és megnézni, hogy a tcp-kapcsolat felépül-e. Ha nem, akkor megnézni, hogy hol akad el. Ezt meg lehet fejelni egy tcptraceroute -tal is, de lehet rajzolni is, hogy a notebook és a külső partner gépe között milyen ismert eszközök vannak, és azoknak a beállításait is megnézni.
Tapasztalatok alapján már most több időt feccölt bele a közösség (meg te) ebbe a topicba, mint amennyi a probléma megtalálásához kellene.
Ezt megtettem, és kétszer is be van vágva a tartalma. Láthatólag ahogy felvette a kapcsolatot el is dobja. Már 1-2 ember jelezte, hogy szerinte a mi ip-nk, vagy hostunk tiltva lehet náluk. Hétfőn a kapcsolattartónkon keresztül megpróbálok az IT-ssal beszélni. Addig csináltam egy alternatív megoldást, azzal fog működni.
Mondjuk a sok `type -1` hibán lehetne gondolkozni: nincs ilyen fájl, nem jó az owner, nem jók a jogok, egyéb.
Azok csak a default keresett kulcs pathok, semmi baj vele.
PubkeyAcceptedKeyTypes