Come installare OpenSSH con Winget su Windows 11 e 10

Su Windows 11 e Windows 10, OpenSSH può essere installato e gestito senza passare dal vecchio ciclo di download manuale: con Winget riduci errori, mantieni una traccia chiara del pacchetto e puoi standardizzare il setup su più macchine. La parte importante non è solo “installarlo”, ma capire cosa cambia davvero: servizio, firewall, chiavi, permessi e modalità di accesso.

In pratica hai due componenti da tenere distinti: OpenSSH Client, che serve a connetterti ad altri host, e OpenSSH Server, che trasforma il PC Windows in una macchina raggiungibile via SSH. Molti installano il client e pensano di aver abilitato anche il server: non è così. Se vuoi accedere da remoto al PC, devi installare e avviare il servizio corretto, oltre ad aprire la porta in ingresso.

Verifica preliminare: Winget e stato del sistema

Prima di toccare il sistema, conviene verificare che Winget sia presente e che la macchina non abbia già OpenSSH installato tramite le funzionalità opzionali di Windows. Questo evita doppie installazioni o confusione tra pacchetto App Installer e feature di sistema.

Apri PowerShell o Windows Terminal come utente normale per il controllo iniziale e poi, se serve, come amministratore per l’installazione del server.

winget --version
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
Get-Service sshd -ErrorAction SilentlyContinue

Interpretazione rapida: se winget --version risponde con una versione, il gestore pacchetti è disponibile. Se Get-WindowsCapability mostra OpenSSH.Client* o OpenSSH.Server* come Installed, il componente è già presente come feature. Se Get-Service sshd restituisce un servizio, il server SSH è già stato installato almeno una volta.

Installare OpenSSH Client con Winget

Il client è la scelta più semplice: serve per collegarti in SSH a server Linux, appliance, switch, ambienti cloud e anche ad altri host Windows con OpenSSH Server attivo. Su macchine di supporto e postazioni amministrative è spesso il pacchetto più utile da standardizzare.

Per installarlo con Winget:

winget install --id Microsoft.OpenSSH.Client -e

L’opzione -e forza il match esatto dell’ID e riduce il rischio di prendere un pacchetto sbagliato. Se il client è già presente, Winget lo dirà chiaramente. Dopo l’installazione, verifica la presenza di ssh.exe e scp.exe:

where ssh
ssh -V
where scp

Se ssh -V mostra la versione OpenSSH e i binari sono nel PATH, puoi usare subito il client da terminale. In molti casi non serve altro.

Installare OpenSSH Server con Winget su Windows 11 e 10

Per rendere il PC raggiungibile via SSH devi installare il server. Anche qui Winget è comodo, ma su alcune build di Windows il server può essere distribuito come funzionalità opzionale del sistema: se il pacchetto Winget non è disponibile o non si comporta come previsto, il fallback corretto è la feature di Windows, non un workaround improvvisato.

Comando tipico con Winget:

winget install --id Microsoft.OpenSSH.Server -e

Se il pacchetto viene installato correttamente, il servizio sshd dovrebbe comparire nel sistema. Verificalo subito:

Get-Service sshd
Get-Service ssh-agent

Il servizio sshd gestisce le connessioni in ingresso. ssh-agent è opzionale ma utile se vuoi gestire chiavi private con meno attrito operativo. Non confondere i due ruoli.

Avvio del servizio e attivazione automatica

Dopo l’installazione, il punto critico è rendere il servizio persistente. Su un server o su una workstation usata per amministrazione remota, non vuoi doverlo avviare manualmente a ogni riavvio.

Start-Service sshd
Set-Service -Name sshd -StartupType Automatic
Get-Service sshd

Il risultato atteso è Running. Se il servizio resta fermo, la causa va cercata nei log di Windows e nella configurazione della porta o delle chiavi host. In questa fase non cambiare più variabili del necessario: prima fai partire il demone, poi controlla il resto.

Aprire la porta nel firewall di Windows

Un server SSH installato ma non raggiungibile spesso è solo bloccato dal firewall locale. La porta standard è 22/TCP. Se hai una policy diversa, documentala subito: cambiare porta senza traccia crea problemi inutili sia in troubleshooting sia in auditing.

