Warpgate: bastionul open-source care iti pune ordine in accesul SSH

Exista un moment, in viata oricarei infrastructuri care creste, cand raspunsul la intrebarea “cine are acces la serverul asta?” devine un ridicat din umeri. Cheile SSH s-au inmultit ca iepurii. authorized_keys de pe zece masini contine chei pe care nu le mai recunoaste nimeni. Un fost colaborator inca are, teoretic, acces la baza de date de productie, si nimeni nu e sigur ca i s-a revocat cheia peste tot. Cand cineva intreaba “ce a facut userul X pe serverul Y saptamana trecuta?”, raspunsul cinstit este: habar n-avem.

Aici intervine un bastion. Iar Warpgate , bastionul open-source scris in Rust de echipa warp-tech , rezolva exact aceasta durere fara sa iti ceara sa reinventezi intreaga poveste de acces. Il testam de cateva saptamani in fata catorva servere din datacenterul nostru din Bucuresti. Articolul asta e raportul de teren.

Ce este, mai exact, Warpgate

Pe scurt: Warpgate e un proxy transparent care sta intre tine si infrastructura ta interna si care nu cere absolut niciun software pe partea de client. Nu instalezi un agent, nu rulezi un wrapper peste ssh, nu forezi echipa sa adopte un tool nou. Continui sa dai ssh, sa deschizi VSCode Remote, sa lipesti un connection string de MySQL in clientul tau preferat, sa te loghezi la un panou web din browser. Warpgate se strecoara pe traseu, autentifica, aplica politica de acces, si abia apoi preda conexiunea mai departe catre tinta reala, inregistrand in tot acest timp o sesiune live pentru audit.

Partea de “transparent” e cheia si merita subliniata. Warpgate nu e un jump host clasic, unde te loghezi pe o cutie intermediara si apoi dai al doilea ssh catre destinatie. Diferenta e subtila dar importanta: dintr-un jump host trebuie sa faci doi pasi, sa ai chei pe cutia de mijloc, sa jonglezi cu ProxyJump si agent forwarding. Warpgate termina autentificarea in fata ta si apoi face handoff-ul catre server intr-un mod complet transparent pentru client. Din perspectiva ta, dai o singura comanda si esti pe server. Din perspectiva securitatii, fiecare byte care trece a fost inspectat, atribuit unei identitati si salvat.

De ce contorizeaza faptul ca e scris in Rust

Poate suna a detaliu de fani, dar are consecinte practice. Warpgate e 100% safe Rust, cu implementarea proprie de SSH (biblioteca russh), planul web pe framework-ul poem, si starea persistata in SQLite prin sea-orm si sqlx. Interfata de admin e un frontend modern in Svelte 5.

Ce inseamna asta la nivel operational: un singur binar, fara dependinte externe, fara un runtime greu de patch-uit, fara clasa intreaga de vulnerabilitati de memorie (buffer overflow, use-after-free) care a bantuit software-ul de retea scris in C timp de trei decenii. Pentru un serviciu care, prin definitie, sta expus la marginea retelei si vede primul fiecare tentativa de acces, “safe by construction” nu e un slogan de marketing, e exact proprietatea pe care o vrei.

Ce protocoale acopera

Warpgate a plecat ca bastion de SSH, dar s-a extins mult. La zi, expune listenere native pentru:

• SSH, cazul clasic: acces la shell pe servere, cu inregistrare completa de sesiune.
• HTTPS, pentru a pune orice aplicatie web interna (un panou de admin, un Grafana, un router) in spatele aceleiasi porti de autentificare.
• MySQL si PostgreSQL, ca sa treci si conexiunile de baza de date prin bastion, cu acelasi model de identitate si audit.
• Kubernetes, pentru acces kubectl la clustere prin acelasi punct de control.
• RDP si VNC, adaugate mai recent, pentru sesiuni de desktop la distanta.

Toate prin acelasi binar, acelasi UI de admin, acelasi model de useri si roluri. Nu jonglezi cu sase tool-uri diferite; ai un singur loc unde spui cine ajunge la ce.

Ce primesti din cutie

