Puncte:0

Transmite conexiunea SSH la un server diferit la conectare

drapel za

Bună seara,
În prezent, încerc să-mi aprofundez mâna mai mult în Linux, cu care sunt familiarizat.

Să trecem direct la problema mea:
În primul rând, să vorbim despre configurația mea.
Am 3 servere, fiecare având un IP public.
Fiecare server face parte dintr-un VLAN.
Serverul #1 (vlan 10.0.0.2) nu este protejat de un firewall.
Serverul #2 (vlan 10.0.0.3) și Serverul #3 (vlan 10.0.0.4) sunt complet blocate de pe internet și pot fi accesate numai din vlan.
Serverul #2 rulează un container KeyCloak. Cu toate acestea, acest lucru este irelevant pentru problemă.
Serverul #3 ar trebui să servească drept serverul meu git.
În mod normal, aș crea doar un git utilizator, link-ul chei_autorizate dosar cu cel al meu GitLab recipient. Fiecare cheie publică ar fi prefixată cu o comandă, care ar trece apoi conexiunea către deamonul ssh din interiorul containerului.
Dar, deoarece Serverul #3 nu este accesibil public, trebuie să accept conexiunea ssh de intrare pe Serverul #1.
Am creat un git utilizator și am început să mă gândesc cum pot depăși această problemă.

M-am gândit la două moduri în care aș putea face față.

  1. Permite git utilizator pentru a fi accesat fără parolă și pentru a deschide o conexiune la [email protected] (funcționează? Funcționează clientul ssh-agent în acest caz? Ar putea un atacator să iasă din conexiunea ssh internă și să facă lucruri pe Serverul #1?)
  2. Serverul #3 se conectează regulat la Serverul #1 și actualizează chei_autorizate fișier (atunci ar trebui să scriu un al doilea script la comanda locație, care ar deschide apoi conexiunea către Serverul #3. Acest lucru ar fi mai lent, deoarece utilizatorul trebuie să aștepte până când Serverul #3 se sincronizează cu Serverul #1)
Michael Hampton avatar
drapel cz
3. Faceți serverul 3 accesibil publicului.
drapel za
@MichaelHampton nu este deloc util și nu este ceea ce întrebam
Michael Hampton avatar
drapel cz
Este exact ceea ce ați întrebat și este cea mai simplă și mai fiabilă soluție.Dacă nu doriți să o luați în considerare, ar trebui să explicați în detaliu de ce nu doriți să o faceți.
drapel za
@MichaelHampton Am explicat configurația mea de rețea și am presupus că ar fi clar că vreau ca Serverul #1 să fie considerat ca o poartă către orice alt server și ar trebui să rămână așa. Îmi pare rău că nu mi-am declarat în mod explicit intenția. Aceasta este practic o cerință pentru întreaga configurație. Aceasta înseamnă: dacă vă aflați în rețea, puteți face tot ce doriți. Dacă nu sunteți, trebuie să îl accesați prin gateway, fie utilizând „rute” predefinite (de exemplu utilizator ssh care se conectează automat la serverul git etc.), fie prin conectarea prin ssh.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.