🔑 SSH & Remote Management: Protocolli di Accesso Sicuro

::: info Security First: In un ambiente di produzione, l’autenticazione tramite password è considerata obsoleta e insicura (vulnerabile ai botnet). Questa guida stabilisce lo standard per l’accesso remoto basato esclusivamente su chiavi crittografiche e sessioni persistenti. :::

1. Generazione Chiavi Moderne (Ed25519)

Dimentichiamo lo standard RSA. Le chiavi Ed25519 sono più sicure, performanti e producono firme più corte.

Sul Client (Tua Workstation principale):

Esegui questo comando per generare una nuova identità:

ssh-keygen -t ed25519 -a 100 -C "nome.cognome@workstation"

-a 100: Aumenta il numero di round di hashing della passphrase (più resistente al brute-force offline).
Best Practice: Inserisci sempre una passphrase locale per proteggere la chiave privata su disco.

2. Automazione Accesso: Il file `~/.ssh/config`

Per evitare di dover ricordare ogni volta indirizzi IP e porte, utilizziamo il file di configurazione SSH per creare degli alias.

Modifica (o crea) il file ~/.ssh/config sulla tua macchina principale:

# Impostazioni Globali
Host *
    AddKeysToAgent yes
    IdentitiesOnly yes

# Nodo Proxmox
Host pve
    HostName 192.168.1.100
    User root
    Port 22

# Home Assistant VM
Host ha
    HostName 192.168.1.101
    User admin
    IdentityFile ~/.ssh/id_ed25519_home

# Mac Pro 2013 (Ubuntu)
Host macpro
    HostName 192.168.1.105
    User software_eng

Vantaggio: Ora puoi collegarti semplicemente digitando ssh pve o ssh macpro.

3. Hardening del Server (`sshd_config`)

Ogni server Linux deve essere blindato modificando il file /etc/ssh/sshd_config.

Checklist di Sicurezza:

Disabilitare Root Login: PermitRootLogin no (usa un utente standard con sudo).
Disabilitare Password: PasswordAuthentication no.
Rafforzare Protocollo: Protocol 2.
Max Autenticazioni: MaxAuthTries 3.

# Applica le modifiche
sudo systemctl restart ssh

📉 Workflow di Connessione Sicura (Mermaid)

graph LR
    ADMIN[Engineer Workstation] -->|SSH Request: 'ssh pve'| CFG{Local SSH Config}
    CFG -->|Key Auth: Ed25519| FW{UFW Firewall}
    FW -->|Port 22/Allowed| SSHD[SSH Daemon on Server]
    SSHD -->|Challenge/Response| KEY[Private Key Agent]
    KEY -->|Verified| SHELL[Interactive Shell / Tmux]
    
    style ADMIN fill:#f5f5f5,stroke:#333
    style SHELL fill:#4CAF50,color:#fff

4. Persistenza delle Sessioni: Tmux

Quando lavori su container Docker o aggiornamenti di sistema via SSH, il rischio principale è la disconnessione della rete (che interrompe il processo in corso).

Utilizzo Professionale:

Avvio sessione: tmux new -s manutenzione
Distacco (Detach): Ctrl+b seguito da d (la sessione continua a girare sul server).
Riconnessione (Attach): tmux attach -t manutenzione

::: tip PRO-TIP Installa Tmux su ogni server che gestisci. È l’equivalente di un “salvataggio istantaneo” per il tuo terminale. :::

💡 Note dell’Ingegnere (Critical Thinking)

SSH over Reverse Proxy: Non tentare di passare l’SSH attraverso Nginx Proxy Manager (HTTP/HTTPS). SSH è un protocollo TCP puro. Se devi accedere dall’esterno, usa una VPN (es. Tailscale o WireGuard) per entrare nella LAN e poi usa l’SSH locale.
Agent Forwarding: Usa ForwardAgent no a meno che tu non debba fare git pull dal server usando le chiavi del tuo laptop. L’agente inoltrato è un potenziale rischio se il server viene compromesso.
Backup delle Chiavi: La tua chiave privata (~/.ssh/id_ed25519) è l’unica prova della tua identità. Conservane una copia criptata sul tuo NAS Synology/QNAP.

Tags: #SSH #RemoteManagement #Security #Tmux #SysAdmin #Networking*