sviluppatoresicurezzapassword

Come condividere chiavi SSH in modo sicuro (senza Slack, email o cronologia Git)

20 luglio 20267 minuti di lettura

Le chiavi pubbliche si possono condividere. Quelle private no. Quando evitare il passaggio di una chiave privata, come consegnarla con un link cifrato monouso e quali estensioni PrivateNote tengono i PEM fuori dalla chat.

Le chiavi private SSH appartengono a passaggi cifrati e di breve durata—non a Slack, e-mail o cronologia git. Immagine: scrivania di programmazione via Pixabay.

Un collega deve accedere al server di staging. Un collaboratore ha bisogno di una chiave di deploy per il weekend. Il laptop di qualcuno si è rotto e l'unico accesso rimasto è la chiave privata sul tuo computer.

Il percorso più rapido è di solito la stessa cattiva abitudine: incollare il blocco PEM in Slack, inviarlo per e-mail «solo questa volta», o inserirlo in un ticket. Quel messaggio si sincronizza sui telefoni, finisce negli indici di ricerca, e può restare nei backup molto dopo la fine dell'emergenza.

Le chiavi private SSH sono segreti con un ampio raggio d'impatto. Una sola chiave trapelata può significare accesso shell completo. Questa guida spiega quando dovresti condividere una chiave privata, cosa non incollare mai in chat, e come consegnarne una con un link cifrato ad autodistruzione dopo la lettura—più le estensioni per sviluppatori di PrivateNote che rendono il percorso sicuro anche quello veloce.

Chiave pubblica vs chiave privata (30 secondi di chiarezza)

Una coppia di chiavi SSH ha due metà. La chiave pubblica è pensata per essere condivisa: la aggiungi a ~/.ssh/authorized_keys, a una console cloud, o a una deploy key di GitHub. Inviare la chiave pubblica di qualcuno in chat è normale.

La chiave privata (id_ed25519, id_rsa, un file .pem) è il segreto. Chiunque la possieda può autenticarsi come quell'identità finché non revochi l'accesso. Trattala come una password che apre un server—perché è esattamente questo che è.

Se il tuo istinto dice «dobbiamo condividere la chiave privata», fermati. In molti casi dovresti invece condividere la chiave pubblica: il destinatario genera la propria coppia in locale e tu autorizzi la sua chiave pubblica sull'host.

Regola pratica
Preferisci aggiungere la loro chiave pubblica piuttosto che inviare la tua chiave privata. I passaggi di chiave privata sono per casi di recupero di emergenza (break-glass) e casi legacy—non per l'onboarding predefinito.

Preferisci non condividere la chiave privata

Prima di cifrare e inviare qualsiasi cosa, chiediti se la chiave privata deve davvero essere spostata:

Aggiungi la loro chiave pubblica

Falli eseguire ssh-keygen, farti inviare il file .pub (sicuro in chat), e aggiungerlo ad authorized_keys o alle impostazioni SSH del provider. Loro conservano la metà privata; tu non la vedi mai.

Usa una chiave di deploy dedicata

Per la CI o un singolo repository, crea una chiave di deploy dedicata con l'ambito minimo. Evita di riutilizzare una chiave personale del laptop su più sistemi.

Preferisci l'accesso a breve termine

Dove il tuo stack lo supporta—certificati SSH, host bastione (jump host), Tailscale SSH, ruoli IAM cloud—preferisci un accesso limitato nel tempo rispetto a copiare chiavi private a lunga durata.

Quando il passaggio di una chiave privata è giustificato

Recupero di emergenza (break-glass), un host legacy che non può registrare rapidamente nuove chiavi, o un'emergenza in cui esiste solo una chiave protetta da passphrase. Anche in quel caso: cifra il trasferimento, mantieni una scadenza breve, confermane la ricezione, poi ruota o revoca.

Dove muoiono le chiavi SSH nella realtà

Gli stessi canali che fanno trapelare chiavi API e password fanno trapelare anche materiale SSH—spesso con conseguenze peggiori.

Canale	Perché fallisce	Cosa ottengono gli attaccanti
Slack, Teams, Discord	Cronologia ricercabile, sincronizzazione dispositivi, esportazioni del workspace	Chiave privata completa in chiaro per sempre
E-mail	Caselle di posta, archivi, sincronizzazione mobile, inoltri	Una copia duratura che non puoi eliminare in modo affidabile
Ticket e documenti	Jira, Notion, Confluence, issue di GitHub	Chiavi in backup, ricerca IA e audit trail
Repository Git	La cronologia è persistente; «elimina e fai push» non elimina nulla	Gli scanner trovano PEM in pochi minuti nei repo pubblici

