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:

   & '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.

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:

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

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

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

$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

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

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:

& '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.