[MEGOLDVA] sftp-zés-kor hibaüzenet: kex_exchange_identification: Connection closed by remote host

Fórumok

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 8822

Vagyis 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

Szerkesztve: 2024. 08. 09., p – 16:01

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.

Ha lecsatlakozok a helyi hálóról, és mobillal adok netet, akkor simán tudok csatlakozni.

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.

nem hiszem, hogy a windows-os kliensekkel lenne a gond

GO TO 3.

a partner szervere ahova csatlakoznánk, ahhoz nyilván nem férek hozzá, így azon nem tudok logot nézni.

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.

Nekem a szerver az ip route list -re a következőket írja ki:
 

default via a.b.c.d dev enp5s0f3 onlink
192.168.88.0/24 dev enp5s0f1 proto kernel scope link src 192.168.88.1
192.168.99.0/24 dev enp5s0f0 proto kernel scope link src 192.168.99.99
a.b.c.d/30 dev enp5s0f3 proto kernel scope link src a.b.c.d

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.

cat /etc/hosts.allow
sshd:10.0.0.0/8

cat /etc/hosts.deny
sshd: ALL

Igen, ezt néztem, de a hosts.deny alatt csak a default kikommentezett szövegek vannak.

 

╰─$ cat /etc/hosts.deny
# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
#                  See the manual pages hosts_access(5) and hosts_options(5).
#
# Example:    ALL: some.host.name, .some.domain
#             ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID
Szerkesztve: 2024. 08. 09., p – 16:22

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:
 

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.

MTU-nak utánanézek.

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):

       Match   Introduces a conditional block.  If all of the criteria
               on the Match line are satisfied, the keywords on the
               following lines override those set in the global section
               of the config file, until either another Match line or
               the end of the file.  If a keyword appears in multiple
               Match blocks that are satisfied, only the first instance
               of the keyword is applied.

               The arguments to Match are one or more criteria-pattern
               pairs or the single token All which matches all criteria.
               The available criteria are User, Group, Host,
               LocalAddress, LocalPort, RDomain, and Address (with
               RDomain representing the rdomain(4) on which the
               connection was received).

               The match patterns may consist of single entries or
               comma-separated lists and may use the wildcard and
               negation operators described in the “PATTERNS” section of
               ssh_config(5).

               The patterns in an Address criteria may additionally
               contain addresses to match in CIDR address/masklen
               format, such as 192.0.2.0/24 or 2001:db8::/32.  Note that
               the mask length provided must be consistent with the
               address - it is an error to specify a mask length that is
               too long for the address or one with bits set in this
               host portion of the address.  For example, 192.0.2.0/33
               and 192.0.2.0/8, respectively.

               Only a subset of keywords may be used on the lines
               following a Match keyword.  Available keywords are
               AcceptEnv, AllowAgentForwarding, AllowGroups,
               AllowStreamLocalForwarding, AllowTcpForwarding,
               AllowUsers, AuthenticationMethods, AuthorizedKeysCommand,
               AuthorizedKeysCommandUser, AuthorizedKeysFile,
               AuthorizedPrincipalsCommand,
               AuthorizedPrincipalsCommandUser,
               AuthorizedPrincipalsFile, Banner, CASignatureAlgorithms,
               ChannelTimeout, ChrootDirectory, ClientAliveCountMax,
               ClientAliveInterval, DenyGroups, DenyUsers,
               DisableForwarding, ExposeAuthInfo, ForceCommand,
               GatewayPorts, GSSAPIAuthentication,
               HostbasedAcceptedAlgorithms, HostbasedAuthentication,
               HostbasedUsesNameFromPacketOnly, IgnoreRhosts, Include,
               IPQoS, KbdInteractiveAuthentication,
               KerberosAuthentication, LogLevel, MaxAuthTries,
               MaxSessions, PasswordAuthentication,
               PermitEmptyPasswords, PermitListen, PermitOpen,
               PermitRootLogin, PermitTTY, PermitTunnel, PermitUserRC,
               PubkeyAcceptedAlgorithms, PubkeyAuthentication,
               PubkeyAuthOptions, RekeyLimit, RevokedKeys, RDomain,
               SetEnv, StreamLocalBindMask, StreamLocalBindUnlink,
               TrustedUserCAKeys, UnusedConnectionTimeout,
               X11DisplayOffset, X11Forwarding and X11UseLocalhost.

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):

 