Se il segreto è già apparso in chat o su git, considéralo compromesso. Revoca la chiave, genera una nuova coppia, e consegna la sostituzione tramite un link cifrato monouso—non un altro copia-incolla. Per fughe di pipeline e .env, vedi segreti in CI/CD e GitHub.

Un passaggio più sicuro delle chiavi private SSH

Quando devi spostare una chiave privata, tratta il trasferimento come consegna temporanea—non come archiviazione. Si applica lo stesso schema usato per password e chiavi API: cifra in locale, invia un link, distruggi dopo la lettura, poi ruota.

PrivateNote cifra nel browser (o nel tuo editor/CLI) con AES-256-GCM prima che qualcosa raggiunga la rete. La chiave di decifratura vive solo nel fragment dell'URL—la parte #… che i browser non inviano mai ai server. Dettagli: cosa significa qui la cifratura end-to-end e come creare una nota privata.

Un flusso di lavoro pratico per il break-glass:

1
Passo 1
Delimita e proteggi la chiave
Preferisci una chiave dedicata per questo host o compito. Usa una passphrase sulla chiave privata. Evita di spedire la tua chiave d'identità personale quotidiana se basta una chiave più ristretta.
2
Passo 2
Cifra in locale
Incolla solo il materiale della chiave (non un romanzo di hostname e username) in PrivateNote tramite la web app, l'estensione VS Code / Cursor, la CLI, o l'estensione Chrome.
3
Passo 3
Invia il link—non il PEM
Condividi il link cifrato su Slack o via e-mail. Attiva opzionalmente l'incapsulamento con passphrase e invia quella passphrase su un canale separato (suggerimento sui canali separati). Preferisci una scadenza di 15 minuti o 1 ora e l'autodistruzione dopo la lettura.
4
Passo 4
Conferma, poi ruota
Il destinatario installa la chiave con i permessi corretti (chmod 600), conferma l'accesso, poi revochi o ruoti la vecchia chiave. Considera qualsiasi chiave finita in un prompt IA come vista—ruotala.

Devi consegnare una chiave SSH ora? Crea una nota cifrata monouso e invia il link invece della chiave privata.

Crea una nota privata

Estensioni per sviluppatori: condividi chiavi SSH da dove lavori

I passaggi falliscono quando lo strumento sicuro è a tre clic di distanza in più rispetto a Slack. Le integrazioni PrivateNote mantengono la cifratura nel tuo editor, browser, terminale o flusso di lavoro dell'agente. Tour completo: PrivateNote per sviluppatori.

La tua situazione	Percorso migliore
La chiave è già aperta nell'editor	Estensione IDE VS Code / Cursor / Codex — seleziona → condividi come PrivateNote
La chiave è su una pagina web o un ticket	Estensione Chrome — evidenzia → Crea PrivateNote
Sei in un terminale	CLI — incanala il file così il PEM non finisce mai nella cronologia della shell
Vuoi che un agente produca il link	Server MCP — poi ruota; preferisci l'estensione dell'editor per le chiavi private
Il destinatario non è tecnico	Link della web app su privatenote.ai

VS Code, Cursor e Codex IDE

Installa dal marketplace (PrivateNote.privatenote-vscode), seleziona il blocco della chiave, e usa Share as PrivateNote—oppure apri il composer nella sidebar. La cifratura viene eseguita nel processo host dell'editor, quindi il testo in chiaro non deve mai entrare in una chat IA. Configurazione: estensione VS Code / Cursor.

Estensione Chrome

Quando una chiave appare in un ticket, una pagina di documentazione o una console di amministrazione, evidenziala e crea una nota cifrata senza copiarla prima in Slack. Installazione: estensione Chrome.

CLI

Incanala da un file così il segreto non è un argomento di echo nella cronologia della shell: cat id_ed25519 | npx privatenote-cli --expire 15m --output-url-only. Documentazione: CLI di PrivateNote.

MCP per Cursor, Claude e Codex

