I tasti SSH per un accesso Linux VPS: creare, installare e testare

Confermare il vero account, host e metodo di recupero

Utilizzare questa lista di controllo per un Linux VPS che si possiede o sono autorizzati a amministrare. Iniziare con l'host, il nome dell'account e la porta SSH effettivamente assegnato al vostro servizio. Non indovinare un nome utente da un nome di distribuzione. Confermare come recuperare l'accesso se una modifica di autenticazione non riesce, utilizzando un metodo che il tuo operatore ha reso realmente disponibile.

Mantenere una sessione autenticata esistente aperta durante il test di un nuovo metodo di login. Se non hai ancora accesso al lavoro, risolvi prima i dettagli della connessione iniziale. Un piano di hosting pubblico o un ordine pagato non è di per sé un account shell funzionante; attendere i dettagli del servizio effettivo prima di applicare le istruzioni del server.

Recensione software e risorse Linux VPS

Creare la chiave sul dispositivo utilizzato per collegare

Eseguire ssh-keygen sul proprio dispositivo client, non all'interno del telecomando VPS. Per un client OpenSSH che lo supporta, ssh-keygen -t ed25519 crea una coppia di tasti Ed25519 e richieste per una posizione di file e passphrase. Scegliere un nuovo nome di file se una chiave esistente è già presente; non sovrascrivere una chiave che un altro server utilizza ancora.

Proteggi la chiave privata con un passphrase e un'archiviazione sicura del dispositivo. Utilizzare il prompt interattivo piuttosto che mettere una passphrase in un comando che può essere salvato nella storia della shell. Tenere traccia dello scopo chiave e dell'impronta digitale di chiave pubblica in modo da poter identificare in seguito l'entrata giusta durante la revisione o la revoca dell'accesso.

Installare la metà pubblica per l'account server previsto

La chiave pubblica ha normalmente lo stesso nome del file con .pub allegato. Aggiungi quella chiave pubblica alla posizione chiave autorizzata per l'account che utilizzerai su VPS. Molte installazioni OpenSSH utilizzano ~/.ssh/authorized_keys per l'account remoto, ma la configurazione del server efficace può specificare una posizione diversa. Verificare la posizione invece di assumere ogni sistema utilizza la stessa politica.

Se disponibile, ssh-copy-id può installare una chiave pubblica tramite una connessione autorizzata esistente. Un'installazione manuale deve conservare le chiavi esistenti e mantenere ogni chiave pubblica su una linea. Non sostituire l'intero file con un'unica nuova voce a meno che non abbia deliberatamente esaminato ogni titolare di accesso. La chiave privata rimane sul proprio dispositivo.

Scorrere il tavolo orizzontalmente se necessario.

Verificare l'host e testare una connessione fresca

Confrontare le impronte chiave host server con un valore di fiducia ottenuto attraverso il tuo operatore o un altro canale verificato prima di accettare una nuova identità host. Se un'impronta digitale precedentemente nota cambia inaspettatamente, indaga il cambiamento. Cancellare l'ingresso client-hosts e accettare ciò che appare non stabilisce che hai raggiunto il server corretto.

Aprire un secondo terminale e connettersi con il tuo account reale, host e percorso chiave privata scelto. L'opzione OpenSSH -i seleziona un file di identità e -p seleziona una porta non predefinita quando è stata assegnata. Confermare l'account previsto dopo il login. Un messaggio di passphrase chiave privata sblocca la chiave locale; è diverso da un prompt delle password di account remoto.

Diagnosi del rifiuto prima di cambiare la politica di login

Se la chiave viene rifiutata, controlla che hai usato il conto giusto e che la sua chiave pubblica corrisponda all'identità privata selezionata dal cliente. Rivedere la posizione del file, la proprietà e le autorizzazioni di licenza-chiave. Su un tipico account OpenSSH, le autorizzazioni restrittive come 700 su .ssh e 600 su authorized_keys impediscono ad altri utenti di modificare i file di autenticazione; l'account corretto deve possederli.

Ispezionare la diagnostica del client e i registri di autenticazione del server disponibili. La politica del server può limitare gli utenti, i tipi chiave o le combinazioni di autenticazione. Non ampliare i permessi per fare un lavoro chiave respinto. Condividere un messaggio di errore reagito quando si cerca aiuto, piuttosto che una chiave privata, passphrase o registro diagnostico completo sensibile.

Modificare le impostazioni di autenticazione solo dopo che l'accesso è dimostrato

Una chiave di lavoro non cambia automaticamente il criterio della password del server. Se si intende modificare le impostazioni di autenticazione, ispezionare la configurazione OpenSSH principale e tutti i file inclusi che influiscono sull'account. L'autenticazione PasswordAuthentication e tastiera-interattiva sono impostazioni separate, e una politica operatore o un blocco Match può cambiare il risultato efficace.

Riavviare la configurazione pertinente e convalidarla con il daemon installato prima di applicare le modifiche; sudo sshd -t è il controllo della sintassi OpenSSH sui sistemi in cui si applica il comando e il privilegio. Utilizzare il metodo di gestione del servizio documentato per la vostra distribuzione. Mantenere la sessione originale aperta e dimostrare un'altra connessione chiave fresca dopo il cambiamento prima di chiuderla.

Continuare con la lista di controllo di sicurezza Linux VPS

Ruotare l'accesso e mantenere il recupero indipendente da un computer portatile

Dare a ciascun amministratore la propria chiave in modo che una modifica di accesso non richiede la condivisione di un file privato. Quando si sostituisce un dispositivo, installare e testare la nuova chiave pubblica prima, quindi rimuovere la vecchia voce di chiave pubblica dopo l'identificazione. Un passphrase perso non è recuperabile dalla chiave privata crittografata; creare una sostituzione attraverso un metodo di accesso autorizzato funzionante.

Verificare i tasti quando un membro del team parte o un dispositivo è perso. La rimozione di una voce chiave pubblica impedisce i futuri login chiave attraverso quella voce, ma anche rivedere sessioni attive e altri metodi di accesso. Mantenere una procedura di recupero approvata con i record di servizio in modo che l'accesso non dipende interamente dal dispositivo che si sta sostituendo.

• La chiave privata non è mai stata caricata o inviata a supporto.
• Una seconda connessione funziona con il conto e l'identità previsti.
• L'impronta dell'host è stata controllata attraverso un canale di fiducia.
• Il recupero e la revoca chiave sono documentati prima delle modifiche della politica.

Pianificare backup e ripristino indipendenti · Convalida un sito web Nginx dopo aver stabilito l'accesso