Editia open-source, singura de altfel, e generoasa. Warpgate e licentiat sub Apache-2.0, aduna peste 7.400 de stele pe GitHub si e dezvoltat activ. Din cutie primesti:

• Autentificare in doi factori (2FA) nativa, prin TOTP. Adica generatorul de coduri din Google Authenticator, Aegis sau orice alta aplicatie, fara vreun SMS gateway de platit.
• Single Sign-On prin OpenID Connect, ca sa legi Warpgate de furnizorul tau de identitate (Authelia, Keycloak, Google Workspace, Azure AD). Userul se logheaza o data, cu identitatea companiei, si primeste exact accesul pe care i l-ai desemnat.
• Inregistrare completa de sesiune, cu vizualizare live si replay ulterior direct din UI-ul de admin. Poti sa urmaresti in timp real ce se tasteaza intr-o sesiune SSH, sau sa te intorci peste doua saptamani si sa redai exact ce s-a intamplat.
• Audit la nivel de comanda, nu doar “userul s-a conectat la 14:32”, ci ce a rulat acolo.
• Control precis al accesului, cu asignare fina intre useri, roluri si tinte. Un user vede si atinge doar serviciile care i-au fost desemnate, nimic altceva.
• Protectie anti-brute-force, cu blocare pe IP si lockout de user, ca sa nu-ti transforme cineva portul 2222 intr-un teren de joaca.
• Un singur binar, fara dependinte, care porneste in secunde si se muta usor dintr-un loc in altul.

Ce nu face, si e bine sa fie clar: Warpgate nu e un VPN si nu e un vault de secrete. Nu iti cripteaza segmentul de retea end-to-end pentru tot traficul, ci iti da o poarta de acces controlat catre servicii specifice. Nu inlocuieste un HashiCorp Vault pentru rotatia secretelor. E o bucata dintr-o strategie de acces, nu strategia intreaga.

Instalare Warpgate pe un VPS

Aici multe proiecte “self-hosted PAM” te fac sa regreti alegerea, ingropandu-te intr-un helm chart de trei sute de linii si cinci dependinte externe. Warpgate, sincer, nu. Fiind un singur binar Rust, instalarea e aproape jenant de simpla.

Resurse rezonabile pentru inceput: 1 vCPU si 1 GB RAM duc lejer un bastion pentru o echipa mica; urca la 2 vCPU / 2 GB daca inregistrezi multe sesiuni concurente sau treci trafic de baze de date. SQLite tine starea locala, deci nu ai nevoie de un server de baza de date separat.

Pe un server proaspat de Debian sau Ubuntu, iei binarul din release-urile oficiale:

ver=v0.26.1
wget https://github.com/warp-tech/warpgate/releases/download/$ver/warpgate-$ver-x86_64-linux
chmod +x warpgate-$ver-x86_64-linux
sudo mv warpgate-$ver-x86_64-linux /usr/local/bin/warpgate

Apoi lansezi setup-ul interactiv, care iti genereaza fisierul de configurare, cheile de host si primul cont de admin:

sudo warpgate --config /etc/warpgate.yaml setup

Setup-ul te intreaba pe ce porturi sa asculte fiecare protocol. Valorile implicite sunt alese bine ca sa nu se bata cu serviciile deja existente pe cutie:

• SSH: portul 2222 (nu 22, ca sa nu se ciocneasca cu sshd-ul host-ului).
• UI de admin HTTPS: portul 8888.
• MySQL: portul 33306.

Datele si istoricul de sesiuni ajung intr-o baza SQLite in /var/lib/warpgate. Dupa setup, pornesti serviciul:

sudo warpgate --config /etc/warpgate.yaml run

Pentru productie il pui, evident, intr-un unit systemd cu Restart=always, ca sa se ridice singur dupa un reboot. Daca preferi containere, exista si imagine Docker oficiala plus un helm chart, dar pentru un bastion single-node binarul direct pe host e cea mai curata varianta: mai putine straturi de retea intre atacator si log-uri.