Gli agenti possono chiamare create_private_note dopo aver installato privatenote-mcp. Utile per l'orchestrazione—ma se incolli la chiave privata nel prompt dell'agente, il fornitore del modello potrebbe vederla prima della cifratura. Per le chiavi private SSH, preferisci l'estensione dell'editor o di Chrome. Configurazione specifica per Codex: PrivateNote con Codex.

Un'avvertenza onesta
MCP cifra dopo che l'agente ha letto il prompt. L'esposizione persistente in chat/e-mail scompare; la visibilità del fornitore IA no. Per le chiavi private, usa l'estensione VS Code o Chrome così il testo in chiaro non lascia mai il tuo computer prima di essere già testo cifrato.

Buone pratiche e insidie

Non fare mai commit delle chiavi private

Tieni id_* e *.pem fuori dai repository. Aggiungili al .gitignore. Se una chiave è finita nella cronologia git, ruotala—riscrivere la cronologia non basta più una volta che il repository è stato clonato o scansionato.

Correggi i permessi dei file

Le chiavi private dovrebbero essere chmod 600 (o 400). SSH rifiuterà file di chiave troppo permissivi su molti sistemi—e chiavi leggibili da chiunque su macchine condivise sono un autogol.

Non inserire contesto nella nota

Metti solo il materiale della chiave nella nota cifrata. Invia hostname, username e porta in un messaggio separato. Se il link trapela, l'attaccante non dovrebbe ottenere anche una mappa etichettata di ciò che sblocca.

Passphrase e canali separati

Proteggi con passphrase il file della chiave stesso, e opzionalmente incapsula la PrivateNote con una passphrase separata inviata su un altro canale. Stessa raccomandazione della condivisione sicura delle password.

Il forwarding dell'agente non è una strategia di condivisione

Il forwarding dell'agente SSH può ridurre le copie di chiave sugli host remoti, ma non sostituisce una distribuzione attenta delle chiavi—ed estende la fiducia a ogni hop attraverso cui esegui il forwarding. Usalo deliberatamente, non come scusa per inviare PEM via e-mail.

Domande frequenti

È sicuro inviare una chiave pubblica su Slack?

Sì. Le chiavi pubbliche sono pensate per essere distribuite. Evita comunque di scaricare interi directory ~/.ssh—le persone includono per errore file privati.

Posso mettere una chiave privata SSH in un password manager?

Per l'archiviazione a lungo termine delle chiavi che conservi, un password manager o un agente basato su hardware è appropriato. Usa un link cifrato monouso per il momento di consegna da persona a persona—poi il destinatario archivia correttamente la chiave. PrivateNote è consegna, non un vault di segreti.

Dovrei condividere la chiave e la passphrase insieme?

No. Questo ricrea un singolo punto di fallimento. Invia il link cifrato su un canale e qualsiasi passphrase su un altro—oppure fai impostare al destinatario la propria passphrase dopo l'installazione e ruotala.

Quale scadenza dovrei usare?

Per il coordinamento in tempo reale, 15 minuti con autodistruzione dopo la lettura. Per passaggi asincroni a collaboratori esterni, massimo 1 ora o 1 giorno. Preferisci una durata più breve ogni volta che il destinatario è raggiungibile.

PrivateNote è un sostituto di Vault o dei gestori di segreti cloud?

No. Usa Vault, AWS Secrets Manager e strumenti simili per l'archiviazione e l'iniezione machine-to-machine. Usa PrivateNote per il momento da persona a persona quando una chiave deve attraversare chat o e-mail senza diventare un archivio permanente. Stessa distinzione della guida alle chiavi API.

Considerazioni finali

La maggior parte dei problemi di «condivisione» SSH sono in realtà problemi di iscrizione: aggiungi una chiave pubblica, usa una chiave di deploy, o emetti un accesso a breve termine. Quando una chiave privata deve essere spostata, non lasciarla nella cronologia della chat o nell'e-mail.

Cifra in locale, invia un link ad autodistruzione, conferma l'installazione, poi ruota. Collega gli strumenti per sviluppatori che già usi così che il percorso sicuro sia anche il percorso di minore resistenza.

Condividi il link—non la chiave privata

Crea una PrivateNote cifrata nel browser con scadenza breve e autodistruzione dopo la lettura. Oppure cifra dall'estensione VS Code, dalla CLI, o dall'estensione Chrome così il PEM non finisce mai in chiaro su Slack.