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

Pentru toate profilele deodata, cu verificare care prinde parola uitata: **sectiunea 7**.

### 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` | angajat, `romfast@VM-303` |
| `docs/chei-publice/vm304.pub` | `g1HHsnnqmbwEas7SFJuaUDcQLdsZKwNTklSXZO2mbLw` | angajat, `romfast@VM-304` (clona lui 303) |
| `docs/chei-publice/marius-lenovo-birou.pub` | `Rp4QdhbGw1G7eNY4T66VAeRSMbb8kMgdWExvOCwn7Wg` | admin, statia de birou (`C:\Users\mmari\.ssh\id_ed25519`) |
| `docs/chei-publice/marius-lenovo-birou-rsa.pub` | `3LTMHACTsF21CfoHwG6oHlmNgynoOl43zPGz1exe87w` | admin, aceeasi statie — RSA 4096, doar pentru serverele care refuza Ed25519 |
| `docs/chei-publice/marius-hx90g.pub` | `XxLBMaYY0BhhOnYnIsnboLEswEGDoRic+0ZGDIuJo6Q` | admin, `marius@Marius-HX90G` |

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. Tabelul de mai jos e starea verificata la 2026-09-01
cu `-Actiune List` (comparatie pe amprenta, nu pe comentariu — comentariile se repeta).

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

`abcval` ruleaza Bitvise SSH Server 9.32 si respinge Ed25519 cu `KeyNotSupported` — pe el intra
doar chei RSA. De aceea coloana "birou RSA" exista: e aceeasi statie, alta pereche de chei.
Un angajat care are nevoie de `abcval` isi genereaza in paralel o pereche RSA 3072/4096.

`romfast_bitvise.tlp` (`roadigi.romfast.ro:22122` = `188.26.14.103`) si `10.0.20.36:22122` sunt
**acelasi server**, vazut din exterior si din reteaua interna — listele de chei sunt identice.
Profilul extern **nu mai autentifica neinteractiv** (`Attempting none authentication` → nicio
metoda disponibila, deci nici parola stocata, nici keypair global valid); pana se repara din GUI,
ruta interna `10.0.20.36` este cea care functioneaza, si e cea din script.

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.

## 7. Mutarea profilelor mele pe VM 303, convertite la publickey

Profilele mele de client se conecteaza cu **parola salvata in fisier**. Copiate ca atare pe VM
303, angajatul primeste parolele tuturor clientilor. Conversia la publickey se face pe **copii**,
nu pe profilele de lucru.

De ce merita copiate in loc de reconstruite de la zero: **host key-ul calatoreste in profil**
(verificat pe toate cele 11 cu `-noRegistry=y` — niciun "host key rejected"), deci angajatul nu
mai are de verificat manual cate un fingerprint per client.

### Ce contine de fapt fiecare profil

Se afla fara sa deschizi nimic in GUI, ruland comanda cu `-noRegistry=y` (blocheaza registry-ul,
deci ce reuseste vine din fisier):

```powershell
$spksc = 'C:\Program Files (x86)\Bitvise SSH Client\spksc.exe'
foreach ($f in Get-ChildItem 'D:\vm303-profile') {
  $o = & $spksc "-profile=$($f.FullName)" -noRegistry=y -unat=y -initialKexTimeout=20 "-cmd=List Server" 2>&1 | Out-String
  '{0,-24} {1}' -f $f.Name, (($o -split "`n" | Select-String 'Attempting|Signing with client key' | Select-Object -First 2) -join ' / ')
}
```

Starea la 2026-09-01, inainte de conversie:

- 9 profile → `Attempting password authentication` = **parola in fisier, portabila** (nu e legata
  de contul meu Windows, deci pleaca odata cu fisierul);
- `vadeco.tlp` → `Signing with client key 'Profile 1'` = **cheie privata Ed25519 salvata in
  profil**. Copiat asa, angajatul primeste cheia mea privata — singurul lucru din procedura care
  chiar are consecinte;
- `romfast_bitvise.tlp` → nimic. Initial am citit asta ca "foloseste o cheie globala din
  registry", dar verificarea ulterioara (`-pk=a`, care ar incerca orice cheie globala) arata
  `Attempting none authentication` si apoi nicio metoda: profilul **nu are nicio credentiala
  utilizabila**. Nu e gata de copiat — trebuie deschis in GUI si reparat inainte, altfel
  angajatul primeste un profil care doar cere parola.

### Pasul 1 — folderul de pregatire

```powershell
$dest = 'D:\vm303-profile'
New-Item -ItemType Directory -Force $dest | Out-Null
'automotive.tlp','avis.tlp','clever-motors.tlp','conpress_romfast.tlp','eduard.tlp',
'ems.tlp','romconstruct.bscp','romfast_bitvise.tlp','sigma.tlp','vadeco.tlp','vending.tlp' |
  ForEach-Object { Copy-Item "D:\GoogleDrive\$_" $dest -Force }