Controlla la regola già presente e, se serve, aggiungila in modo esplicito:

Get-NetFirewallRule | Where-Object DisplayName -like '*OpenSSH*'
New-NetFirewallRule -Name OpenSSH-Server-In-TCP -DisplayName 'OpenSSH Server (sshd)' -Enabled True -Direction Inbound -Protocol TCP -Action Allow -LocalPort 22

Se la macchina è in un ambiente gestito da GPO o da un firewall endpoint centralizzato, la regola locale può essere sovrascritta. In quel caso il controllo corretto non è “riprovare a caso”, ma verificare la policy applicata e l’eventuale blocco a livello di profilo rete.

Verificare che SSH ascolti davvero

Il controllo più utile è capire se il servizio è in ascolto sulla porta prevista. Questo chiude subito il dubbio tra problema di servizio, problema di firewall e problema di rete esterna.

netstat -ano | findstr :22
Test-NetConnection -ComputerName localhost -Port 22

Se netstat mostra LISTENING su :22, il demone è vivo. Se Test-NetConnection verso localhost fallisce, il problema è locale: servizio non avviato, configurazione errata o binding non corretto. Se funziona in locale ma non da un altro host, il sospetto si sposta su firewall o rete.

Configurazione minima utile: chiavi host e accesso utente

La configurazione base di OpenSSH su Windows non richiede file esotici, ma richiede ordine. Il server usa un set di chiavi host che identifica la macchina, mentre l’accesso utente si basa sulle chiavi nel profilo o su password, se abilitate. In produzione, la scelta più pulita è usare chiavi e limitare le password dove possibile.

Le chiavi host si trovano in genere sotto C:\ProgramData\ssh\. Le chiavi utente, invece, vanno sotto %USERPROFILE%\.ssh\. Il punto operativo è semplice: se l’utente con cui ti connetti non ha i permessi corretti sulla cartella o sul file authorized_keys, l’autenticazione fallisce anche se il servizio è sano.

Per creare una coppia di chiavi sul client Windows:

ssh-keygen -t ed25519 -a 64

La scelta ed25519 è pratica perché moderna, veloce e con chiavi compatte. Se devi interoperare con vecchi sistemi, potresti dover usare RSA, ma non farlo per inerzia: fallo solo se il target lo richiede davvero.

Primo accesso e test da un altro host

Una volta attivo il server, il test vero va fatto da un host diverso, non dalla stessa macchina. Collegarsi in locale è utile per isolare il livello servizio, ma non dimostra che la rete sia aperta verso l’esterno.

ssh nomeutente@IP_DEL_PC_WINDOWS

Se la connessione è la prima verso quell’host, vedrai la richiesta di conferma dell’impronta della chiave host. Qui bisogna fare attenzione operativa: verifica che l’IP o il nome host corrispondano davvero alla macchina attesa prima di accettare la fingerprint.

Se usi una chiave privata specifica:

ssh -i C:\Users\NomeUtente\.ssh\id_ed25519 nomeutente@IP_DEL_PC_WINDOWS

In ambienti con più identità, questo evita di affidarsi al comportamento implicito dell’agent o alla selezione automatica delle chiavi. Meno magia, meno errori.

Se Winget non trova OpenSSH Server

Capita che il catalogo Winget non restituisca l’ID atteso, oppure che il pacchetto sia disponibile solo in certe build o canali. Non è un blocco: il piano B corretto è usare la funzionalità opzionale di Windows, che spesso è la strada più stabile per il server SSH su Windows 10 e 11.

Installa la feature integrata:

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Se lavori in un ambiente con restrizioni di rete, il download della capability può fallire perché il sistema non riesce a raggiungere le sorgenti Microsoft. In quel caso non è un problema di SSH: è un problema di servicing di Windows. Il controllo utile è il log di installazione delle funzionalità e la connettività verso i repository richiesti dall’host.

Log utili quando qualcosa non torna

Se il servizio non parte o l’autenticazione fallisce, i punti da guardare sono pochi ma decisivi. I log di OpenSSH su Windows stanno in genere sotto C:\ProgramData\ssh\logs\ se la configurazione li abilita, mentre gli eventi di sistema e applicazione possono dare il contesto che manca.

