> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/rdm/it/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md). # Best practice di sicurezza per Open SSH Sebbene Open SSH sia diventato lo standard in materia di accesso remoto, l'utilizzo della sua installazione predefinita comporta comunque alcuni rischi per la sicurezza. Questa guida propone modi per aumentare notevolmente il livello di sicurezza di un'installazione Open SSH. ### Utilizzare l'autenticazione con chiavi private/pubbliche L'utilizzo di chiavi crittografate per l'autenticazione è utile perché elimina la necessità di inserire password. Nemmeno gli hacker più fantasiosi saranno in grado di interferire o intrufolarsi in una sessione, e non ci saranno più tentativi di violazione delle password. 1. Generi una coppia di chiavi pubblica/privata utilizzando questo comando: `$ ssh-keygen -t rsa`. Questo crea due file nella directory (nascosta) `~/.ssh`; la chiave privata si chiama `id_rsa` e quella pubblica `id_rsa.pub`. 2. Scelga una password che verrà utilizzata per sbloccare la chiave pubblica a ogni connessione. Facoltativamente, è possibile aggiungere una crittografia protetta con una passphrase durante la creazione della chiave.

Anche premere Enter senza inserire una passphrase funziona. Tenga presente, tuttavia, che creare una chiave senza passphrase concede automaticamente l'accesso SSH al server remoto a chiunque riesca ad accedere alla sua macchina locale.

3. Copi la chiave pubblica (`id_rsa.pub`) sul server: ```` Scp –p id_rsa.pub remoteuser@remotehost: ```
The `remoteuser` should never be root. Select the default non-root user as `remoteuser` instead.
```` 4. Acceda con SSH e copi la chiave pubblica nella posizione corretta: ``` ssh remoteuser@remotehost mkdir ~/.ssh chmod 700 ~/.ssh cat id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys mv id_rsa.pub ~/.ssh logout ``` 5. Quindi elimini la chiave pubblica dal server, altrimenti il client SSH non consente l'accesso al server: ``` rm id_rsa.pub ``` 6. Imposti le autorizzazioni sui file del server (queste due sono necessarie se "StrictModes" è impostato su ***yes***): ``` $ chmod 700 ~/.ssh $ chmod 600 ~/.ssh/authorized_keys ``` 7. Una volta effettuato l'accesso utilizzando la passphrase della chiave, l'autenticazione tramite password può essere disattivata completamente. Per farlo, apra il file `/etc/ssh/sshd_config` e vi aggiunga le seguenti righe: ``` # Disable password authentication forcing use of keys PasswordAuthentication no ``` ### Disattivare l'autenticazione con nome utente e password Per eliminare completamente l'autenticazione basata su password e forzare l'utilizzo di chiavi o certificati SSH, aggiorni la configurazione SSH aggiungendo le seguenti righe nel file `/etc/ssh/sshd_config`: ``` PasswordAuthentication no ChallengeResponseAuthentication no KbdInteractiveAuthentication no UsePAM no ``` Quindi riavvii il servizio SSHD inserendo `/etc/init.d/sshd restart` oppure `service sshd restart`. Una volta fatto ciò, il server dovrebbe rifiutare tutti gli accessi con nome utente/password e accettare solo l'autenticazione tramite chiave o certificato. ### Configurare l'intervallo di timeout di inattività È possibile impostare un intervallo di timeout di inattività per evitare di avere una sessione SSH incustodita. Per farlo, apra il file `/etc/ssh/sshd_config` e aggiunga la seguente riga: ``` ClientAliveInterval 360 ClientAliveCountMax 0 ``` L'intervallo di timeout di inattività è espresso in secondi (360 secondi = 6 minuti). Una volta trascorso l'intervallo, gli utenti inattivi vengono disconnessi automaticamente. ### Disattivare le password vuote Per una maggiore sicurezza, si consiglia di impedire gli accessi remoti da account con password vuote. Apra il file `/etc/ssh/sshd_config` e aggiorni la seguente riga: ``` PermitEmptyPasswords no ``` ### Limitare l'accesso SSH a pochi utenti Nei casi in cui non sia possibile evitare l'autenticazione con nome utente/password, si consiglia di limitare l'accesso SSH solo a determinati utenti che necessitano di accesso remoto, riducendo così al minimo l'impatto degli utenti con password deboli. Per limitare l'accesso SSH, apra il file `/etc/ssh/sshd_config` e aggiunga una riga `AllowUsers`, seguita dall'elenco dei nomi utente separati da spazi: ``` AllowUsers user1 user2 ``` Quindi riavvii il servizio SSHD inserendo `/etc/init.d/sshd restart` oppure `service sshd restart`. ### Disattivare l'accesso root Per disattivare gli accessi root, apra il file `/etc/ssh/sshd_config` mentre è connesso come root e modifichi la riga `#PermitRootLogin` in `PermitRootLogin no`. Si assicuri di rimuovere il simbolo #, altrimenti non funzionerà. Quindi riavvii il servizio SSHD inserendo `/etc/init.d/sshd restart` oppure `service sshd restart`. ### Disattivare i cifrari deboli Apra il file `/etc/ssh/sshd_config` e aggiunga queste righe: ``` # Ciphers moderns Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com # KEX robusts KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384 # MAC moderns MACs hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com # Disable weak algorithms PubkeyAcceptedKeyTypes ssh-ed25519,rsa-sha2-256,rsa-sha2-512 HostKeyAlgorithms ssh-ed25519,rsa-sha2-256,rsa-sha2-512 ``` Quindi riavvii il servizio SSHD inserendo `/etc/init.d/sshd restart` oppure `service sshd restart`. ### Utilizzare una porta non standard La stragrande maggioranza degli hacker alla ricerca di server SSH aperti cercherà la porta 22, poiché per impostazione predefinita SSH è in ascolto delle connessioni in entrata su tale porta. Per eseguire SSH su una porta diversa, apra il file `/etc/ssh/sshd_config` e aggiunga le seguenti righe: ``` #Run SSH on a non standard port Port 2025 #Change me ``` Quindi riavvii il servizio SSHD inserendo `/etc/init.d/sshd restart` oppure `service sshd restart`. Si assicuri di modificare il port forwarding nel suo router e le eventuali regole del firewall necessarie. Si consiglia di informare i client di eventuali modifiche alle porte affinché sappiano a quale porta connettersi, dal momento che SSH non sarà più in ascolto delle connessioni sulla porta standard. ### Limitare l'esposizione SSH con controlli di rete Se la modifica della porta SSH non è praticabile, la distribuzione di un jump server offre un solido punto di controllo Zero-Trust tra i client e i sistemi interni. Centralizza l'autenticazione, applica criteri di accesso uniformi e impedisce l'esposizione diretta delle risorse critiche. Consulti [Remote Desktop Manager Jump (feature)](https://docs.devolutions.net/resources/it/devolutions-agent/jump-host#configure-a-jump-host) per i passaggi di configurazione. ### Abilitare l'autenticazione a più fattori L'autenticazione a più fattori è una delle principali protezioni da aggiungere ai server SSH per proteggerli da accessi non autorizzati, poiché ogni accesso utente deve essere collegato a un utente MFA configurato. Anche se un hacker riuscisse a impossessarsi di una password o a violare il server SSH, verrebbe comunque bloccato dall'MFA. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.devolutions.net/rdm/it/knowledge-base/knowledge-base-articles/open-ssh-security-best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.