```

Folderul e **in afara** lui `D:\GoogleDrive` intentionat: pana la pasul 2 copiile inca au parolele
inauntru si n-au ce cauta in sincronizarea cu cloud-ul.

Lipsesc din lista, cu motiv: `abcval.tlp` (Bitvise 9.32, respinge Ed25519) si
`bitvise_10.0.20.36.bscp` (acelasi server cu `romfast_bitvise.tlp`, cu parola expirata).


### Lista profilelor pregatite, cu numele scurte

Numele au fost scurtate la copiere; astea sunt fisierele care pleaca pe VM 303 / VM 304 (pe VM
304 stau in `D:\roa\BITVISE\`). Coloana "server" e citita din fisier, fara conectare.

| Fisier (copie) | Original din `D:\GoogleDrive` | Server | Utilizator |
|---|---|---|---|
| `automotive.tlp` | `automotive.tlp` | `78.96.115.213:22122` | `automotive` |
| `avis.tlp` | `avis.tlp` | `86.124.94.107` | `romfast` |
| `clever.tlp` | `clever-motors.tlp` | `clever-motors.go.ro` | `romfast` |
| `conpress.tlp` | `conpress_romfast.tlp` | `185.132.173.105:22322` | `romfast` |
| `eduard.tlp` | `eduard.tlp` | `extra.edituraeduard.ro` | `romfast` |
| `ems.tlp` | `ems.tlp` | `185.132.173.240` | `romfast` |
| `romconstruct.bscp` | `romconstruct.bscp` | `82.76.217.177` | `romfast` |
| `romfast.tlp` | `romfast_bitvise.tlp` | `roadigi.romfast.ro:22122` | `romfast` |
| `sigma.tlp` | `sigma.tlp` | `82.137.26.46` | `romfast` |
| `vadeco.tlp` | `vadeco.tlp` | `100.93.100.75` (Tailscale) | `romfast` |
| `vending.tlp` | `vending.tlp` | `79.119.86.134` | `romfast` |

Trei fisiere au fost redenumite: `clever-motors` → `clever`, `conpress_romfast` → `conpress`,
`romfast_bitvise` → `romfast`. Restul si-au pastrat numele. `romfast.tlp` merge pe copie (a fost
reparat acolo), desi originalul din `D:\GoogleDrive` a ramas fara credentiala.

### Pasul 2 — conversia (GUI, obligatoriu manual)

`-storePw=n` scoate parola, `-pk=a` pune metoda initiala pe publickey cu "orice cheie accepta
serverul" — asa profilul nu depinde de pozitia cheii in managerul angajatului. Ambele sunt
*profile modifications*: se aplica la incarcare, dar **Bitvise nu salveaza profilul din linia de
comanda** ("it will not be saved unless the user manually saves it"), deci Ctrl+S e al tau.

```powershell
Get-ChildItem 'D:\vm303-profile' | ForEach-Object {
  Start-Process -Wait 'C:\Program Files (x86)\Bitvise SSH Client\BvSsh.exe' `
    -ArgumentList "-profile=$($_.FullName)", '-storePw=n', '-pk=a'
}
```

In fiecare fereastra: **Ctrl+S**, apoi inchizi — `-Wait` face bucla sa treaca la urmatorul.

La **`vadeco.tlp`**, inainte de Ctrl+S: Login → **User keypair manager** → scope **Profile** →
sterge keypair-ul de acolo.

### Pasul 3 — verificarea, inainte sa plece ceva spre VM 303

Aceeasi comanda ca la inceputul sectiunii. Dupa conversie, pe **niciun** profil nu mai are voie
sa apara `Attempting password authentication` sau `Signing with client key 'Profile 1'`. Daca
apar, Ctrl+S nu s-a facut pe acel profil — verificarea e singurul lucru care prinde asta, fiindca
fereastra inchisa fara salvare nu da niciun semnal.


Stare la 2026-09-01, dupa conversie: cele 11 copii nu mai incearca nicio metoda pe cont propriu
(parola scoasa, keypair de profil sters la `vadeco`), host key-ul e in continuare in fisier
(`hostkey_prompt=0`), iar cu o cheie furnizata explicit — `-keypairFile=...`, exact ce va face
managerul de keypair-uri al angajatului — **10 din 11 se autentifica**. Al 11-lea, `conpress`,
nu e o problema de profil: si originalul, si copia primesc EOF de la `185.132.173.105:22322`,
adica serverul ne blocheaza temporar IP-ul dupa conexiunile de azi. Se reia mai tarziu.

Atentie la un efect secundar: stergerea keypair-urilor **globale** din User keypair manager (utila
ca sa nu plece cheia mea cu profilele) lasa fara credentiala orice profil care se baza pe ele —
in cazul nostru originalul `romfast_bitvise.tlp`. Se repara importand cheia la loc, sau se
foloseste ruta interna `10.0.20.36:22122` catre acelasi server.

### Pasul 4 — pe VM 303

1. Copiezi folderul (ex. in `C:\profile`).
2. BvSsh → Login → **User keypair manager** → **Import** `C:\Users\romfast\.ssh\id_ed25519`,
   scope **Global**.
3. Test per client — trebuie `Attempting publickey authentication` + `Authentication completed`:

```powershell
& 'C:\Program Files (x86)\Bitvise SSH Client\spksc.exe' -profile=C:\profile\ems.tlp -unat=y -cmd="List Server"
```

### Ce nu rezolva conversia

Stergerea parolei din profil **nu revoca nimic** — parola contului ramane valida pe serverul
clientului si oricine o stie intra in continuare. Daca angajatul nu trebuie sa poata intra cu
parola deloc, parola se schimba pe server sau se dezactiveaza metoda `password` pe cont
(Control Panel → intrarea contului/grupului → Authentication).

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