programersigurnostilozinke

Kako sigurno dijeliti SSH ključeve (bez Slacka, e-pošte ili Git povijesti)

20. srpnja 2026.7 min čitanja

Javni ključevi smiju se dijeliti. Privatni ne. Kada izbjeći predaju privatnog ključa, kako ga isporučiti jednokratnim šifriranim linkom i koje PrivateNote ekstenzije drže PEM izvan chata.

Privatni SSH ključevi spadaju u enkriptirane, kratkotrajne predaje—ne u Slack, e-mail ili git povijest. Slika: programerski radni stol putem Pixabaya.

Kolegi je potreban pristup staging poslužitelju. Izvođaču je potreban deploy key za vikend. Nekome je laptop prestao raditi, a jedini preostali pristup je privatni ključ na vašem računalu.

Najbrži put je obično ista loša navika: zalijepiti PEM blok u Slack, poslati ga e-poštom „samo ovaj put“, ili ga ostaviti u tiketu. Ta poruka se sinkronizira na telefone, završava u indeksima za pretraživanje, i može ostati u sigurnosnim kopijama dugo nakon što je hitna situacija prošla.

Privatni SSH ključevi su tajne s velikim radijusom štete. Jedan procureni ključ može značiti potpuni shell pristup. Ovaj vodič objašnjava kada uopće treba dijeliti privatni ključ, što nikad ne treba zalijepiti u chat, i kako ga predati putem enkriptiranog linka koji se briše nakon čitanja (burn-after-reading)—plus PrivateNote ekstenzije za developere koje čine sigurni put i brzim putem.

Javni ključ naspram privatnog ključa (30 sekundi jasnoće)

SSH par ključeva ima dvije polovice. Javni ključ namijenjen je dijeljenju: dodajete ga u ~/.ssh/authorized_keys, cloud konzolu, ili GitHub deploy key. Slanje nečijeg javnog ključa u chatu je normalno.

Privatni ključ (id_ed25519, id_rsa, datoteka .pem) je tajna. Tko god ga posjeduje može se autenticirati kao ta identičnost sve dok ne opozovete pristup. Tretirajte ga kao lozinku koja otključava poslužitelj—jer to je točno to.

Ako vam instinkt govori „moramo dijeliti privatni ključ“, zastanite. U mnogim slučajevima trebali biste umjesto toga dijeliti javni ključ: primatelj lokalno generira svoj par, a vi autorizirate njegov javni ključ na hostu.

Pravilo palca
Bolje je dodati njihov javni ključ nego slati svoj privatni ključ. Predaje privatnog ključa su za hitne slučajeve (break-glass) i legacy situacije—ne za standardni onboarding.

Bolje je ne dijeliti privatni ključ

Prije nego što bilo što enkriptirate i pošaljete, pitajte se treba li privatni ključ uopće premjestiti:

Dodajte njihov javni ključ

Neka pokrenu ssh-keygen, pošalju vam .pub datoteku (sigurno u chatu), i dodaju je u authorized_keys ili SSH postavke pružatelja usluge. Oni čuvaju privatnu polovicu; vi je nikad ne vidite.

Koristite namjenski deploy key

Za CI ili jedan repozitorij, izradite namjenski deploy key s minimalnim opsegom. Izbjegavajte ponovnu upotrebu osobnog laptop ključa na više sustava.

Preferirajte kratkotrajan pristup

Gdje vaš stack to podržava—SSH certifikati, bastion/jump host poslužitelji, Tailscale SSH, cloud IAM uloge—preferirajte vremenski ograničen pristup umjesto kopiranja dugotrajnih privatnih ključeva.

Kada je predaja privatnog ključa opravdana

Hitni pristup (break-glass) kod oporavka, legacy host koji ne može brzo registrirati nove ključeve, ili hitna situacija u kojoj postoji samo jedan ključ zaštićen passphraseom. I tada: enkriptirajte prijenos, držite kratak istek, potvrdite prijem, zatim rotirajte ili opozovite.

Gdje SSH ključevi umiru u praksi

Isti kanali koji propuštaju API ključeve i lozinke propuštaju i SSH materijal—često s gorim posljedicama.

Kanal	Zašto ne uspijeva	Što napadači dobivaju
Slack, Teams, Discord	Pretraživa povijest, sinkronizacija uređaja, izvozi radnog prostora	Kompletan privatni ključ u čistom tekstu, zauvijek
E-pošta	Pretinci, arhive, mobilna sinkronizacija, prosljeđivanja	Trajna kopija koju ne možete pouzdano obrisati
Tiketi i dokumenti	Jira, Notion, Confluence, GitHub issuei	Ključevi u sigurnosnim kopijama, AI pretraživanju i audit tragovima
Git repozitoriji	Povijest ostaje; „obriši i pushaj“ ne briše ništa	Skeneri pronalaze PEM datoteke u minutama na javnim repozitorijima

