romfast/ROMFASTSQL
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0ace9f97ac8e22469020d405cfdd745e8218ae28
ROMFASTSQL/docs/acces-ssh-chei-angajati.md

14 KiB
Raw Blame History

Acces SSH la clienti cu chei publice/private — procedura pentru angajati noi

De ce: conexiunile catre clientii ROMFAST merg prin Bitvise SSH Server (la client) si Bitvise SSH Client (la noi), iar pana acum totul a mers pe user + parola salvata in profil. Cand un angajat nou (aici: VM 303, Windows 11) are nevoie de tunelurile SSH catre clienti, i se da acces pe chei — avantaj: la plecarea lui revoci o singura cheie pe fiecare server, fara sa schimbi parola la toti clientii.

Context conex: docs/diagnostic-spatiu-clienti.md sectiunea 6 (cum se deschide un tunel si capcanele lui).

1. VM 303 (angajatul) — generarea perechii de chei

  1. Instaleaza Bitvise SSH Client.
  2. Tab Login → User keypair manager → Generate New:
    • algoritm Ed25519 (fallback: RSA 2048 doar daca serverul de la client e versiune foarte veche si refuza Ed25519);
    • passphrase puternica — cheia fara passphrase e echivalentul unei parole lipite pe monitor.
  3. Export public key (format OpenSSH sau Bitvise) → trimite doar fisierul .pub spre administrator (eu). Cheia privata ramane pe VM 303 — nu circula niciodata prin email/Drive/mesagerie.

Varianta: cheie generata deja prin alta metoda (ex. OpenSSH)

Daca pe VM 303 exista deja C:\Users\romfast\.ssh\id_ed25519 (generata cu ssh-keygen pentru git sau alt client OpenSSH), se poate folosi aceeasi cheie si in Bitvise — nu trebuie una noua:

  1. User keypair manager → Import → alege fisierul de cheie privata id_ed25519 (cel fara .pub); Bitvise importa formatul OpenSSH (inclusiv formatul nou -----BEGIN OPENSSH PRIVATE KEY----- si Ed25519) si formatul PuTTYgen (.ppk). Daca cheia are passphrase, il cere la import.
  2. Importul face o copie in managerul Bitvise — fisierul original din .ssh ramane neatingut, deci ssh.exe/git continua sa il foloseasca in paralel.
  3. Pentru serverul de la client se foloseste direct id_ed25519.pub existent — Bitvise SSH Server importa format OpenSSH, fara conversie.

Capcanele variantei:

  • Cheia fara passphrase ramane fara passphrase si dupa import — daca vrei protectie, ruleaza inainte ssh-keygen -p -f C:\Users\romfast\.ssh\id_ed25519.
  • O cheie comuna pentru git/OpenSSH/Bitvise = un singur punct de compromitere. Acceptabil, dar idealul e o cheie dedicata doar pentru tunelurile catre clienti (generezi separat si revoci separat).
  • Nu uita capcana din sectiunea 3: keypair-ul importat in manager sta in registry per-user si nu e vazut de stnlc -noRegistry=y — pentru rulari scriptate foloseste -keypairFile= cu fisierul original, sau copiaza keypair-ul in profil.

2. Serverul clientului — autorizarea cheii

2a. Am acces la Bitvise SSH Server Control Panel

  1. Easy Settings (sau Advanced Settings → Accounts) → contul folosit de noi (ex. romfast) → tab Authentication → Public keys → Import cheia publica a angajatului.
  2. Un cont poate avea mai multe chei publice — parola existenta ramane valabila, iar regulile de forwarding de pe server (ex. ROA Oracle = 127.0.0.1:1521) nu se ating.
  3. Varianta cu audit mai clar (optional): cont separat pentru angajat, mapat pe acelasi user Windows, in care se reproduc manual regulile c2s. Costa munca in plus; varianta simpla (cheia pe contul existent) e ok — in logurile Bitvise se vede metoda de autentificare si fingerprint-ul cheii folosite.

2b. Fara acces la Control Panel — doar parola + acces la fisiere (SFTP)

Bitvise SSH Server are doua mecanisme prin care utilizatorul isi administreaza singur cheile publice, fara administrator (FAQ Q350). Ambele actioneaza asupra contului cu care ma conectez eu (romfast) — deci cheia adaugata il lasa pe angajat sa intre pe acelasi cont.

Important — tipul contului de pe server: daca romfast e un cont virtual Bitvise (nu un cont Windows), varianta A nu se aplica deloc (fara profil Windows, .ssh nu apare in SFTP — vederea doar a partitiilor C/D/E la un client e semnul) → sari direct la varianta B, care functioneaza pentru conturi virtuale. Bonus: conturile virtuale nici nu sunt afectate de capcana LSA protection de la finalul sectiunii.

