From 85750d8ab3d5334b37d20c702d6b4f5ba52b2fdd Mon Sep 17 00:00:00 2001 From: Marius Date: Mon, 24 Aug 2026 18:57:38 +0300 Subject: [PATCH] docs: acces SSH la clienti cu chei publice pentru angajati noi --- CLAUDE.md | 1 + docs/acces-ssh-chei-angajati.md | 237 ++++++++++++++++++++++++++++++++ 2 files changed, 238 insertions(+) create mode 100644 docs/acces-ssh-chei-angajati.md diff --git a/CLAUDE.md b/CLAUDE.md index 16c193f..bed27d6 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -48,6 +48,7 @@ input/ # Oracle DMP files for import - **ROA Windows setup scripts (XE/SE 21c)**: `proxmox/lxc108-oracle/roa-windows-setup/README.md` - **VM 302 test environment for ROA setup**: `proxmox/vm302-oracle-test/README.md` - **Diagnostic spațiu Oracle la clienți (job zilnic + emailuri)**: `docs/diagnostic-spatiu-clienti.md` +- **Acces SSH la clienți cu chei publice (angajați noi)**: `docs/acces-ssh-chei-angajati.md` - **Cazuri clienți (depanare DB)**: `proxmox/lxc108-oracle/clienti/README.md` - **ROMPETROL ENERGY — recreare PDB Oracle XE 21c după ORA-12954**: `proxmox/lxc108-oracle/clienti/oracle-xe-21c/README.md` diff --git a/docs/acces-ssh-chei-angajati.md b/docs/acces-ssh-chei-angajati.md new file mode 100644 index 0000000..e0c705a --- /dev/null +++ b/docs/acces-ssh-chei-angajati.md @@ -0,0 +1,237 @@ +# 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\\.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: + + ```powershell + & 'C:\Program Files (x86)\Bitvise SSH Client\spksc.exe' --% -profile=d:\GoogleDrive\.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): + +```powershell +# 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\.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\.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\.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\.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: + +```powershell +# 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.