Ako se tajna već pojavila u chatu ili gitu, pretpostavite da je izgorjela. Opozovite ključ, generirajte novi par, i isporučite zamjenu putem jednokratnog enkriptiranog linka—ne novim lijepljenjem. Za curenja pipelinea i .env datoteka, pogledajte tajne u CI/CD-u i GitHubu.

Sigurnija predaja privatnog SSH ključa

Kada morate premjestiti privatni ključ, tretirajte prijenos kao privremenu isporuku—ne kao pohranu. Isti obrazac koji se koristi za lozinke i API ključeve primjenjuje se: enkriptirajte lokalno, pošaljite link, izbrišite nakon čitanja, zatim rotirajte.

PrivateNote enkriptira u pregledniku (ili u vašem editoru/CLI-u) s AES-256-GCM prije nego bilo što stigne do mreže. Ključ za dešifriranje živi samo u URL fragmentu—dijelu #… koji preglednici nikad ne šalju poslužiteljima. Detalji: što enkripcija od kraja do kraja znači ovdje i kako napraviti privatnu bilješku.

Praktičan radni tijek za hitne slučajeve (break-glass):

1
Korak 1
Ograničite i zaštitite ključ
Preferirajte namjenski ključ za ovaj host ili zadatak. Koristite passphrase na privatnom ključu. Izbjegavajte slanje svog svakodnevnog osobnog identitetskog ključa ako je dovoljan uži ključ.
2
Korak 2
Enkriptirajte lokalno
Zalijepite samo materijal ključa (ne roman od hostnameova i korisničkih imena) u PrivateNote putem web aplikacije, VS Code / Cursor ekstenzije, CLI-a, ili Chrome ekstenzije.
3
Korak 3
Pošaljite link—ne PEM
Podijelite enkriptirani link u Slacku ili e-poštom. Opcionalno aktivirajte omatanje passphraseom i pošaljite tu passphrase preko odvojenog kanala (savjet za odvojene kanale). Preferirajte istek od 15 minuta ili 1 sat i brisanje nakon čitanja.
4
Korak 4
Potvrdite, zatim rotirajte
Primatelj instalira ključ s ispravnim dozvolama (chmod 600), potvrđuje prijavu, zatim vi opozivate stari ključ ili ga rotirate. Tretirajte svaki ključ koji je bio u AI promptu kao viđen—rotirajte ga.

Trebate predati SSH ključ sada? Kreirajte enkriptiranu jednokratnu bilješku i pošaljite link umjesto privatnog ključa.

Kreiraj privatnu bilješku

Ekstenzije za developere: dijelite SSH ključeve odakle radite

Predaje ne uspijevaju kada je sigurni alat tri klika dalje od Slacka. PrivateNote integracije čuvaju enkripciju u vašem editoru, pregledniku, terminalu ili agent workflowu. Kompletan pregled: PrivateNote za developere.

Vaša situacija	Najbolji put
Ključ je već otvoren u editoru	VS Code / Cursor / Codex IDE ekstenzija — odaberi → podijeli kao PrivateNote
Ključ je na web stranici ili tiketu	Chrome ekstenzija — označi → Kreiraj PrivateNote
Nalazite se u terminalu	CLI — pipe-ajte datoteku da PEM nikad ne bude u shell povijesti
Želite da agent generira link	MCP poslužitelj — zatim rotirajte; preferirajte editor ekstenziju za privatne ključeve
Primatelj nije tehnički potkovan	Link web aplikacije na privatenote.ai

VS Code, Cursor i Codex IDE

Instalirajte iz marketplacea (PrivateNote.privatenote-vscode), odaberite blok ključa, i koristite Share as PrivateNote—ili otvorite composer u sidebaru. Enkripcija se izvršava u host procesu editora, tako da čisti tekst nikad ne mora ući u AI chat. Postavljanje: VS Code / Cursor ekstenzija.

Chrome ekstenzija

Kad se ključ pojavi u tiketu, stranici dokumentacije ili admin konzoli, označite ga i kreirajte enkriptiranu bilješku bez prethodnog kopiranja u Slack. Instalacija: Chrome ekstenzija.

CLI

Pipe-ajte iz datoteke tako da tajna ne bude echo argument u shell povijesti: cat id_ed25519 | npx privatenote-cli --expire 15m --output-url-only. Dokumentacija: PrivateNote CLI.

MCP za Cursor, Claude i Codex

