ROMFASTSQL/docs/acces-ssh-chei-angajati.md

# 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:

   ```powershell
   & '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):

```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\<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:

```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 ...`);
     pe toate serverele deodata: `scripts\bitvise-chei.ps1 -Actiune Remove` — sectiunea 6.
3. Optional: verifica in logurile Bitvise SSH Server ultima conectare cu fingerprint-ul lui,
   ca sa sti ce a accesat in perioada de gratie.

## 6. Unde stau cheile publice si pe ce servere sunt copiate

### Unde se salveaza cheia publica a unui angajat

`docs/chei-publice/<vm>.pub`, in acest repo. Cheile **publice** nu sunt secrete — se tin
versionate tocmai ca sa se stie, peste un an, exact ce sir trebuie revocat. Cheia **privata** nu
ajunge niciodata aici (vezi Capcane).

Fisierul e si sursa pentru revocare: `Remove File <acelasi .pub>` sterge exact ce a adaugat
`Add File`, fara sa fie nevoie de fingerprint copiat de mana.

```powershell
ssh-keygen -lf docs\chei-publice\vm304.pub   # amprenta, pentru corelare cu logurile serverului
```

| Fisier | Amprenta SHA-256 | Cine |
|---|---|---|
| `docs/chei-publice/vm303.pub` | `BDidUbM24Do2ySosEeVuP9wYSRo2+soOg4UhlNcUzTQ` | `romfast@VM-303` |
| `docs/chei-publice/vm304.pub` | `g1HHsnnqmbwEas7SFJuaUDcQLdsZKwNTklSXZO2mbLw` | `romfast@VM-304` |

VM 304 e clona lui VM 303, deci a pornit cu **aceeasi** cheie privata; a fost regenerata pe VM
304 (`ssh-keygen -t ed25519 -C "romfast@VM-304"`, plus stergerea keypair-ului mostenit din
**Bitvise User keypair manager** si regenerarea cheilor de host `C:\ProgramData\ssh\ssh_host_*`
daca VM-ul ruleaza sshd). Fara pasul din keypair manager, clona continua sa se autentifice cu
identitatea VM 303 si nu se vede diferenta in loguri.

### Serverele pe care sunt copiate cheile

Lista traieste in `scripts/bitvise-chei.ps1` (variabila `$Servere`) — se actualizeaza acolo,
nu aici, ca sa nu existe doua adevaruri.

| Server (profil din `D:\GoogleDrive`) | VM-303 | VM-304 |
|---|---|---|
| `automotive.tlp` | da | da |
| `avis.tlp` | da | da |
| `clever-motors.tlp` | da | da |
| `conpress_romfast.tlp` | da | da |
| `eduard.tlp` | da | da |
| `ems.tlp` | da | da |
| `romconstruct.bscp` | da | da |
| `romfast_bitvise.tlp` = **10.0.20.36:22122** (Oracle productie) | da | da |
| `sigma.tlp` | da | da |
| `vadeco.tlp` | da | da |
| `vending.tlp` | da | da |
| `abcval.tlp` | **nu** | **nu** |

`romfast_bitvise.tlp` si intrarea `10.0.20.36` sunt **acelasi server** (liste de chei identice) —
a doua e pastrata ca ruta de rezerva, fiindca parola din `bitvise_10.0.20.36.bscp` a expirat si
ruta aceea se conecteaza cu `-keypairFile` in loc de parola.

`abcval` ruleaza Bitvise SSH Server 9.32 si respinge Ed25519 cu `KeyNotSupported`. Daca un
angajat chiar are nevoie de el, genereaza o pereche RSA 3072/4096 in paralel si urca **acel** `.pub`.

Restul profilelor din `D:\GoogleDrive` sunt clienti expirati (timeout / conexiune refuzata) sau
servere Linux/OpenSSH, unde SPKS nu exista (`cod 201: Failed to request PublicKey subsystem`) —
acolo cheia se pune direct in `~/.ssh/authorized_keys`.

### Adaugare si revocare in masa

```powershell
cd E:\proiecte\ROMFASTSQL\scripts

.\bitvise-chei.ps1 -Actiune List                                      # ce chei sunt pe fiecare server
.\bitvise-chei.ps1 -Actiune Add    -Cheie ..\docs\chei-publice\vm304.pub
.\bitvise-chei.ps1 -Actiune Remove -Cheie ..\docs\chei-publice\vm304.pub   # revocare la plecare
```

Scriptul ruleaza `spksc` cu `-unat=y`, deci nu se blocheaza niciodata intr-un prompt: orice
server picat iese cu un cod de retur, nu cu o fereastra care asteapta. Coduri utile:
`101` conexiune esuata, `102` host key neacceptat in profil, `103` autentificare respinsa,
`201` serverul nu suporta SPKS, `233` algoritm de cheie nesuportat.

**Verificarea de dupa revocare nu e optionala**: `-Actiune List` si cauta comentariul cheii.
Un `Remove` care raporteaza "cheie inexistenta" pe un server unde cheia chiar era inseamna ca
te-ai conectat pe alt cont decat cel pe care a fost adaugata.

## 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.