docs: acces SSH la clienti cu chei publice pentru angajati noi
This commit is contained in:
Marius
237
docs/acces-ssh-chei-angajati.md
Normal file
237
docs/acces-ssh-chei-angajati.md
Normal file
@@ -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\<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.
|
||||
Reference in New Issue
Block a user