francoismichel/ssh3Protocollo shell veloce e sicuro basato su HTTP/3, QUIC e TLS 1.3. Supporta OAuth2, OpenID Connect e l'autenticazione SSH classica con port forwarding UDP e funzionalità di server nascosto.
[!NOTE] SSH3 è probabilmente destinato a cambiare nome. Rimane il protocollo di connessione SSH (RFC4254) eseguito su HTTP/3 Extended connect, ma le modifiche necessarie sono pesanti e troppo lontane dalla filosofia delle implementazioni SSH popolari per essere considerate per l'integrazione. La bozza di specifica è già stata rinominata ("Remote Terminals over HTTP/3"), ma abbiamo bisogno di tempo per trovare un bel nome permanente.
SSH3 è una revisione completa del protocollo SSH, che mappa la sua semantica sui meccanismi HTTP. Nasce dal nostro lavoro di ricerca e noi (ricercatori) lo abbiamo recentemente proposto come Internet-Draft (draft-michel-remote-terminal-http3-00).
In poche parole, SSH3 utilizza QUIC+TLS1.3 per stabilire un canale sicuro e i meccanismi di Autorizzazione HTTP per l'autenticazione degli utenti. Tra gli altri, SSH3 consente i seguenti miglioramenti:
[!TIP] Vuoi iniziare velocemente? Scopri come installare SSH3. Imparerai a configurare un server SSH3 e usare il client SSH3.
Più veloce per lo stabilimento della sessione, non per il throughput! SSH3 offre uno stabilimento della sessione significativamente più veloce di SSHv2. Stabilire una nuova sessione con SSHv2 può richiedere da 5 a 7 round-trip time di rete, cosa facilmente notabile dall'utente. SSH3 necessita solo di 3 round-trip time. La latenza di digitazione in una sessione in esecuzione rimane invariata.
SSH3 (sopra) VS SSHv2 (sotto) stabilimento della sessione con un ping di 100 ms verso il server.
Mentre SSHv2 definisce i propri protocolli per l'autenticazione degli utenti e lo stabilimento del canale sicuro, SSH3 si affida ai meccanismi robusti e collaudati di TLS 1.3, QUIC e HTTP. Questi protocolli sono già ampiamente utilizzati per proteggere applicazioni critiche per la sicurezza su Internet come l'e-commerce e l'home banking.
SSH3 implementa già i comuni metodi di autenticazione basati su password e chiave pubblica (RSA e EdDSA/ed25519). Supporta anche nuovi metodi di autenticazione come OAuth 2.0 e consente di accedere ai propri server utilizzando gli account Google/Microsoft/Github.
Sebbene SSH3 mostri promesse per uno stabilimento più veloce della sessione, è ancora in una fase iniziale di proof-of-concept. Come per ogni nuovo protocollo complesso, è necessaria una revisione crittografica esperta su un periodo esteso prima di poter trarre conclusioni di sicurezza ragionevoli.
Stiamo sviluppando SSH3 come progetto open source per facilitare il feedback e l'analisi della comunità. Tuttavia, non possiamo ancora approvare la sua idoneità per sistemi di produzione senza ulteriore revisione tra pari. Collabora con noi se hai competenze rilevanti!
Dato lo stato attuale di prototipo, consigliamo di testare SSH3 in ambienti sandbox o reti private. Sii consapevole che rendere i server sperimentali direttamente accessibili da Internet potrebbe introdurre rischi prima di una valutazione di sicurezza approfondita.
Sebbene nascondere i server dietro percorsi segreti abbia potenziali benefici, ciò non annulla la necessità di una rigorosa analisi delle vulnerabilità prima di entrare in produzione. Siamo entusiasti delle future possibilità di SSH3 ma incoraggiamo ulteriori controlli prima.
Usando SSH3, puoi evitare il solito stress degli attacchi di scansione e dizionario contro il tuo server SSH. Analogamente ai tuoi documenti segreti di Google Drive, il tuo server SSH3 può essere nascosto dietro un link segreto e rispondere solo ai tentativi di autenticazione che hanno effettuato una richiesta HTTP a questo specifico link, come il seguente:
ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>
Sostituendo <my-long-secret> con, ad esempio, il valore casuale M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU, il tuo server SSH3 risponderà solo ai tentativi di connessione SSH3 effettuati all'URL https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU e risponderà con un 404 Not Found alle altre richieste. Gli attaccanti e i crawler su Internet non possono quindi rilevare la presenza del tuo server SSH3. Vedranno solo un semplice server web che risponde con codici di stato 404 a ogni richiesta.
NOTA BENE: posizionare il tuo server SSH3 dietro un URL segreto può ridurre l'impatto degli attacchi di scansione ma non deve e non potrà mai sostituire i meccanismi di autenticazione classici. Il link segreto dovrebbe essere usato solo per evitare che il tuo host venga scoperto. Conoscere l'URL segreto non dovrebbe concedere a nessuno l'accesso al tuo server. Usa i meccanismi di autenticazione classici descritti sopra per proteggere il tuo server.
SSH3 fornisce nuove funzionalità che non potevano essere fornite dal protocollo SSHv2.
Questa implementazione di SSH3 fornisce già molte delle funzionalità popolari di OpenSSH, quindi se sei abituato a OpenSSH, il processo di adozione di SSH3 sarà agevole. Ecco un elenco di alcune funzionalità di OpenSSH che SSH3 implementa anche:
~/.ssh/authorized_keys sul serverknown_hosts quando non vengono utilizzati certificati X.509.ssh-agent per l'autenticazione a chiave pubblica-proxy-jump). Se A è un client SSH3 e B e C sono entrambi server SSH3, puoi connetterti da A a C usando B come gateway/proxy. Il proxy utilizza l'inoltro UDP per inoltrare i pacchetti QUIC da A a C, quindi B non può decifrare il traffico SSH3 A<->C.~/.ssh/config sul client e gestisce le opzioni di configurazione Hostname, User, Port e IdentityFile (le altre opzioni sono attualmente ignorate). Analizza anche un nuovo UDPProxyJump che si comporta in modo simile al ProxyJump di OpenSSH.Aiutaci a far progredire SSH3 in modo responsabile! Accogliamo con favore ricercatori di sicurezza capaci per esaminare il nostro codice e fornire feedback. Per favore, mettiti anche in contatto con gli organismi di standardizzazione pertinenti per potenzialmente far avanzare SSH3 attraverso i processi formali IETF/IRTF nel tempo.
Con assistenza collaborativa, speriamo di migliorare iterativamente SSH3 verso una preparazione sicura per la produzione. Ma non possiamo fare affermazioni di sicurezza definitive in modo credibile senza prove di un'ampia revisione crittografica esperta e adozione da parte di autorità di sicurezza rispettate. Lavoriamo insieme per realizzare le possibilità di SSH3!
Puoi scaricare gli ultimi binari di rilascio,
installarlo usando go install o generare questi binari da solo compilando il codice dal sorgente.
[!TIP] SSH3 è ancora sperimentale ed è il frutto di un lavoro di ricerca. Se hai paura di distribuire pubblicamente un nuovo server SSH3, puoi utilizzare la funzionalità del percorso segreto di SSH3 per nasconderlo dietro un URL segreto.
go install github.com/francoismichel/ssh3/cmd/...@latest
Hai bisogno di una versione recente di Golang per farlo. Scaricare il codice sorgente e compilare i binari può essere fatto con i seguenti passaggi:
git clone https://github.com/francoismichel/ssh3 # clone the repo
cd ssh3
go build -o ssh3 cmd/ssh3/main.go # build the client
CGO_ENABLED=1 go build -o ssh3-server cmd/ssh3-server/main.go # build the server, requires having gcc installed
Se hai privilegi di root/sudo e vuoi rendere ssh3 accessibile a tutti i tuoi utenti,
puoi quindi copiare direttamente i binari in /usr/bin:
cp ssh3 /usr/bin/ && cp ssh3-server /usr/bin
Altrimenti, puoi semplicemente aggiungere gli eseguibili alla variabile d'ambiente PATH aggiungendo
la seguente riga alla fine del tuo .bashrc o equivalente:
export PATH=$PATH:/path/to/the/ssh3/directory
Prima di connetterti al tuo host, devi distribuire un server SSH3 su di esso. Attualmente non
esiste un demone SSH3, quindi per ora dovrai eseguire l'eseguibile ssh3-server in background
usando screen o un'utilità simile.
[!NOTE] Poiché SSH3 funziona su HTTP/3, un server necessita di un certificato X.509 e della relativa chiave privata. I certificati pubblici possono essere generati automaticamente per il tuo nome di dominio pubblico tramite Let's Encrypt usando l'argomento
-generate-public-certsulla riga di comando del server. Se non vuoi generare un certificato firmato da una vera autorità di certificazione o se non hai un nome di dominio pubblico, puoi generararne uno auto-firmato usando l'argomento-generate-selfsigned-cert. I certificati auto-firmati forniscono garanzie di sicurezza simili al meccanismo di chiave host di SSHv2, con lo stesso problema di sicurezza: potresti essere vulnerabile ad attacchi man-in-the-middle durante la prima connessione al tuo server. Usare certificati reali firmati da autorità di certificazione pubbliche come Let's Encrypt evita questo problema.
Ecco l'utilizzo dell'eseguibile ssh3-server:
Usage of ./ssh3-server:
-bind string
la coppia indirizzo:porta su cui ascoltare, ad es. 0.0.0.0:443 (default "[::]:443")
-cert string
il nome del file del certificato del server (o fullchain) (default "./cert.pem")
-key string
il nome del file della chiave privata del certificato (default "./priv.key")
-enable-password-login
se impostato, abilita l'autenticazione tramite password (disabilitato per impostazione predefinita)
-generate-public-cert value
Produce e utilizza automaticamente un certificato pubblico valido usando Let's Encrypt per il nome di dominio fornito. Il flag può essere usato più volte per generare più certificati. Se i certificati sono già stati generati in precedenza usando questo flag, verranno semplicemente riutilizzati senza essere rigenerati. I certificati pubblici vengono rinnovati automaticamente finché il server è in esecuzione. I certificati pubblici IP generati automaticamente non sono ancora disponibili.
-generate-selfsigned-cert
se impostato, genera un certificato e una chiave auto-firmati che verranno salvati nei percorsi indicati dagli argomenti -cert e -key (non devono già esistere)
-url-path string
il percorso URL segreto su cui il server SSH3 ascolta (default "/ssh3-term")
-v modalità verbosa, se impostata
-version
se impostato, mostra la versione del software sullo standard output ed esce
Il seguente comando avvia un server SSH3 pubblico sulla porta 443 con un certificato pubblico valido di Let's Encrypt per il dominio my-domain.example.org e risponde alle richieste di nuove sessioni che interrogano il percorso URL /ssh3:
ssh3-server -generate-public-cert my-domain.example.org -url-path /ssh3
Se non hai un nome di dominio pubblico (cioè solo un indirizzo IP), puoi usare un certificato esistente per il tuo indirizzo IP usando gli argomenti -cert e -key o generare un certificato auto-firmato usando l'argomento -generate-selfsigned-cert.
Se hai certificati e chiavi esistenti, puoi eseguire il server come segue per usarli=
ssh3-server -cert /path/to/cert/or/fullchain -key /path/to/cert/private/key -url-path /ssh3
[!NOTE] Analogamente a OpenSSH, il server deve essere eseguito con privilegi di root per accedere come altri utenti.
Per impostazione predefinita, il server SSH3 cercherà le identità nei file ~/.ssh/authorized_keys e ~/.ssh3/authorized_identities per ogni utente.
~/.ssh3/authorized_identities consente nuove identità come OpenID Connect (oidc) discusso di seguito.
Tipi di chiave popolari come rsa, ed25519 e chiavi nel formato OpenSSH possono essere utilizzati.
Una volta che hai un server SSH3 in esecuzione, puoi connetterti ad esso usando il client SSH3 in modo simile a quanto facevi con il tuo classico strumento SSHv2.
Ecco l'utilizzo dell'eseguibile ssh3:
Utilizzo di ssh3:
-pubkey-for-agent string
se impostato, usa una chiave agente la cui chiave pubblica corrisponde a quella nel percorso specificato
-privkey string
file della chiave privata
-use-password
se impostato, esegue l'autenticazione classica tramite password
-forward-agent
se impostato, inoltra l'agente ssh per essere utilizzato con connessioni sshv2 sull'host remoto
-forward-tcp string
se impostato, prendi una localport/remoteip@remoteport inoltrando localhost@localport verso remoteip@remoteport
-forward-udp string
se impostato, prendi una localport/remoteip@remoteport inoltrando localhost@localport verso remoteip@remoteport
-proxy-jump string
se impostato, esegue un proxy jump usando l'host remoto specificato come proxy
-insecure
se impostato, salta la verifica del certificato del server
-keylog string
Scrive le chiavi TLS QUIC e il segreto master nel file keylog specificato: solo a scopo di debug
-use-oidc string
se impostato, forza l'uso di OpenID Connect con l'url dell'emittente specificato come parametro
-oidc-config string
file di configurazione json di OpenID Connect contenente i campi "client_id" e "client_secret" necessari per la maggior parte dei provider di identità
-do-pkce
se impostato, esegue la challenge-response PKCE con oidc
-v se impostato, abilita la modalità verbosa
Puoi connetterti al tuo server SSH3 all'indirizzo my-server.example.org in ascolto su /my-secret-path usando la chiave privata situata in ~/.ssh/id_rsa con il seguente comando:
ssh3 -privkey ~/.ssh/id_rsa [email protected]/my-secret-path
Il client SSH3 funziona con l'agente OpenSSH e utilizza la variabile d'ambiente classica SSH_AUTH_SOCK per comunicare con questo agente. Analogamente a OpenSSH, SSH3 elencherà le chiavi fornite dall'agente SSH e si connetterà utilizzando la prima chiave ascoltata dall'agente per impostazione predefinita.
Se vuoi specificare una chiave specifica da usare con l'agente, puoi specificare direttamente la chiave privata con l'argomento -privkey come sopra, o specificare la corrispondente chiave pubblica usando l'argomento -pubkey-for-agent. Questo ti consente di autenticarti in situazioni in cui solo l'agente ha accesso diretto alla chiave privata ma tu hai solo accesso alla chiave pubblica.
Sebbene sconsigliato, puoi connetterti al tuo server usando password (se esplicitamente abilitato su ssh3-server) con il seguente comando:
ssh3 -use-password [email protected]/my-secret-path
ssh3 analizza la tua configurazione OpenSSH. Attualmente, gestisce solo le opzioni OpenSSH Hostname; User, Port e IdentityFile.
Aggiunge anche nuove opzioni usate solo da SSH3, come URLPath o UDPProxyJump. URLPath ti permette di omettere il percorso URL segreto nel tuo comando SSH3. UDPProxyJump ti permette di eseguire un (#proxy-jump)[Proxy Jump] di SSH3 e ha lo stesso significato dell'argomento -proxy-jump della riga di comando.
Supponiamo che tu abbia le seguenti righe nella tua configurazione OpenSSH situata in ~/.ssh/config :
IgnoreUnknown URLPath
Host my-server
HostName 192.0.2.0
User username
IdentityFile ~/.ssh/id_rsa
URLPath /my-secret-path
Analogamente a ciò che fa OpenSSH, il seguente comando ssh3 ti connetterà al server SSH3 in esecuzione su 192.0.2.0 sulla porta UDP 443 usando l'autenticazione a chiave pubblica con la chiave privata situata in .ssh/id_rsa :
ssh3 my-server/my-secret-path
Se non desideri un utilizzo di SSH3 basato su configurazione, puoi leggere le sezioni seguenti per vedere come usare i parametri CLI di ssh3.
Questa funzionalità ti consente di connetterti utilizzando un provider di identità esterno come quello della tua azienda o qualsiasi altro provider che implementa lo standard OpenID Connect, come Google Identity, Github o Microsoft Entra. Il flusso di autenticazione è illustrato nella GIF qui sotto.
Connessione sicura senza chiave privata utilizzando un account Google.
Il modo in cui si connette al tuo provider di identità è configurato in un file chiamato ~/.ssh3/oidc_config.json. Di seguito è riportato un esempio di file config.json per l'uso con un account Google. Questo file di configurazione è un array e può contenere diverse configurazioni di provider di identità.
[
{
"issuer_url": "https://accounts.google.com",
"client_id": "<your_client_id>",
"client_secret": "<your_client_secret>"
}
]
Questo potrebbe cambiare in futuro, ma attualmente, per far funzionare questa funzionalità con il tuo account Google, dovrai configurare una nuova applicazione sperimentale nella console Google Cloud e aggiungere la tua email come utenti autorizzati. Questo ti fornirà un client_id e un client_secret che potrai poi impostare nel tuo ~/.ssh3/oidc_config.json. Sul lato server, devi solo aggiungere la seguente riga nel tuo ~/.ssh3/authorized_identities:
oidc <client_id> https://accounts.google.com <email>
Attualmente stiamo valutando di rimuovere la necessità di impostare il client_id nel file authorized_identities in futuro.
Spesso accade che alcuni host SSH possano essere raggiunti solo attraverso un gateway. SSH3 ti consente di eseguire un Proxy Jump in modo simile a quanto proposto da OpenSSH. Puoi connetterti da A a C usando B come gateway/proxy. B e C devono essere entrambi in esecuzione con un server SSH3 valido. Funziona stabilendo un inoltro porte UDP su B per inoltrare i pacchetti QUIC da A a C. La connessione da A a C è quindi completamente end-to-end e B non può decifrare o alterare il traffico SSH3 tra A e C.