Varianta A — .ssh/authorized_keys (de incercat prima)

  1. Conecteaza-te cu profilul existent (parola) si deschide fereastra SFTP.
  2. Cauta in radacina SFTP (langa C:, D:, E:) un director .ssh — e un mount point special al serverului, nu un folder real pe disc si nu se gaseste navigand pe partitii (crearea manuala a lui C:\Users\<cont>\.ssh nu ajuta: fara setarea activa, serverul ignora fisierul). Daca nu apare in radacina, sincronizarea cu authorized_keys e dezactivata pe serverul respectiv → treci la varianta B.
  3. Daca exista deja fisierul authorized_keys in .ssh, descarca-l si adauga cheia angajatului ca linie noua (format OpenSSH, o cheie pe linie). Nu-l suprascrie: la logout, serverul inlocuieste toate cheile configurate pe cont cu continutul fisierului.
  4. Uploadeaza fisierul authorized_keys in .ssh, apoi deconecteaza-te curat (Logout, nu inchiderea fortata a clientului) — serverul citeste fisierul abia la sfarsitul sesiunii.
  5. Angajatul testeaza loginul cu cheia.

Functioneaza doar pentru conturi Windows (nu conturi virtuale Bitvise).

Varianta B — SPKS / "Upload to server" (activat implicit pe server)

Functioneaza si pentru conturi virtuale, si pentru conturi Windows; nu depinde de niciun mount point in SFTP. Atentie la semantica "Add": pentru contul curent se adauga cheia — exact ce vrem (angajatul intra pe acelasi cont).

  1. Incearca intai urcarea directa a cheii publice a angajatului, din linia de comanda:

    & 'C:\Program Files (x86)\Bitvise SSH Client\spksc.exe' --% -profile=d:\GoogleDrive\<client>.tlp -cmd="Add File C:\temp\angajat.pub"

    Cod de retur 200 = serverul nu suporta SPKS (prea vechi) → ramane doar Control Panel-ul.

  2. Daca Add File refuza un fisier doar cu cheie publica: angajatul se conecteaza o singura data cu parola (fluxul oficial Bitvise, FAQ Q330) → Client key manager → importă keypair-ul lui → click dreapta → Upload to server. De acum cheia lui functioneaza. Contras: angajatul a vazut parola contului — daca e inacceptabil, ramane varianta A sau accesul la Control Panel.

Cand oricum e nevoie de admin

  • Server vechi: nici .ssh in SFTP, nici SPKS (cod 200 la spksc).
  • Windows recent (~2025+) cu Bitvise SSH Server < 9.51: LSA protection (RunAsPPL), activ implicit, blocheaza pachetul de autentificare BvLsa → loginul cu cheia pe conturi Windows esueaza chiar daca cheia e instalata corect (FAQ Q370). Remedii, toate de admin: update server la 9.51+, password cache sau dezactivare LSA protection. Simptom: parola merge, cheia nu. Versiunea serverului se vede in mesajele de login ale clientului Bitvise. Conturile virtuale nu sunt afectate de LSA protection — la ele, cheia functioneaza indiferent de versiune.
  • Tunelurile spre 127.0.0.1:1521 functioneaza si cu autentificare prin cheie pe cont virtual cu context de securitate implicit (FAQ Q450): doar resursele de retea (shares, EFS) ar cere configurarea password cache — nu e cazul nostru.

Depanare: cheia e pe server, dar loginul cere parola (FAQ Q320)

"Cere parola" inseamna doar ca autentificarea a esuat — nu si ca publickey ar fi dezactivat. Cea mai frecventa cauza e ca clientul nici nu ofera cheia. Izolarea se face cu propria cheie, de pe calculatorul meu (nu cel al angajatului):

# 0. daca nu am keypair: BvSsh -> Login -> Client key manager -> Generate New (devine g1)

# 1. adauga cheia mea pe contul de la client (login cu parola din profil)
& 'C:\Program Files (x86)\Bitvise SSH Client\spksc.exe' --% -profile=d:\GoogleDrive\<client>.tlp -cmd="Add Global 1"

# 2. login DOAR cu cheia (SPKS merge unattended: nu cade inapoi pe parola)
& 'C:\Program Files (x86)\Bitvise SSH Client\spksc.exe' --% -profile=d:\GoogleDrive\<client>.tlp -pk=g1 -cmd="List Server"

# 3. curatenie: scoate cheia mea de pe server
& 'C:\Program Files (x86)\Bitvise SSH Client\spksc.exe' --% -profile=d:\GoogleDrive\<client>.tlp -cmd="Remove Global 1"