Un pas de igiena pe care nu il sari niciodata: UI-ul de admin de pe 8888 nu trebuie expus lumii intregi. Restrictioneaza-l la IP-urile de management prin firewall:

ufw allow 2222/tcp
ufw allow from IP_BIROU_TAU to any port 8888 proto tcp
ufw deny 8888/tcp

Daca rulezi asta pe un VPS DreamServer , aceeasi regula trebuie dublata si in firewall-ul de retea al providerului, nu te baza doar pe reguli la nivel de host pentru interfetele de management.

Cum adaugi un target si un user

Modelul mental dureaza un minut sa se aseze, dar dupa aia e limpede. In Warpgate ai trei entitati care se combina: targets (serverele si serviciile catre care vrei sa dai acces), users (oamenii care se conecteaza) si roles (grupuri care leaga userii de targets).

In UI-ul de admin de la https://<ip-server>:8888/, adaugi intai un target SSH: numele lui in Warpgate (sa zicem web-prod), adresa reala si portul originii (10.0.0.5:22), si cum se autentifica Warpgate mai departe catre server, cu o cheie SSH dedicata pe care o generezi pentru bastion. Cheia aia ajunge in authorized_keys pe target, si e singura care mai trebuie sa existe acolo: din acel moment, oamenii nu mai au chei personale imprastiate pe servere, ci trec toti prin bastion.

Apoi creezi un user, ii activezi 2FA (sau il legi prin OIDC de identity provider-ul companiei), si il asignezi la un rol care are acces la web-prod. Gata. Userul se conecteaza asa:

ssh admin:web-prod@bastion.example.com -p 2222

Sintaxa user:target@host e toata magia: partea dinainte de : e identitatea Warpgate, partea de dupa e numele target-ului la care vrei sa ajungi. Warpgate te autentifica (parola plus codul TOTP, sau redirect OIDC in browser), verifica ca ai voie la web-prod, si te pune pe server. Pentru baze de date, acelasi model, doar sintaxa difera putin:

mysql -u 'admin#web-db' --host bastion.example.com --port 33306 --ssl -p

Pentru tintele HTTPS, deschizi UI-ul Warpgate in browser, te autentifici, si dai click pe target: bastionul iti proxy-eaza aplicatia web interna prin poarta lui autentificata, fara sa expui direct aplicatia la internet.

Tipare de configurare care merita stiute

Cateva lucruri pe care le-am gasit chiar utile dincolo de default-uri.

Forteaza 2FA pentru toata lumea, de la inceput

Un bastion fara al doilea factor e doar un SSH cu pasi in plus. Activeaza TOTP obligatoriu pe toti userii de la prima zi, inainte sa apuce cineva sa se obisnuiasca fara. Costul e o scanare de QR code; beneficiul e ca o parola furata singura nu mai deschide nimic.

Leaga-l de OIDC si scapi de gestiunea manuala de conturi

Daca ai deja un identity provider, integrarea OIDC transforma Warpgate din “inca un loc unde tin parole” in “inca un serviciu care respecta identitatea companiei”. Cand pleaca un om, ii dezactivezi contul intr-un singur loc, in IdP, si accesul lui la tot ce trece prin bastion dispare instant. Asta singur rezolva scenariul cu care am inceput articolul.

Revizuieste inregistrarile, nu doar sa stea acolo

Puterea reala a inregistrarii de sesiune nu e ca exista, e ca o folosesti. Intra o data pe saptamana in Sessions din UI si trece prin ce s-a intamplat pe tintele sensibile. Vei prinde lucruri: cineva care a rulat un DROP pe baza gresita, un colaborator care a atins un server care nu era in sarcina lui, un incident pe care nimeni nu il raportase. Replay-ul e ceva ce nu poti obtine dintr-un log de text.

Un target = o cheie dedicata de bastion

Nu refolosi aceeasi cheie SSH pentru toate target-urile. Genereaza cate o pereche per server, tinuta de Warpgate. Daca vreodata trebuie sa scoti un server din bastion sau sa rotesti o cheie, o faci chirurgical, fara sa atingi accesul catre restul flotei.

Trateaza baza SQLite ca infrastructura critica

