Vai al contenuto

Impostazioni cookie

Scelga per ogni tipo quali cookie consente. Può modificare la sua scelta in qualsiasi momento tramite Impostazioni cookie in fondo a ogni pagina. Informativa sulla privacy

Necessari

Sempre attivi

Servono per accedere, conservare il carrello e ricordare le sue scelte. Sono sempre attivi.

Quali cookie?
  • weboke_sessie, weboke_klant, weboke_remember: la sua sessione e la permanenza dell'accesso
  • weboke_basket: il suo carrello
  • wkBtwIncl: visualizzazione dei prezzi con o senza IVA
  • wok_cookies: la sua scelta sui cookie, 12 mesi

Misurano quale annuncio porta a una visita o a un ordine, così non paghiamo annunci che non funzionano.

Quali cookie?
  • Google Ads tramite Google Tag Manager (_gcl_au, _gcl_aw), fino a 90 giorni
  • OpenAI Ads, annunci in ChatGPT
  • wok_aff: tramite quale partner è arrivato da noi (programma di affiliazione), 60 giorni

4,6

Paese e lingua

Ogni paese ha il suo sito, con i prezzi e l'IVA di quel paese.

Vedi

Disattivare l'accesso con password e come root

Ogni server su internet riceve in breve tempo visite da programmi che tentano di indovinare le password. Se è possibile accedere solo con una chiave, questi programmi non hanno alcuna possibilità. Ora attiviamo questa protezione.

Attenzione: l'accesso con la Sua chiave come anna funziona (vedere Un utente personale con sudo)? Allora crei prima uno snapshot (vedere Snapshot: una rete di sicurezza per ogni modifica importante) e mantenga una sessione aperta durante questi passaggi. Se qualcosa dovesse andare storto, potrà comunque accedere tramite la console (vedere La console: il Suo VPS nel browser).

Un file di impostazioni personale

Su Debian e Ubuntu il server SSH legge prima i file in /etc/ssh/sshd_config.d/, in ordine alfabetico. Per ogni impostazione vale il primo valore che incontra. Per questo motivo il Suo file riceve un nome che compare all'inizio:

anna@web1:~$ sudo nano /etc/ssh/sshd_config.d/00-eigen.conf

Inserisca al suo interno:

PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no
  • PasswordAuthentication no: nessuna password tramite SSH.
  • KbdInteractiveAuthentication no: nessuna richiesta di password neppure per vie traverse.
  • PermitRootLogin no: root non può più accedere tramite SSH, nemmeno con una chiave. Lei lavora come anna con sudo. Se desidera consentire ancora l'accesso a root con una chiave, utilizzi prohibit-password.

Controllare e applicare

anna@web1:~$ sudo sshd -t
anna@web1:~$ sudo sshd -T | grep -Ei '^(passwordauthentication|kbdinteractiveauthentication|permitrootlogin)'
passwordauthentication no
kbdinteractiveauthentication no
permitrootlogin no
anna@web1:~$ sudo systemctl restart ssh

sshd -t non mostra nulla se il file è corretto. sshd -T mostra quali valori sono effettivamente in vigore. Compare ancora passwordauthentication yes? Allora un altro file in sshd_config.d lo riattiva, spesso 50-cloud-init.conf. Il Suo 00-eigen.conf viene letto prima e ha la precedenza; controlli che il nome sia corretto.

Su AlmaLinux e Rocky Linux il servizio si chiama sshd: sudo systemctl restart sshd.

Verificare prima di chiudere la sessione

Apra una nuova finestra e provi:

ssh anna@203.0.113.10
ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no anna@203.0.113.10
anna@203.0.113.10: Permission denied (publickey).
ssh root@203.0.113.10
root@203.0.113.10: Permission denied (publickey).

Il primo deve funzionare. Gli altri due devono essere rifiutati. È tutto corretto? Allora elimini lo snapshot.

Suggerimento: una porta diversa dalla 22 rende il Suo registro più tranquillo, ma non rende il server più sicuro. È la chiave a fare il lavoro. Se decide comunque di cambiare la porta, la apra prima nel Suo firewall (vedere Un firewall con ufw (o nftables)).

Un momento…

Configuri i suoi domini

Per ogni dominio imposti i nameserver, il collegamento al suo hosting e chi ne diventa l'intestatario.

Caricamento dei suoi domini…