Interpretare:

  • Cum se citeste output-ul de respingere: linia Remaining authentication methods arata metodele inca disponibile pe cont — daca publickey apare acolo, metoda e activa pe server si respingerea inseamna "cheia nu e recunoscuta pe acest cont" (nu a fost adaugata / a fost adaugata pe alt cont / alt keypair decat cel oferit). Daca publickey lipseste din lista, metoda e dezactivata in setarile contului — doar adminul o poate activa.
  • Pasul 2 reusește → serverul accepta publickey pe cont; problema e la angajat (vezi mai jos).
  • Pasul 2 esueaza cu cod 103 → serverul refuza publickey:
    • server foarte vechi, fara suport Ed25519 → angajatul genereaza RSA 2048/3072 si se reface Add File; versiunea serverului se vede in mesajele de login ale clientului;
    • publickey dezactivat in intrarea contului/grupului virtual (Advanced settings → Access control → Virtual accounts → grupul/contul → Authentication) → cere acces la Control Panel; semnul diagnostic: publickey lipseste din Remaining authentication methods la login;
    • loguri prin SFTP: C:\Program Files (x86)\Bitvise SSH Server\Logs — fisierul textual de log spune explicit de ce a picat (cheie necunoscuta / metoda nepermisa / metoda nici macar nu s-a incercat). Serverul EMS e 9.66 — versiune curenta, deci cauzele "server prea vechi" (fara Ed25519, fara SPKS, LSA protection) nu se aplica la el.
  • Cauze client-side (daca serverul e OK): profilul nu are Login → Authentication → Initial method = publickey si Client key = keypair-ul lui; parola salvata in profil "câstiga" tacut inainte de cheie; keypair-ul e in registry-ul altui user Windows (managerul e per-user); promptul de passphrase (protectia locala a cheii) nu e parola serverului; -noRegistry=y fara -keypairFile=/profil (vezi sectiunea 3).

3. Profilul de client pentru angajat

Regula: nu se copiaza profilele mele din D:\GoogleDrive\<client>.tlp — au parola salvata in .tlp. Cheia angajatului se adauga pe server de pe calculatorul meu (sectiunea 2b, Add File), deci angajatul nu are nevoie de nimic de la mine in afara de: host, port, username si fingerprint-ul host key-ului.

Varianta principala: profil de la zero (pe VM 303)

  1. Tab Login: host + port + username (numele contului virtual de la client).
  2. Authentication: Initial method = publickey, Client key = keypair-ul angajatului (importat in User keypair manager — a se vedea sectiunea 1). Fara parola salvata.
  3. La prima conectare apare promptul de host key: angajatul verifica fingerprint-ul cu cel transmis de mine pe alt canal si abia apoi accepta. Fingerprint-ul se vede in mesajele de login ale oricarui client Bitvise (ex. output-ul spksc: SHA-256 fingerprint: ...) sau in profilul meu, la Login → Host key manager → click dreapta pe cheie.
  4. Save profile (ex. ems.tlp al lui) — de acum se conecteaza doar cu cheia.

Varianta alternativa: copie din profilul meu

Copiaza profilul (ex. sigma.tlp → sigma_angajat.tlp), apoi in tabul Login: la Authentication debifeaza/sterge parola salvata, seteaza publickey + keypair-ul angajatului. Host key-ul ramane din copie (fara prompt de verificare). Avantaj: niciun transfer de fingerprint; risc: daca uiți sa stergi parola, o livrez odata cu profilul — de aceea e doar alternativa.

Scripturi neinteractive (comun ambelor variante)

Daca angajatul va rula si scripturi neinteractive (ca in docs/diagnostic-spatiu-clienti.md): cu stnlc -noRegistry=y keypair-urile "globale" din registry nu sunt vazute — keypair-ul trebuie sa fie fisier (exportat din keypair manager sau chiar id_ed25519 din .ssh, via -keypairFile=), sau copiat in profil (User keypair manager → click dreapta pe keypair → Copy to profile, apoi in profil Login → Authentication → Client key = Profile 1; echivalent CLI: -pk=p1).

4. Testul de validare

Din VM 303, dupa conectare:

# 0. verifica intai ca nu e deja un tunel deschis spre ALT client
Get-NetTCPConnection -State Listen -LocalPort 1521

# 1. prima interogare dupa conectarea prin tunel — confirma clientul corect
select instance_name, host_name from v$instance;

Regulile de forwarding vin de la server (profilul nu da -c2s), deci tunelul gresit se detecteaza doar cu verificarea de mai sus — nu trece nimeni direct la SQL.

5. Revocarea accesului

La plecarea angajatului:

  1. Pe fiecare server de client: stergi cheia lui publica din tabul Authentication al contului. Atat — parola ramane neschimbata, deci nimic din accesul existent nu se strica.
  2. La clientii fara Control Panel: revocarea se face prin acelasi mecanism cu care a fost adaugata cheia:
    • varianta A: sterge linia angajatului din .ssh/authorized_keys, re-uploadeaza, deconecteaza-te curat — sincronizarea de la logout inlatura cheia;
    • varianta B: spksc ... -cmd="Remove File C:\temp\angajat.pub" (sau Remove Fingerprint ...).
  3. Optional: verifica in logurile Bitvise SSH Server ultima conectare cu fingerprint-ul lui, ca sa sti ce a accesat in perioada de gratie.

Capcane

  • Cheia privata nu se primeste niciodata "in avans" de la angajat ca backup — daca se pierde, se genereaza una noua si se repeta pasul 2.
  • -noRegistry=y + keypair doar in registry = autentificare care cere parola sau esueaza; testul scripturilor se face cu acelasi stil de comanda cu care vor rula in productie.
  • Profilele noi (.tlp) se dau angajatului fara parola salvata; daca a mostenit una din copie, se sterge din Authentication methods inainte de predare.