Acces la distanță cu sursă deschisă folosind VNC și Reverse SSH (Administrarea sistemului, Ssh, Tunel Ssh, Vnc, Tightvnc)

Senrabdet a intrebat.
a intrebat.

Încerc să obțin o abordare de acces de la distanță (sursă deschisă) care să funcționeze implicând openssh și tightvnc care se ocupă de NAT, care permite cuiva să se îndepărteze la serverul meu și apoi îmi permite să vnc înapoi la mașina lor fără a trebui să se încurce cu firewall-ul lor și îmi permite să folosesc o adresă WAN statică pe drum. Am încercat să fac acest lucru în pași mici pentru a gestiona necunoscutele (pentru mine, multe:). S-ar părea că alții au reușit să facă acest lucru să funcționeze, dar sunt nedumerit.

Pentru început, am reușit să fac să funcționeze ssh inversat fără parolă între două mașini virtuale Windows 10 (hyperv) pe laptop (adică nu încerc să mă ocup de redirecționarea porturilor pe firewall-ul meu sau de adresa WAN statică încă), dar nu pot face ca vcn să funcționeze prin tunelul ssh inversat, deși funcționează doar folosind adresa IP lan în loc de „localhost” pentru ssh inversat.

Mă întreb dacă abordarea mea generală este greșită sau nu. Așa este:

Mașina A/Persoana A (dorește ajutor)
în prezent o VM win10
client ssh (nativ pe win10)
server tightvnc

Mașina B/Persoana B (rol de help desk)
în prezent vm win10 (aceeași rețea locală ca și mașina A în prezent)
server ssh (supliment opțional pe win10)
client tightvnc

Ideea ar fi ca persoana A de pe mașina A să pornească serverul VNC de pe mașina A și să se conecteze prin ssh inversat la mașina B (până acum totul este în regulă). În acel moment, persoana B de pe mașina B ar putea să facă VNC înapoi la mașina A și să ajute.

Presupunerea mea, care ar putea fi problema, este de a folosi reverse ssh de la A->B (am încercat și opțiunea -L în loc de -R), iar apoi să folosesc tightvnc pentru a accesa mașina A înapoi de la B. După ce am pornit serverul vnc pe mașina A, un exemplu de comandă ssh inițială pe care am reușit să o fac să funcționeze de la A la B este:
ssh -R 5902:localhost:5901 [email protected] -i ~/.ssh/id_rsa -vvv

Această parte funcționează. Serverul vnc de pe A are portul 5902 (am activat și dezactivat loopback-ul, am încercat serverul de ascultare). Sper că este ceva de genul că sunt confuz cu privire la care este gazda locală sau ceva de genul ăsta.

Eroarea pe care o primesc pe mașina B încercând să fac vnc înapoi la mașina A prin tunelul ssh folosind „localhost::5902” este „conexiunea a fost închisă cu grație”. Conexiunea vnc funcționează dacă folosesc doar lanip-ul serverului vnc de pe A de pe B.

Nu există nimic în „tviewer.log” nici pe client, nici pe server. Am încercat să schimb unele setări în sshd_config (de exemplu, AllowAgentForwarding yes) fără niciun rezultat.

Q este proiectul meu defect sau funcțional? Este vorba de modul în care configurez lucrurile și poate fi abordat, eventual folosind o comandă ssh diferită?

Q am nevoie de server ssh pe ambele mașini (sper să evit acest lucru, deoarece înseamnă că trebuie să îl instalez pe mașinile altor persoane)?

Știu că există diverse opțiuni plătite și unele gratuite pentru toate acestea, dar sper să reușesc să o fac să meargă.

Vă mulțumesc.

2 răspunsuri
liverwust

Am întâlnit ceva similar la locul de muncă atunci când ne ocupăm de redirecționarea portului SSH pe Windows. Aruncați o privire la ieșirea din netstat, , care confirmă faptul că TightVNC ascultă pe portul 5901:

PS C:WINDOWSsystem32> netstat -an | findstr 5901
  TCP    0.0.0.0:5901         0.0.0.0:0              LISTENING
PS C:WINDOWSsystem32>

Contrastând acest lucru cu socketurile de ascultare pentru serviciul Remote Desktop încorporat (am exclus socketurile UDP, care nu au legătură cu această discuție):

PS C:WINDOWSsystem32> netstat -an | findstr 3389 | findstr /V UDP
  TCP    0.0.0.0:3389         0.0.0.0:0              LISTENING
  TCP    [::]:3389            [::]:0                 LISTENING
PS C:WINDOWSsystem32>

Serviciul TightVNC nu pare să implementeze socket-uri dual-stack (IPv4 + IPv6). Acest lucru este nefericit, deoarece rularea clientului SSH cu un singur -v va afișa următoarele mesaje atunci când TightVNC încearcă să se conecteze înapoi prin tunelul RemoteForward:

debug1: client_input_channel_open: ctype forwarded-tcpip rchan 3 win 2097152 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 5901, originator 127.0.0.1 port 50132
debug1: getsockopt TCP_NODELAY: Invalid argument
debug1: connect_next: host localhost ([::1]:5900) in progress, fd=7
debug1: channel 1: new [127.0.0.1]
debug1: confirm forwarded-tcpip
debug1: channel 1: connected to localhost port 5900
debug1: channel 1: free: 127.0.0.1, nchannels 2