PermitRootLogin without-password
PubkeyAuthentication yes
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem	sftp	/usr/lib/openssh/sftp-server
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
Ciphers chacha20-poly1305@openssh.com,aes256-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

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.

TCPDump-hoz sajni nem értek.

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).

tcp csomagok megértése a probléma

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

sudo tcpdump -v -i any host a.b.c.d
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
17:02:50.996393 enp5s0f3 Out IP (tos 0x10, ttl 64, id 55446, offset 0, flags [DF], proto TCP (6), length 60)
    abc.host.hu.54770 > hablaty.fixip.t-online.hu.8822: Flags [S], cksum 0x9a55 (incorrect -> 0xd502), seq 1740129444, win 64240, options [mss 1460,sackOK,TS val 2576916359 ecr 0,nop,wscale 7], length 0
17:02:50.998977 enp5s0f3 In  IP (tos 0x0, ttl 122, id 16068, offset 0, flags [DF], proto TCP (6), length 60)
    hablaty.fixip.t-online.hu.8822 > abc.host.hu.54770: Flags [S.], cksum 0x2120 (correct), seq 1744668184, ack 1740129445, win 65535, options [mss 1380,nop,wscale 3,sackOK,TS val 3806912023 ecr 2576916359], length 0
17:02:50.999014 enp5s0f3 Out IP (tos 0x10, ttl 64, id 55447, offset 0, flags [DF], proto TCP (6), length 52)
    abc.host.hu.54770 > hablaty.fixip.t-online.hu.8822: Flags [.], cksum 0x9a4d (incorrect -> 0x4d9f), ack 1, win 502, options [nop,nop,TS val 2576916362 ecr 3806912023], length 0
17:02:50.999398 enp5s0f3 Out IP (tos 0x10, ttl 64, id 55448, offset 0, flags [DF], proto TCP (6), length 92)
    abc.host.hu.54770 > hablaty.fixip.t-online.hu.8822: Flags [P.], cksum 0x9a75 (incorrect -> 0xe89d), seq 1:41, ack 1, win 502, options [nop,nop,TS val 2576916362 ecr 3806912023], length 40
17:02:51.002076 enp5s0f3 In  IP (tos 0x0, ttl 122, id 16069, offset 0, flags [DF], proto TCP (6), length 52)
    hablaty.fixip.t-online.hu.8822 > abc.host.hu.54770: Flags [F.], cksum 0xcf90 (correct), seq 1, ack 1, win 32768, options [nop,nop,TS val 3806912026 ecr 2576916362], length 0
17:02:51.002076 enp5s0f3 In  IP (tos 0x0, ttl 122, id 16070, offset 0, flags [DF], proto TCP (6), length 40)
    hablaty.fixip.t-online.hu.8822 > abc.host.hu.54770: Flags [R.], cksum 0x82a3 (correct), seq 2, ack 41, win 0, length 0
^C
6 packets captured
7 packets received by filter
0 packets dropped by kernel

Ebből az abc.host.hu a mi szerverünk és a hablaty.fixip.t-online.hu az övéké

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.

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...)

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.

Szerkesztve: 2024. 08. 09., p – 23:38

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?

Szerkesztve: 2024. 08. 10., szo – 14:14

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.
 

/etc/sysctl.conf
net.ipv4.ip_no_pmtu_disc = 1


/etc/iptables/rules.v4
-t filter -A INPUT -p icmp --icmp-type 3/4 -j ACCEPT
-t filter -A INPUT --fragment -j ACCEPT
-t nat -A POSTROUTING -o enp5s0f3 -p tcp -m tcp --sport:1-65535 -j TCPMSS --clamp-mss-to-pmtu

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.

 

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 *
debug1: Connecting to host.hu [x.y.z.w] port 8822.
debug1: Connection established.
debug1: identity file /home/nio/.ssh/id_rsa type -1
debug1: identity file /home/nio/.ssh/id_rsa-cert type -1
debug1: identity file /home/nio/.ssh/id_ecdsa type -1
debug1: identity file /home/nio/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/nio/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/nio/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/nio/.ssh/id_ed25519 type -1
debug1: identity file /home/nio/.ssh/id_ed25519-cert type -1
debug1: identity file /home/nio/.ssh/id_ed25519_sk type -1
debug1: identity file /home/nio/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/nio/.ssh/id_xmss type -1
debug1: identity file /home/nio/.ssh/id_xmss-cert type -1
debug1: identity file /home/nio/.ssh/id_dsa type -1
debug1: identity file /home/nio/.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 8822

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ó.

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.