Controlli rapidi:

Get-WinEvent -LogName Application -MaxEvents 20 | Format-Table TimeCreated, Id, ProviderName, Message -AutoSize
Get-WinEvent -LogName System -MaxEvents 20 | Format-Table TimeCreated, Id, ProviderName, Message -AutoSize

Se vuoi capire se il problema è di autenticazione, cerca messaggi legati a chiavi, permessi o tentativi falliti. Se invece non trovi neppure un evento relativo a sshd, è più probabile che il servizio non sia partito correttamente o che si sia arrestato subito dopo l’avvio.

Uso pratico: perché conviene su Windows 11 e 10

Il vantaggio vero non è “avere SSH”, ma integrare Windows in flussi già standardizzati. Puoi copiare file con scp, fare tunnel con -L, usare automazioni da Linux o da altri host Windows, e amministrare macchine remote senza dipendere da strumenti proprietari o sessioni grafiche.

Per esempio, un tunnel locale verso un servizio esposto solo sul PC Windows:

ssh -L 8080:localhost:80 nomeutente@IP_DEL_PC_WINDOWS

In questo scenario, il traffico passa cifrato fino all’host Windows e il servizio interno resta non esposto direttamente sulla rete. È una configurazione semplice, ma molto più pulita di tante aperture inutili sul firewall.

Hardening minimo che vale la pena fare subito

Se il server SSH resta acceso più del tempo necessario, conviene ridurre la superficie d’attacco. Il minimo sindacale è limitare l’accesso a chi serve davvero, evitare password dove possibile e tenere sotto controllo gli aggiornamenti del componente OpenSSH e del sistema operativo.

Checklist utile:

• usa chiavi SSH invece di password, quando il contesto lo consente;
• verifica che la porta 22 sia aperta solo dai segmenti necessari;
• controlla che il servizio sshd sia avviato solo sulle macchine che devono davvero accettare connessioni;
• mantieni aggiornato Windows, perché OpenSSH dipende anche dal layer di sistema;
• seleziona con cura gli utenti autorizzati e rivedi periodicamente authorized_keys.

Se devi revocare l’accesso, la via corretta non è “spegnere tutto e vedere”. Rimuovi la chiave pubblica corrispondente da authorized_keys o disabilita l’account necessario, poi verifica che il login fallisca come atteso.

Procedura sintetica consigliata

Se vuoi una sequenza lineare, questa è quella che uso di solito su Windows 11 e 10 quando devo portare su OpenSSH senza perdere tempo in tentativi casuali:

1. verifica Winget con winget --version;
2. installa il client con winget install --id Microsoft.OpenSSH.Client -e;
3. installa il server con winget install --id Microsoft.OpenSSH.Server -e oppure usa Add-WindowsCapability se il pacchetto non è disponibile;
4. avvia sshd e imposta l’avvio automatico;
5. apri la porta 22 nel firewall, se non esiste già una regola valida;
6. testa prima in locale con Test-NetConnection localhost -Port 22;
7. testa poi da un altro host con ssh nomeutente@IP;
8. solo dopo, consolida chiavi, permessi e policy di accesso.

Questa sequenza riduce il rischio di confondere problemi di installazione con problemi di rete. È un errore molto comune saltare direttamente al client esterno e poi inseguire il firewall, quando il servizio non sta proprio ascoltando.

Conclusione operativa: quando Winget è la scelta giusta

Winget è la strada più veloce per installare OpenSSH su Windows 11 e 10 quando vuoi automatizzare o standardizzare. Per il client è quasi sempre la scelta più comoda; per il server resta ottimo, ma devi sapere anche come gestire il fallback con le capability di Windows. La differenza la fanno i controlli successivi: servizio, porta, firewall, permessi e log.

Se tratti OpenSSH come un servizio di produzione e non come un semplice “tool da installare”, eviti il classico scenario in cui il pacchetto c’è, ma nessuno riesce a connettersi. E in amministrazione di sistema, è proprio lì che si perde tempo.