Acquisto VPS
- Openstack Linux
- 1 CPU, 1GB RAM, 20GB HD, 2TB/mese
- Debian 12 64-bit
- Aggiunto indirizzo IPv4 (Euro 0.50/mese)
- Nome server: ‘posta’
- Configurato password ‘root’
- Aggiunto la mia SSH Key
- Euro 1.99/mese
Configuraziono iniziale
Aggiornamento sistema
ssh debian@31.14.142.65
su -
apt update
apt upgrade
shutdown -r nowAbilitazione SSH Key per ‘root’
Alla prima connessione tramite SSH sono stato disconnesso e invitato ad utilizzare l’utente ‘debian’. Per potermi connettere direttamente tramite utente ‘root’ devo modificare il file /root/.ssh/authorized_keys eliminando le istruzioni all’inizio della prima riga e facendo un copia di backup del file:
cd /root/
cp .ssh/authorized_keys .ssh/authorized_keys.bak
vi .ssh/authorized_keysConnessione solo tramite SSH Key
Modificando i seguenti parametri all’interno del file di configurazione /etc/ssh/sshd.config e facendo sempre una copia di backup impedisco laccesso tramite password ma solo tramite SSH Key:
PermitRootLogin yes
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yesPer nuova versione di sshd invece avremo:
PermitRootLogin yes
PasswordAuthentication no
KbdInteractiveAuthentication no
UsePAM yesRicarico quindi il servizio con la nuova configurazione:
systemctl reload sshd.serviceCollegamento al dominio ‘max73.net’
Dopo varie vicissitudini sul sito di Aruba ho inserito i record A (IPv4) e record AAAA (IPv6).
Record A (IPv4)
| HOST | INDIRIZZO IPV4 | TTL |
|---|---|---|
| www.max.73.net | 31.14.142.65 | 300 |
| max.73.net | 31.14.142.65 | 300 |
| *.max.73.net | 31.14.142.65 | 300 |
Record AAAA (IPv6)
| HOST | INDIRIZZO IPV6 | TTL |
|---|---|---|
| www.max.73.net | 2a00:6d40:0072:0100:0000:0000:0000:0086 | 300 |
| max.73.net | 2a00:6d40:0072:0100:0000:0000:0000:0086 | 300 |
| *.max.73.net | 2a00:6d40:0072:0100:0000:0000:0000:0086 | 300 |
Installazione e configurazione Webserver NGINX
Installazione
ufw status numbered
ufw allow 80
ufw allow 443
apt install nginxConfigurazione landing page
mv /var/www/html /var/www/home
mv /var/www/home/index.nginx-debian.html /var/www/home/index.html
cp /etc/nginx/sites-vailable/default /etc/nginx/sites-availabe/home
vi /etc/nginx/sites-available/home
rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/home /etc/nginx/sites-enabled/
systemctl restart nginx.serviceContenuto del file /etc/nginx/sites-available/home:
#
# Home page
#
server {
listen 80;
listen [::]:80;
root /var/www/home;
index index.html;
server_name www.max73.net max73.net;
location / {
try_files $uri $uri/ =404;
}
}Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
1: max73.net
2: www.max73.net
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel):
Requesting a certificate for max73.net and www.max73.net
Certbot failed to authenticate some domains (authenticator: nginx). The Certificate Authority reported these problems:
Domain: max73.net
Type: dns
Detail: DNS problem: looking up A for max73.net: DNSSEC: DNSKEY Missing: validation failure <max73.net. A IN>: No DNSKEY record from 81.2.232.15 for key max73.net. while building chain of trust; DNS problem: looking up AAAA for max73.net: DNSSEC: DNSKEY Missing: validation failure <max73.net. AAAA IN>: No DNSKEY record from 185.8.48.79 for key max73.net. while building chain of trust
Domain: www.max73.net
Type: dns
Detail: DNS problem: looking up A for www.max73.net: DNSSEC: DNSKEY Missing: validation failure <www.max73.net. A IN>: No DNSKEY record from 185.43.208.79 for key max73.net. while building chain of trust; DNS problem: looking up AAAA for www.max73.net: DNSSEC: DNSKEY Missing: validation failure <www.max73.net. AAAA IN>: No DNSKEY record from 81.2.232.15 for key max73.net. while building chain of trust
Hint: The Certificate Authority failed to verify the temporary nginx configuration changes made by Certbot. Ensure the listed domains point to this nginx server and that it is accessible from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.