Linia care contează este connect_next, , care arată că clientul OpenSSH încearcă IPv6 și doar IPv6 atunci când face proxy-ul conexiunii.

Nu am reușit să găsesc nicio opțiune în setările TightVNC pentru a lega IPv4+IPv6, dar nu contează, deoarece există o soluție simplă. În loc de aceasta:

ssh -R 5902:localhost:5901 [email protected] -i ~/.ssh/id_rsa -vv

încercați acest lucru:

 ssh -R 5902:127.0.0.1:5901 [email protected] -i ~/.ssh/id_rsa -vv

Pentru ca lucrurile să fie și mai confuze, este absolut în regulă să introduceți localhost::5902 în cadrul clientului TightVNC. Acest lucru se datorează faptului că ascultătorul OpenSSH de pe MachineB (portul 5902) este dual-stack:

PS C:WINDOWSsystem32> netstat -an | findstr 5902
  TCP    127.0.0.1:5902         0.0.0.0:0              LISTENING
  TCP    [::1]:5902             [::]:0                 LISTENING
PS C:WINDOWSsystem32>

UPDATE: După ce am recitit răspunsul dumneavoastră, aș dori să verific dacă suntem pe aceeași lungime de undă în ceea ce privește numerele de port. Comenzile din răspunsul meu presupun următoarele:

  • Mașina A -> Server TightVNC -> Portul serverului principal = port 5901
  • Mașina A -> client OpenSSH -> Specificație RemoteForward = -R 5902:127.0.0.1:5901
  • Mașina B -> TightVNC client -> Remote Host = localhost::5902

În special, cred că este posibil să fi rulat serverul TightVNC pe portul 5902, în ciuda nepotrivirii dintre acesta și specificația RemoteForward.

Comentarii

  • Wow, mulțumesc! Va trebui să digerăm sugestiile dvs., dar o vom face și vom reveni. Mulțumesc foarte mult pentru răspunsul atent. –  > Por Senrabdet.
  • Cred / sper că am încercat sugestia (apreciez foarte mult), dar cred că primesc același rezultat („conexiunea a fost închisă cu grație”). Adică, de la MașinaA am încercat: ssh -R 5902:127.0.0.1:5901 [email protected]ăMachineB -i ~/.ssh/id_rsa -v . SSH se conectează, dar VNC înapoi de la MașinaB obține aceeași eroare folosind atât „localhost::5902”, cât și „127.0.0.0.1::5902”. Eroare de utilizator din partea mea? Am văzut postări despre utilizarea unei a treia mașini la mijloc sau mă întreb dacă aș putea folosi Linux pentru MașinaA. Orice alte gânduri, inclusiv modul de diagnosticare, apreciate. Thx:) –  > Por Senrabdet.
  • Aruncați o privire la actualizarea mea, care încearcă să reconcilieze potențialele diferențe dintre specificațiile porturilor noastre. –  > Por liverwust.
  • O voi face, postați înapoi. Thx –  > Por Senrabdet.
  • @liverwust Vă mulțumesc. Nu mi-aș fi dat seama singur de asta. –  > Por Joyce Babu.
Stingray

Ați menționat că serverul VNC de pe „Mașina A” rulează pe portul 5902 și că încercați, de asemenea, să vă conectați la portul 5902 (localhost:5902) pe „Mașina B” pentru a ajunge la VNC-ul „Mașinii A”. Exemplul pe care l-ați dat:

ssh -R 5902:localhost:5901 [email protected] -i ~/.ssh/id_rsa -vv

Este greșit. Pentru ceea ce faci, ar trebui să folosești:

ssh -R 5902:localhost:5902 [email protected] -i ~/.ssh/id_rsa -vv

Primul parametru la -R este portul care va fi ascultat de sshd pe partea de la distanță (server SSH), în timp ce al treilea parametru este portul la care se va conecta clientul SSH de pe partea locală, ori de câte ori cineva se conectează la portul cu primul parametru de pe partea de la distanță. Din modul în care descrieți, doriți 5902 pentru ambele.

După ce rezolvi asta, nu văd niciun motiv pentru care nu ar funcționa.

Comentarii

  • Mulțumesc foarte mult pentru toate informațiile, trebuie să le asimilez. Am atribuit același port pe fiecare parte, așa cum a sugerat Stingray. Nici o bucurie până când nu am modificat GUI-ul aplicației serverului VNC. Nu sunt sigur că acest lucru este corect (pot posta imagini?), dar setați-l pentru a solicita loopback & permiteți 127.0.0.1 folosind fila ctrl de acces. Se poate conecta acum de la o mașină win10 prin 127.0.0.1 w vNC client & de la o vm linux care joacă același rol. Din nou, trebuie să digerăm contribuțiile de mai sus, foarte apreciat. FYI atunci când se conectează prin linux obține un mesaj roșu în partea de jos a ecranului win10 „fără criptare”; nu știu ce să fac din asta & nu primesc acest mesaj conectându-mă de pe vm win10. –  > Por Senrabdet.