Agenti mogu pozvati create_private_note nakon što instalirate privatenote-mcp. Korisno za orkestraciju—ali ako zalijepite privatni ključ u agent prompt, pružatelj modela ga možda vidi prije enkripcije. Za privatne SSH ključeve preferirajte editor ili Chrome ekstenziju. Postavljanje specifično za Codex: PrivateNote s Codexom.

Iskrena napomena
MCP enkriptira nakon što agent pročita prompt. Trajna izloženost u chatu/e-pošti nestaje; vidljivost AI pružatelja ne. Za privatne ključeve koristite VS Code ili Chrome ekstenziju tako da čisti tekst nikad ne napusti vaše računalo prije nego što već bude šifrirani tekst.

Najbolje prakse i zamke

Nikad ne commitajte privatne ključeve

Držite id_* i *.pem izvan repozitorija. Dodajte ih u .gitignore. Ako je ključ dospio u git povijest, rotirajte ga—prepisivanje povijesti više nije dovoljno kad je repozitorij jednom kloniran ili skeniran.

Ispravite dozvole datoteka

Privatni ključevi trebali bi imati chmod 600 (ili 400). SSH će na mnogim sustavima odbiti previše dopuštene datoteke ključeva—a ključevi koje svi mogu čitati na zajedničkim računalima su gol u svoju mrežu.

Ne stavljajte kontekst unutar bilješke

Stavite samo materijal ključa u enkriptiranu bilješku. Pošaljite hostname, korisničko ime i port u zasebnoj poruci. Ako link procuri, napadač ne bi trebao dodatno dobiti i oznakovanu kartu onoga što otključava.

Passphrase i odvojeni kanali

Zaštitite passphraseom samu datoteku ključa, i opcionalno omotajte PrivateNote sa zasebnom passphrase poslanom preko drugog kanala. Isti savjet kao za sigurno dijeljenje lozinke.

Prosljeđivanje agenta nije strategija dijeljenja

SSH agent forwarding može smanjiti kopije ključeva na udaljenim hostovima, ali nije zamjena za pažljivu distribuciju ključeva—i proširuje povjerenje na svaki hop kroz koji prosljeđujete. Koristite ga namjerno, ne kao izgovor za slanje PEM datoteka e-poštom.

Često postavljana pitanja

Je li sigurno slati javni ključ u Slacku?

Da. Javni ključevi namijenjeni su distribuciji. Ipak izbjegavajte izbacivanje čitavih ~/.ssh mapa—ljudi nenamjerno uključe privatne datoteke.

Mogu li staviti privatni SSH ključ u upravitelja lozinki?

Za dugoročno čuvanje ključeva koje zadržavate, upravitelj lozinki ili agent podržan hardverom je adekvatan. Koristite jednokratni enkriptirani link za trenutak predaje od čovjeka do čovjeka—zatim primatelj pravilno pohranjuje ključ. PrivateNote je isporuka, ne trezor tajni.

Trebam li dijeliti ključ i passphrase zajedno?

Ne. To ponovno stvara jednu točku kvara. Pošaljite enkriptirani link na jednom kanalu, a bilo koju passphrase na drugom—ili neka primatelj postavi svoju passphrase nakon instalacije i rotira je.

Koji istek trebam koristiti?

Za koordinaciju u stvarnom vremenu, 15 minuta s brisanjem nakon čitanja. Za asinkrone predaje izvođačima, najviše 1 sat ili 1 dan. Preferirajte kraće kad god je primatelj dostupan.

Je li PrivateNote zamjena za Vault ili cloud upravitelje tajni?

Ne. Koristite Vault, AWS Secrets Manager i slične alate za pohranu i injekciju stroj-stroj. Koristite PrivateNote za trenutak čovjek-čovjek kad ključ mora prijeći chat ili e-poštu bez da postane trajna arhiva. Ista razlika kao u vodiču za API ključeve.

Zaključne misli

Većina SSH problema „dijeljenja“ su zapravo problemi registracije: dodajte javni ključ, koristite deploy key, ili izdajte kratkotrajan pristup. Kad privatni ključ mora premjestiti, ne ostavljajte ga u povijesti chata ili e-pošti.

Enkriptirajte lokalno, pošaljite link koji se sam briše, potvrdite instalaciju, zatim rotirajte. Povežite alate za developere koje već koristite tako da sigurni put bude i put najmanjeg otpora.

Dijelite link—ne privatni ključ

Kreirajte PrivateNote enkriptiranu u pregledniku s kratkim istekom i brisanjem nakon čitanja. Ili enkriptirajte iz VS Code ekstenzije, CLI-a, ili Chrome ekstenzije tako da PEM nikad ne stigne u čistom tekstu u Slack.