238 lines
14 KiB
Markdown
238 lines
14 KiB
Markdown
# 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 ...`).
|
|
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.
|