Puncte:1

Proxy invers SSH folosind NGINX. (Subdomenii pentru containerele Docker care rulează SSH)

drapel jp

TDLR: x.a.se:22 și y.a.se:22 ar trebui să accepte și să conducă la mașina x și, respectiv, la mașina y. NGINX doar coordonează traficul prin proxy invers.

Bună comunitate minunată, Oscar din Suedia aici.

Configurare curentă

Am o mașină gazdă care acceptă a.se, să sunăm gazda mașina A. Asa de ssh [email protected] duce la SSH-serviciu la portul 22 pe mașina A. Mașina A alerga container dockers: mașina B și alte mașini, să ne concentrăm pe un container la un moment dat.

Utilizare dorită

Vreau să se întâmple asta:

  1. Utilizatorul Bob de operare mașina B nu are acces la mașina A deoarece utilizatorul nu este de încredere.
  2. Utilizator Bob se conectează la b.a.se:22 cu SSH și primește un shell la mașina B.

Problema

Nu stiu cum sa configurez asta. Cred că caut un proxy invers al SSH. Toate celelalte puncte finale ale mele sunt inversate folosind NGINX, deoarece la asta mă pricep cel mai bine, așa că mă uit la ngx_stream_proxy_module care poate inversa practic orice conexiuni TCP. Chestia este că nu pot să-mi înțeleg cum ar trebui să poată distinge proxy-ul de flux NGINX între a.se, baza si sa zicem n.a.se Unde n este orice șir.

Dacă aveți întrebări cu privire la configurarea mea sau la întrebarea în sine, vă rugăm să adăugați un comentariu și voi adăuga o modificare la această întrebare. Mulțumesc anticipat, orice ajutor și perspectivă este foarte apreciat.

Notă: Mașina gazdă rulează Debian 11 și am acces complet. Prefer Docker ca manager de container și NGINX pentru a direcționa traficul de rețea.

Notă: am adăugat link-uri către unele dintre cele mai de bază resurse, aceasta nu este pentru a-și bate joc de potențialii ajutoare, este prea de ajutor pentru a-i ajuta pe alții care citesc acest thread în viitor, punând aceeași întrebare ca și mine acum.

drapel us
Nu este posibil. SSH nu are conceptul de gazde virtuale necesare pentru ca acest lucru să funcționeze. SSH se conectează numai la o adresă IP după ce a rezolvat numele de domeniu la adresa IP.
djdomi avatar
drapel za
dacă nu sunteți prea leneș, instalați guacamole prin docker, va fi aproape la fel :) În caz contrar, puteți încerca lucrurile similare care vor fi folosite pentru smtp https://docs.nginx.com/nginx/admin-guide/mail- proxy/mail-proxy/
Oscar Andersson avatar
drapel jp
Salut @djdomi te referi la Apache Guacamole? Asta nu va funcționa pentru mine, nu sunt interesat de desktopul la distanță, vreau un shell la distanță criptat. Proxy-ul de e-mail nu ar funcționa, deoarece acceptă doar POP3, IMAP și SMTP. Mulțumiri.
Oscar Andersson avatar
drapel jp
Mulțumesc @TeroKilkanen :) Vă puteți gândi la vreun alt mod? Poate pot ruta [email protected] către containerul docker B printr-o regulă în sshd?
djdomi avatar
drapel za
@OscarAndersson ....... Ar trebui să vă gândiți la mențiune, partea de flux este aceeași pentru orice tip de proxy pe care doriți să îl utilizați.
Oscar Andersson avatar
drapel jp
@djdomi poți detalia? Încă nu prea înțeleg. Modulul de flux și setările proxy ale modulului de e-mail sunt interschimbabile?
Puncte:1
drapel us

Se poate conecta la container folosind gazda A ca gazdă de salt. Cu toate acestea, acest lucru necesită un cont de utilizator pe gazda A în acest scop.

Se poate limita contul de gazdă de salt, astfel încât să nu existe acces la serverul în sine.

Limitarea se poate face în gazda A sshd_config.

Potriviți utilizatorul bob
    X11Redirecționare nr
    AllowTcpForwarding
    ForceCommand ssh bob@<container>

După configurarea acestui lucru, se poate:

  1. ssh [email protected]
  2. Dați parola sistemului gazdă
  3. Daemonul SSH va forța executarea comenzii SSH în container
  4. Dați parola containerului

De asemenea, se poate crea o pereche de taste pe gazdă în bob cont care ar fi folosit pentru autentificarea la container. Atunci a doua parolă nu ar fi necesară.

Oscar Andersson avatar
drapel jp
Multumesc Tero! Este exact ceea ce caut. Voi face modificările în `sshd_config`. Care sunt implicațiile de securitate ale acestui lucru, `ForceCommand` rulează pe client sau pe serviciul SSH? Poate utilizatorul să ocolească acest lucru? Bineînțeles că voi fi implementat măsuri de securitate, astfel încât, chiar dacă acest lucru se întâmplă, nu se va face daune. Cum ar funcționa această pereche de taste pe gazdă? Nu prea înțeleg cum s-ar autentifica pe container. Mulțumiri. :)
drapel us
`ForceCommand` este rulat pe serverul SSH, iar demonul SSH împiedică utilizatorul să ruleze orice altă comandă.
Oscar Andersson avatar
drapel jp
Ești un zeu finlandez Tero! Mulțumesc frumos din partea cealaltă a lacului mare. Ce părere aveți despre problemă când un utilizator iese din containerul docker, va fi aruncat înapoi în gazdă, nu? Pot să-l repar cu `ForceCommand sh -c "sudo docker exec -ti user-container0 /bin/bash"; exit`, astfel încât sesiunea SSH să iasă automat când utilizatorul părăsește shell-ul (`/bin/bash`) în container?
drapel us
Dacă utilizați comanda `ssh` de mai sus, aceasta se conectează la demonul SSH al containerului Docker. Când utilizatorul închide shell-ul lansat de demonul SSH, acesta va închide conexiunea și gazda SSH va închide, de asemenea, conexiunea. Nu știu cum funcționează accesul prin comanda `docker`.
Oscar Andersson avatar
drapel jp
Ooooh într-adevăr, grozav! Nu mi-am dat seama, credeam că comanda ta era doar un substituent. Atat de naiv din partea mea, multumesc enorm!

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.