Toata configuratia si tot istoricul de sesiuni traiesc in /var/lib/warpgate. Containerul sau binarul se reconstruiesc intr-un minut; baza SQLite e ce ti-ar lipsi cu adevarat. Pune-o intr-o poveste de backup reala, un Proxmox Backup , snapshot-uri, alegerea ta, si testeaza ca stii sa o restaurezi.

Unde Warpgate nu e raspunsul potrivit

Merita sa fim onesti despre limite.

• Nu e un VPN. Warpgate iti da acces controlat catre servicii specifice, nu un tunel de retea generic. Daca ai nevoie ca un laptop sa “fie in retea” pentru zeci de servicii ad-hoc, un VPN (sau WireGuard) ramane tool-ul complementar, nu inlocuit.
• Nu e un vault de secrete. Nu roteste automat parole de baze de date si nu injecteaza credentiale efemere in stil Vault. Stocheaza cheile de acces ale bastionului, atat.
• SQLite are un plafon. Pentru o echipa si o flota de dimensiuni normale, SQLite e perfect. Pentru zeci de mii de sesiuni pastrate pe termen lung sau setup-uri multi-node cu HA agresiv, planifica atent, exporta si arhiveaza inregistrarile vechi in loc sa lasi baza sa creasca la nesfarsit.
• Self-hosting nu e gratis. Mai rulezi un serviciu stateful care are nevoie de backup-uri, patching de OS si atentie ocazionala. Daca echipa ta nu vrea asta, exista bastioane gestionate, dar vei plati altfel, in bani si in control.

Alternative pe care le-am luat in calcul

Pentru completitudine: ne-am uitat si la Teleport (extrem de capabil, cu certificate scurte si acces la infrastructura la scala mare, dar mult mai greu si cu feature-uri cheie impinse spre editia comerciala), sshpiper (reverse proxy pur de SSH, minimalist, fara UI si fara inregistrare de sesiune), Apache Guacamole (excelent pentru RDP/VNC in browser, dar centrat pe desktop remote, nu pe modelul de bastion multi-protocol) si un simplu jump host de SSH intarit cu manual (ieftin, familiar, dar fara audit real si cu aceeasi problema de imprastiere a cheilor pe care voiam sa o rezolvam).

Warpgate s-a dovedit cea mai curata potrivire pentru “vreau un bastion real, cu 2FA si inregistrare de sesiune, in fata unei flote mici-medii de servere self-hosted, fara sa adopt o platforma intreaga”. Ponderile tale pot fi diferite.

Deci, sa-l rulezi?

Daca administrezi mai mult de o mana de servere si ai ajuns in punctul in care nu mai poti raspunde cu certitudine la “cine are acces la ce si ce a facut acolo”, Warpgate merita o duminica dupa-amiaza. Instalarea e chiar rapida, modelul de acces se aseaza repede in cap, si prima data cand redai o sesiune inregistrata ca sa intelegi un incident vei sti ca ti-a intrat in stack pentru totdeauna.

Daca il rulezi in productie, trateaza-l cum ii sta bine unui bastion: expus minimal, cu UI-ul de admin blocat la IP-uri de incredere, cu 2FA fortat, si cu baza SQLite in backup. Bastionul e, prin definitie, singurul drum catre restul infrastructurii, deci merita grija pe masura.

Noi rulam Warpgate in fata catorva servicii interne si il recomandam clientilor care ne intreaba cum sa puna ordine in accesul SSH. Daca vrei sa-l incerci pe infrastructura pe care nu trebuie sa o construiesti tu intai, planurile noastre VPS incep la dimensiuni suficient de mici cat sa faca experimentul ieftin, iar serviciul de administrare server acopera instalarea, integrarea OIDC si tuning-ul daca preferi sa sari peste curba de invatare.

Oricum ai alege, sa testezi Warpgate e o seara mai bine petrecuta decat sa mai numeri o data cheile din authorized_keys sperand ca le recunosti pe toate. Codul e pe GitHub, instalarea e practic o singura comanda, si vei sti intr-o ora daca isi castiga locul in fata infrastructurii tale.