Kolejny elementem serwisu jest produkcyjny serwer HTTP. Serwis jest statyczny co znacząco ułatwia ten etap.
Pomysł
Statyczna strona ma tą zaletę, że można ją umieścić gdziekolwiek.
Mogłbym skorzystać z dedykowanych serwisów takich jak Cloudflare Pages czy Github Pages. Serwisy tego typu mają prymitywnie prostą konfigurację, często są darmowe.
Mógłbym wykorzystać technologię kontenera obiektów (eng. object storage) udostępnianą przez wielu dostawców. Kontener obiektów można łatwo udostępnić jako statyczną stronę, wystarczy chwila konfiguracji i odpowiedni wpis w DNS naszej domeny.
Ostatecznie mógłbym wykorzystać klasyczną usługę hostingu. Otrzymał bym dostęp do współdzielonego serwera poprzez ssh bądź ftp. Samym serwerem HTTP zajmował by się hosting.
Wszystkie te opcje wydają się interesujące. Jednak nie wybrałem żadnej z nich. Postanowiłem skonfigurować mały serwer wirtualny. Serwer wirtualny daje mi dużo większą swobodę eksperymentowania, co jest głównym celem tego projektu.
Do komercyjnego projektu, zdecydował bym się pewnie na object storage, ze względu na na to, że mógłbym go po prostu wdrożyć i
zapomnieć.
Serwer wirtualny wymaga konserwacji od czasu do czasu.
Projekt i Założenia
Serwis umieszczę na infrastrukturze linode, ponieważ ją znam i korzystam prywatnie od dłuższego czasu. Nie są najtańsi, ale są w miarę tani. Lubie u nich prosty deploy i duży wybór gotowych obrazów łącznie z takimi dystybucjami jak Arch Linux czy Kali Linux. Często u tańszych dostawców chmury ograniczeni jesteśmy do Debiana i Ubuntu, bądź nawet tylko jednego z nich. AWS jest zdecydowanie za drogi na moje potrzeby. AWS Lightsail jest zbyt toporny, mimo że faktycznie tańszy niż Linode.
Jako system operacyjny wykorzystam Gentoo. Jako serwer HTTP wykorzystam projekt Nginx.
Realizacja
Do uruchomienia serwera wykorzystam narzędzie linode-cli.
Narzędzie instalujemy przez pip.
Narzędzie konfigurujemy pojedynczą komendą lin configure.
Jego główną zaletą jest możliwość wykonania wszystkich zadań związanych z serwerem prosto z terminala.
Pozwala to łatwo reprodukować efekty i minimalizuje ryzyko pomyłki.
Mógłbym równie dobrze wyklikać wszystko w interfejsie webowym.
Uruchomienie nowej maszyny
Aby zlecić uruchomienie nowej maszyny potrzebuje kilku parametrów.
Na początek potrzebuje id obrazu Gentoo, komenda lin images ls pokazuje linode/gentoo.
$ lin images ls
┌───────────────────────────────┬─────────────────────────────────┬───────────┬─────────────┬───────────┬───────┬───────────┬───────────────────────────────┬────────────┬──────┐
│ id │ label │ vendor │ description │ is_public │ size │ status │ capabilities │ total_size │ tags │
├───────────────────────────────┼─────────────────────────────────┼───────────┼─────────────┼───────────┼───────┼───────────┼───────────────────────────────┼────────────┼──────┤
│ linode/arch │ Arch Linux │ Arch │ │ True │ 1500 │ available │ │ │ │
├───────────────────────────────┼─────────────────────────────────┼───────────┼─────────────┼───────────┼───────┼───────────┼───────────────────────────────┼────────────┼──────┤
│ linode/debian12 │ Debian 12 │ Debian │ │ True │ 1500 │ available │ cloud-init, distributed-sites │ │ │
├───────────────────────────────┼─────────────────────────────────┼───────────┼─────────────┼───────────┼───────┼───────────┼───────────────────────────────┼────────────┼──────┤
│ linode/gentoo │ Gentoo │ Gentoo │ │ True │ 6500 │ available │ │ │ │
├───────────────────────────────┼─────────────────────────────────┼───────────┼─────────────┼───────────┼───────┼───────────┼───────────────────────────────┼────────────┼──────┤
│ linode/kali │ Kali Linux │ Kali │ │ True │ 1536 │ available │ │ │ │
└───────────────────────────────┴─────────────────────────────────┴───────────┴─────────────┴───────────┴───────┴───────────┴───────────────────────────────┴────────────┴──────┘
Potrzebuje też id regionu, serwer chcę uruchomić w centralnej europie, komenda lin regions ls pokazuje eu-central jako lokalizację we Frankfurcie.
$ lin regions ls
┌──────────────┬─────────────────┬─────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────┬───────────┐
│ id │ label │ country │ capabilities │ status │ site_type │
├──────────────┼─────────────────┼─────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┼───────────┤
│ de-fra-2 │ Frankfurt 2, DE │ de │ Linodes, Block Storage Encryption, Disk Encryption, Backups, NodeBalancers, Block Storage, GPU Linodes, Kubernetes, Cloud Firewall, Vlans, VPCs, │ ok │ core │
│ │ │ │ Metadata, Premium Plans, Placement Group, StackScripts, NETINT Quadra T1U │ │ │
├──────────────┼─────────────────┼─────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┼───────────┤
│ eu-west │ London, UK │ gb │ Linodes, Disk Encryption, Backups, NodeBalancers, Block Storage, Kubernetes, Cloud Firewall, Vlans, Block Storage Migrations, Metadata, Placement │ ok │ core │
│ │ │ │ Group, StackScripts │ │ │
├──────────────┼─────────────────┼─────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────┼───────────┤
│ eu-central │ Frankfurt, DE │ de │ Linodes, Disk Encryption, Backups, NodeBalancers, Block Storage, Object Storage, GPU Linodes, Kubernetes, Cloud Firewall, Vlans, Block Storage │ ok │ core │
│ │ │ │ Migrations, Managed Databases, Metadata, Placement Group, StackScripts │ │ │
└──────────────┴─────────────────┴─────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────┴───────────┘
Potrzebuje też typu maszyny wirtualnej, komenda lin linodes types
pokazuję długą listę wspieranych typów, łącznie z aktualnymi cenami.
Ja wybieram najmniejszy i najtańszy typ g6-nanode-1.
$ lin types
┌─────────────────────┬──────┬─────────┬───────────┬──────────────────────────┬───────┬────────┬──────────┬───────────┬─────────────┬─────────────────────┬──────────────┬───────────────┐
│ id │ gpus │ disk │ class │ label │ vcpus │ memory │ transfer │ successor │ network_out │ accelerated_devices │ price.hourly │ price.monthly │
├─────────────────────┼──────┼─────────┼───────────┼──────────────────────────┼───────┼────────┼──────────┼───────────┼─────────────┼─────────────────────┼──────────────┼───────────────┤
│ g6-nanode-1 │ 0 │ 25600 │ nanode │ Nanode 1GB │ 1 │ 1024 │ 1000 │ None │ 1000 │ 0 │ 0.0075 │ 5.0 │
├─────────────────────┼──────┼─────────┼───────────┼──────────────────────────┼───────┼────────┼──────────┼───────────┼─────────────┼─────────────────────┼──────────────┼───────────────┤
│ g6-standard-1 │ 0 │ 51200 │ standard │ Linode 2GB │ 1 │ 2048 │ 2000 │ None │ 2000 │ 0 │ 0.018 │ 12.0 │
├─────────────────────┼──────┼─────────┼───────────┼──────────────────────────┼───────┼────────┼──────────┼───────────┼─────────────┼─────────────────────┼──────────────┼───────────────┤
│ g6-standard-2 │ 0 │ 81920 │ standard │ Linode 4GB │ 2 │ 4096 │ 4000 │ None │ 4000 │ 0 │ 0.036 │ 24.0 │
└─────────────────────┴──────┴─────────┴───────────┴──────────────────────────┴───────┴────────┴──────────┴───────────┴─────────────┴─────────────────────┴──────────────┴───────────────┘
Posiadając wszystkie wartości, mogę uruchomić nowy serwer.
$ lin linodes create --region eu-central --image linode/gentoo --type g6-nanode-1 --root_pass "xxx"
┌──────────┬────────────────┬────────────┬─────────────┬───────────────┬─────────┬─────────────────┬─────────────────┬───────────────────────┐
│ id │ label │ region │ type │ image │ status │ ipv4 │ disk_encryption │ placement_group.label │
├──────────┼────────────────┼────────────┼─────────────┼───────────────┼─────────┼─────────────────┼─────────────────┼───────────────────────┤
│ 71252128 │ linode71252128 │ eu-central │ g6-nanode-1 │ linode/gentoo │ running │ xxx.xxx.xxx.xxx │ disabled │ │
└──────────┴────────────────┴────────────┴─────────────┴───────────────┴─────────┴─────────────────┴─────────────────┴───────────────────────┘
Doświadczenie mi podpowiada, że gentoo może nie pociągnąć na domyślnych 512MB swapu, dlatego dla spokoju zmienię teraz rozmiary podłączonych dysków. Zmiany muszę niestety dokonać na wyłączonej maszynie.
$ lin linodes shutdown 71252128
$ lin linodes disks-list 71252128
┌───────────┬───────────────────┬────────┬───────┬────────────┬─────────────────┐
│ id │ label │ status │ size │ filesystem │ disk_encryption │
├───────────┼───────────────────┼────────┼───────┼────────────┼─────────────────┤
│ 138654696 │ Gentoo Disk │ ready │ 25088 │ ext4 │ disabled │
├───────────┼───────────────────┼────────┼───────┼────────────┼─────────────────┤
│ 138654697 │ 512 MB Swap Image │ ready │ 512 │ swap │ disabled │
└───────────┴───────────────────┴────────┴───────┴────────────┴─────────────────┘
$ lin linodes disk-resize --size 24064 71252128 138654696
$ lin linodes disk-resize --size 1536 71252128 138654697
$ lin linodes boot 71252128
Konfiguracja maszyny
Zaloguje się na nowo utworzoną maszynę przez ssh. Zaloguje się bezpośrednio na konto roota używając skonfigurowanego wcześniej hasła.
$ ssh root@xxx.xxx.xxx.xxx
Pierwszą rzeczą jaką wykonam jest aktualizacja systemu.
To może potrwać trochę czasu na tak słabej maszynie, należy uzbroić
się w cierpliwość.
Mam dość niestabilne połączenie internetowe w tym momencie, więc
przed aktualizacją systemu zainstalowałem tmux i na nim
kontynuowałem pracę.
(vps) $ ip -4 addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
inet xxx.xxx.xxx.xxx/24 brd xxx.xxx.xxx.xxx scope global eth0
valid_lft forever preferred_lft forever
(vps) $ emerge -q tmux neofetch
(vps) $ tmux
Maszynę skonfiguruję według własnych preferencji, nie będę się skupiał tutaj na najlepszej możliwej konfiguracji.
(vps) $ neofetch
-/oyddmdhs+:. root@localhost
-odNMMMMMMMMNNmhy+-` -----------------
-yNMMMMMMMMMMMNNNmmdhy+- OS: Gentoo Linux x86_64
`omMMMMMMMMMMMMNmdmmmmddhhy/` Host: Compute Instance
omMMMMMMMMMMMNhhyyyohmdddhhhdo` Kernel: 6.6.30-gentoo-x86_64
.ydMMMMMMMMMMdhs++so/smdddhhhhdm+` Uptime: 39 secs
oyhdmNMMMMMMMNdyooydmddddhhhhyhNd. Packages: 428 (emerge)
:oyhhdNNMMMMMMMNNNmmdddhhhhhyymMh Shell: bash 5.2.37
.:+sydNMMMMMNNNmmmdddhhhhhhmMmy Resolution: 1280x800
/mMMMMMMNNNmmmdddhhhhhmMNhs: Terminal: /dev/pts/6
`oNMMMMMMMNNNmmmddddhhdmMNhs+` CPU: AMD EPYC 7713 (1) @ 2.000GHz
`sNMMMMMMMMNNNmmmdddddmNMmhs/. GPU: 00:01.0 Vendor 1234 Device 1111
/NMMMMMMMMNNNNmmmdddmNMNdso:` Memory: 78MiB / 972MiB
+MMMMMMMNNNNNmmmmdmNMNdso/-
yMMNNNNNNNmmmmmNNMmhs+/-`
/hMMNNNNNNNNMNdhs++/-`
`/ohdmmddhys+++/:.`
`-//////:--.
Wrzucam na maszynę minimalną konfigurację systemu do pliku make.conf.
Wyłączam wsparcie javy, alsy, cupsów oraz interfejsów graficznych.
Podłączam się pod globalny mirror repozytorium gentoo.
CHOST="x86_64-pc-linux-gnu"
USE="mmx sse sse2 bash-completion -alsa -cups -gnome -gtk -gtk2 -java -kde -oss -qt -sdl -X -wayland"
CFLAGS="-O2 -pipe -march=native"
CXXFLAGS="${CFLAGS}"
ACCEPT_LICENSE="* -@EULA"
PORTDIR=/var/db/repos/gentoo
DISTDIR=/var/cache/distfiles
PKGDIR=/var/cache/binpkgs
GENTOO_MIRRORS="http://distfiles.gentoo.org/"
/etc/portage/make.confWrzucam aktualizację systemu i idę zająć się innym projektem. Mam nadzieję, że potrwa to nie dłużej niż godzinę, ale różnie może być.
(vps) $ emaint sync
(vps) $ emerge -1 portage
(vps) $ emerge -quDN @world
>>> Emerging (1 of 215) sys-devel/gnuconfig-20240728::gentoo
...
Po niecałej godzinie moja maszyna jest gotowa do pracy. Miałem szczęście, że nie trafiłem na żadną ciężką paczkę taką jak gcc. Generalnie obrazy Archa czy Gentoo w Linode są zawsze w miarę śweże, co jest dużym plusem przy aktualizacji kroczącej (eng. rolling release). Zaczynam od odinstalowania domyślnego loggera systemowego i zastąpieniu go moim ulubionym.
(vps) $ emerge --depclean sysklogd
(vps) $ emerge -q syslog-ng logrotate
(vps) $ rc-udpate add syslog-ng default
Żeby zmiana poprawnie zadziałała należy usunąć z pliku
/etc/init.d/cloud-config linijkę rc_need="sysklogd".
Nie wiem czemu ta zależność się tam znalazła.
Nie wiem czy paczka cloud-init mi dalej potrzebna.
Główną funkcją tej paczki jest skonfigurować system przy pierwszym
uruchomieniu.
Nie chce mi się drążyć tematu, zostawiam jak jest.
Następnie instaluje narzędzie do planowania zadań.
(vps) $ emerge -q cronie
(vps) $ rc-udpate add cronie default
Gentoo z automatu dorzuci logrotate do crona.
Od siebie dorzucam do crona skrypt do automatycznej
synchronizacji systemu.
Na desktopach staram się tego unikać, ale tutaj jest szansa,
że będę rzadko zaglądał.
Nie jest to może złoty standard na produkcyjnym serwerze.
Ale cały projekt jest w końcu eksperymentem.
#!/usr/bin/env bash
/usr/sbin/emaint sync -A
/usr/bin/logger "Portage sync finished with status: $?"
/usr/bin/emerge -quDN @world
/usr/bin/logger "World update finished with status: $?"
/usr/bin/emerge @preserved-rebuild
/usr/bin/logger "Preserved rebuild finished with status: $?"
/etc/cron.daily/emergeGentoo z automatu dorzuci mi do rotacji logów syslog-ng i openrc. Od siebie dorzucam skrypt do rotacji logów managera paczek Gentoo. Jeśli synchronizacja systemu będzie wykonywana z automatu to chciałbym mieć wgląd w archiwalne logi.
/var/log/emerge*.log {
su portage portage
missingok
nocreate
delaycompress
}
/etc/logrotate.d/emergeTworzę nowego użytkownika, dodaję go do trzech grup.
Ustawiam użytkownikowi hasło, żeby być w stanie awaryjnie zalogować
się przez lish.
Hasło ustawiam dość długie, wygenerowane losowo i chowam je do
managera haseł.
Nie będzie mi potrzebne często.
Za chwilę wyłączę możliwość logowania po ssh za pomocą hasła.
(vps) $ useradd -m -G users,wheel,portage -s /bin/bash admin
(vps) $ passwd admin
Z poziomu desktopa wrzucam mu własny klucz publiczny jako autoryzowany do logowania.
$ cat ~/.ssh/id_rsa.pub | ssh root@xxx.xxx.xxx.xxx "mkdir -p /home/admin/.ssh && cat >> /home/admin/.ssh/authorized_keys"
Ustawiam odpowiednie uprawnienia na tym pliku.
Są niezbędne do prawidłowego działania serwera sshd w trybie
StrictModes yes.
(vps) $ chown admin:admin /home/admin/.ssh/authorized_keys
Żeby upewnić się, że wszystko działa w porządku resetuje system.
(vps) $ shutdown -r now
Po restarcie maszyny próbuję zalogować się na nowo utworzone konto.
Serwer powinien autoryzować mnie kluczem, nie powinien pytać o hasło.
Komendą su loguje się na konto root.
Upewniam się, że konfiguracja sudoers oraz
sshd_config jest poprawna.
Usuwam hasło na koncie root komendą passwd -dl root.
Defaults!/usr/sbin/visudo env_keep += "SUDO_EDITOR EDITOR VISUAL"
Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin"
root ALL=(ALL:ALL) ALL
%wheel ALL=(ALL:ALL) NOPASSWD: ALL
/etc/sudoers
StrictModes yes
PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no
Include "/etc/ssh/sshd_config.d/*.conf"
/etc/ssh/sshd_config$ ssh admin@xxx.xxx.xxx.xxx
(vps ~ admin) $ su
(vps ~ root) $ passwd -dl root
Od teraz na serwer zaloguje się jedynie po ssh na konto admin
z użyciem autoryzacji kluczem.
A z konta admin na konto root z użyciem komendy sudo su.
Posiadając taką wstępnie skonfigurowaną i zabezpieczoną maszynę wirtualną mogę przejść do instalacji samego serwisu.
Konfiguracja PAM
Zauważyłem, że pomimo ustawienia PasswordAuthentication no
wciąż jestem w stanie zalogować się na serwer z użyciem hasła.
Po szybkiej analizie okazało się, że obraz gentoo z linode
posiada dodatkową konfigurację wewnąrz pliku
/etc/ssh/sshd_config.d/9999999gentoo-pam.conf.
Znajduje się tam konfiguracja UsePAM yes.
PAM jest zintegrowane z sshd w dosyć nieoczywisty sposób.
Z jednej strony, sshd może przekazać zadanie autoryzacji
użytkownika do odpowiedniego modułu PAM.
Z drugiej strony autoryzacja kluczem (PubkeyAuthentication)
po stronie SSH całkowicie ignoruje PAM.
Ja chciałem w tej konfiguracji polegać głównie na autoryzacji kluczem, dlatego wyłączam PAM w ssh. PAM jest bardzo ciekawym narzędziem, jeśli chcemy skonfigurować 2FA podczas logowania, albo zintegrować LDAP, ale to temat na osobny artykuł.
Konfiguracja serwera HTTP
Konfigurację serwera HTTP muszę zacząć od instalacji kilku paczek.
Dorzucam nginxa do domyślnego poziomu uruchamiania.
Dodaję mojego użytkownika do grupy nginx.
(vps ~ root) $ echo "app-misc/mime-types nginx" >> /etc/portage/package.use/app-misc
(vps ~ root) $ emerge -q dev-vcs/git nginx
(vps ~ root) $ rc-update add nginx default
(vps ~ root) $ usermod -a -G nginx admin
Tworzę nowy katalog /var/www/mucka_pro/ z niego będę udostępniał
moją statyczną stronę.
Ustawiam odpowiednie uprawnienia dostępu.
(vps ~ root) $ mkdir /var/www/mucka_pro
(vps ~ root) $ chown nginx:nginx /var/www/mucka_pro
(vps ~ root) $ chmod 770 /var/www/mucka_pro
Domyślna konfiguracja nginx.conf dostarczona
przez gentoo nie jest zła.
Zmieniam ją trochę pod moje preferencje.
Ustawiam domyślny typ dokumentu na application/xhtml+xml.
Ustawiam domyślną nazwę pliku indeksu na root.xhtml.
Automatycznie ładuje wszystkie dodatkowe pliki konfiguracyjne
z podkatalogu conf.d.
Reszta ustawień jest raczej standardowa.
user nginx nginx;
worker_processes 1;
error_log /var/log/nginx/error_log info;
events {
worker_connections 1024;
use epoll;
}
http {
include /etc/nginx/mime.types.nginx;
types_hash_max_size 4096;
default_type application/xhtml+xml;
index root.xhtml;
log_format main
'$remote_addr - $remote_user [$time_local] '
'"$request" $status $bytes_sent ';
client_header_timeout 10m;
client_body_timeout 10m;
send_timeout 10m;
connection_pool_size 256;
client_header_buffer_size 1k;
large_client_header_buffers 4 2k;
request_pool_size 4k;
gzip off;
output_buffers 1 32k;
postpone_output 1460;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 75 20;
ignore_invalid_headers on;
include /etc/nginx/conf.d/*.conf;
}
/etc/ssh/sshd_configW ten sposób mogę utworzyć plik mucka_pro.conf zawierający konfigurację mojego serwisu. W przyszłości, jak będę chciał dorzucić kolejny serwis na ten serwer, dorzucę kolejny plik konfiguracyjny
Konfiguracja serwera pod statyczną stronę jest prosta. Ustawiam domenę, pliki logów oraz katalog główny.
Dodaję jedną prostą funkcję.
Jeśli wejdziemy na stronę główną w konkretnym języku,
ustawimy cookie na wartość tego języka.
Następnym razem gdy wejdziemy bezpośrednio na mucka.pro zostaniemy
przekierowani na stronę w ostatnio wybranym języku.
Domyślnym językiem zostaje angielski.
map $cookie_language $language_selector {
default "en";
"~^(cz|de|en|jp|kr|la|pl)$" $1;
}
server {
server_name mucka.pro;
access_log /var/log/nginx/mucka_pro.access_log main;
error_log /var/log/nginx/mucka_pro.error_log info;
root /var/www/mucka_pro;
location ~ ^/(cz|de|en|jp|kr|la|pl)/ {
add_header Set-Cookie "language=$1;domain=mucka.pro;Path=/;max-age=31536000";
}
location = / {
return 307 /$language_selector$request_uri;
}
}
/etc/nginx/conf.d/mucka_pro.confPozostaje wystartować serwis nginx.
(vps ~ root) $ rc-service nginx start
Czas zbudować serwis i wgrać pliki na serwer.
(desktop ~ user) $ python project.py build
(desktop ~ user) $ python project.py deploy -p admin@xxx.xxx.xxx.xxx:/var/www/mucka_pro
Przy okazji dodałem nową komendę deploy do
project.py.
Jest bardzo prosta, podstawiam ścieżki do rsync.
def command_deploy(args):
'''Deploy build to web server'''
build_path = current_path / args.output
os.system(f"rsync -ah --delete {build_path}/ {args.path}")
project.pyDorzucam ip serwera do pliku /etc/hosts na desktopie.
Dzięki temu będę mógł zobaczyć stronę w przeglądarce
bez konfiguracji DNS'ów.
(desktop ~ root) $ echo "xxx.xxx.xxx.xxx mucka.pro" >> /etc/hosts
Efekt
Mam wstępnie zabezpieczony serwer udostępniający statyczny serwis. Serwer przygotowany jest pod łatwą konfigurację większej ilości serwisów. Serwer powinien jakiś czas podziałać bez żadnego nadzoru. W razie problemów powinienem mieć dostęp do logów z ostatnich kilku tygodni.
Podsumowanie
Infrastruktura jest bardzo ważnym elementem każdego projektu. Zastanawiałem się jak dużo tej infrastruktury chciałbym powierzyć stronom trzecim w zamian za wygodę. Wybrałem pewien kompromis z którego jestem zadowolony.
Postscriptum
W ramach ciekawostki sprawdziłem logi systemowe.
Kilka minut po tym, jak moja maszyna wirtualna została włączona,
zaczęła odbierać pierwsze próby logowania.
Testowane nazwy użytkownika to głównie root, user, user1,
myuser.
sshd-session[13357]: Received disconnect from 218.92.0.155 port 33737:11: [preauth]
sshd-session[13357]: Disconnected from authenticating user root 218.92.0.155 port 33737 [preauth]
sshd-session[13364]: Invalid user myuser from 125.228.185.131 port 47530
sshd-session[13364]: Received disconnect from 125.228.185.131 port 47530:11: Bye Bye [preauth]
sshd-session[13364]: Disconnected from invalid user myuser 125.228.185.131 port 47530 [preauth]
sshd-session[13368]: Connection closed by authenticating user root 176.65.138.252 port 54468 [preauth]
sshd-session[13371]: Invalid user user1 from 125.228.185.131 port 31642
sshd-session[13371]: Received disconnect from 125.228.185.131 port 31642:11: Bye Bye [preauth]
sshd-session[13371]: Disconnected from invalid user user1 125.228.185.131 port 31642 [preauth]
sshd-session[13375]: error: PAM: Authentication failure for root from 218.92.0.155
sshd-session[13375]: error: PAM: Authentication failure for root from 218.92.0.155
sshd-session[13375]: error: PAM: Authentication failure for root from 218.92.0.155
sshd-session[13375]: Received disconnect from 218.92.0.155 port 39923:11: [preauth]
sshd-session[13375]: Disconnected from authenticating user root 218.92.0.155 port 39923 [preauth]
sshd-session[13382]: Invalid user ekp from 125.228.185.131 port 27536
sshd-session[13382]: Received disconnect from 125.228.185.131 port 27536:11: Bye Bye [preauth]
Serwer HTTP zaraz od włączenia odbiera bardzo dużo zapytań. Testowanych jest bardzo dużo różnych ścieżek, związanych jak zakładam, z popularnymi frameworkami.
193.41.206.176 - "GET /v1/.env HTTP/1.1" 404 332
193.41.206.176 - "GET /wp-admin/.env HTTP/1.1" 404 332
193.41.206.176 - "GET /.env.testing HTTP/1.1" 404 332
193.41.206.176 - "GET /info HTTP/1.1" 404 332
193.41.206.176 - "GET /.env.old HTTP/1.1" 404 332
193.41.206.176 - "GET /public/.env HTTP/1.1" 404 332
193.41.206.176 - "GET /app_dev.php HTTP/1.1" 404 332
193.41.206.176 - "GET /.aws/credentials HTTP/1.1" 404 332
193.41.206.176 - "GET /.env.local HTTP/1.1" 404 332
193.41.206.176 - "GET /admin/config HTTP/1.1" 404 332
193.41.206.176 - "GET /core/.env HTTP/1.1" 404 332
193.41.206.176 - "GET /storage/.env HTTP/1.1" 404 332
193.41.206.176 - "GET /phpinfo HTTP/1.1" 404 332
193.41.206.176 - "GET /config.properties HTTP/1.1" 404 332
193.41.206.176 - "GET /config/settings.env HTTP/1.1" 404 332
193.41.206.176 - "GET /index.html HTTP/1.1" 404 332
193.41.206.176 - "GET /settings/.env HTTP/1.1" 404 332
193.41.206.176 - "GET /php_errors.log HTTP/1.1" 404 332
193.41.206.176 - "GET /db.php.bak HTTP/1.1" 404 332
193.41.206.176 - "GET /database.php HTTP/1.1" 404 332
78.153.140.147 - "GET /.env HTTP/1.1" 404 734
78.153.140.147 - "POST / HTTP/1.1" 307 397
52.15.125.69 - "SSH-2.0-Go" 400 309
88.214.25.65 - "\x03\x00\x00/*\xE0\x00\x00\x00\x00\x00Cookie: mstshash=Administr" 400 309
Wystawiając w dzisiejszych czasach jakikolwiek urządzenie do publicznie dostępnego internetu musimy zawsze zakładać, że będzie ono pod ostrzałem od pierwszych sekund po włączeniu karty sieciowej.