Salut.
En préambule, je tiens a préciser que je ne suis pas un sysadmin, que le titre est un peu menteur, que les propos qui suivent n'ont pas encore été testés sur la cible réelle mais juste sur VM locale et enfin que je viens de valider que ça boote et déverouille le système sur ma VM…
Il y a quelques jours, j'ai finalement fait le nécessaire pour louer un VPS (pour héberger mes délires perso, faire joujou, etc, rien de sérieux), chez un hébergeur du nom d'OVH. Je comptais réinstaller le système complet, d'une manière ou d'une autre, mais pas nécessairement chiffrer le disque, n'ayant aucune expérience sur le sujet. Quelques discussions sur irc plus tard, j'ai finalement décidé de le chiffrer, d'une part pour le jeu, et d'autre part parce que, franchement, y'a 0 sécurité à la location d'un VPS chez OVH: ils m'ont envoyé, dans un seul mail non-signé, une IP, et un message qui dit, en gros: "voila, vous pouvez vous logguer via l'utilisateur root avec le password 123456". J'exagère sur le password, il y avait aussi des lettres, mais la taille est a peu près celle-ci. Ah, et bien sûr, le fingerprint du ssh du serveur… n'est pas indiqué (je ne mentionne pas le fait que le /etc/sources.list, de mémoire, n'utilise pas les serveurs debian, mais un repo OVH, ce que je peux comprendre, mais j'aurais préféré un proxy genre apt-cacher-ng, histoire de réduire la taille de la chaîne de confiance, un petit peu (certes, un proxy peut bidouiller les paquets, mais on peut ensuite vérifier les signatures à partir d'une machine locale, j'imagine)?).
Je suppose que ce mode laxiste est pour éviter de surcharger la hotline, mais j'aurais aimé avoir l'option d'un truc un peu plus sécurisé, comme on a sur les forges logicielles: la possibilité d'envoyer une clé publique, et qu'il ne soit possible de le logguer que par elle si elle a été envoyée. Si ça existe, j'ai pas trouvé. Bref.
OVH propose plusieurs modes de démarrage pour ses VPS:
- reboot simple: on reste sur le système principal;
- rescue mode: un système custo d'OVH, qui détecte le disque principal en tant que /dev/sdb, et le monte dans /mnt/sdb1. Oui, tout est installé sur une seule partition…
- réinstallation: non, ce n'est pas "mettre l'iso de debian dans le lecteur CD virtuel et attendre l'utilisateur", mais plutôt "on vous réinstalle tout ça, on se charge de tout…";
Donc, pas moyen de passer par les outils Debian officiels sur ce coup. Au final, on en est réduit à faire en gros ce que j'avais fait ici, a savoir passer par debootstrap. Comme quoi…
Sans plus vous embêter, je vous colle le script dans l'état actuel, il reste pas mal de boulot dessus, je ne vous le cache pas, d'ailleurs ça se voit: y'a du code zombie, des TODO, des valeurs hard-codées, des commentaires probablement faux/obsolètes, le -x du debug, l'absence de -e d'un truc fini… bref, exemple pas génial de mes capacités (qui ne le sont pas, du coup, ça colle) :)
#!/bin/sh -x
#TODO
# unmount partitions on fail
# prev point includes closing cryptsetup volumes
die()
{
echo $@
exit 1
}
mkd()
{
test -d "${1:="mkd() needs target as param 1"}" || mkdir "$1"
}
CIPHER="aes-xts-plain64"
KEYSZ="512"
HASH="sha512"
KEYFILE="srvcryptkey"
## disk preparation ##
findmnt /dev/sdb1 >/dev/null && umount /mnt/sdb1
apt-get install --yes --no-install-recommends syslinux cryptsetup-bin debootstrap dosfstools
sfdisk /dev/sdb < disk.part
dd if=/usr/lib/SYSLINUX/gptmbr.bin of=/dev/sdb
echo syncing disk... and udev.
sync
sleep 10
mkfs.vfat -I -n BOOTLOADER /dev/disk/by-partlabel/BOOTLOADER
test -n "$KEYFILE" -a -r "$KEYFILE" || die 'KEYFILE must be a valid, normal and readable file'
#for mntpoint in data mainsys mainvar backsys
for mntpoint in data mainsys mainvar
do
## crypto ##
PART="/dev/disk/by-partlabel/${mntpoint}"
cryptsetup -v -c $CIPHER -s $KEYSZ -h $HASH luksFormat "${PART}" - < "${KEYFILE}"
cryptsetup open "${PART}" "${mntpoint}" --type luks --key-file - < "${KEYFILE}"
## formating ##
mkfs.ext4 -F -L "${mntpoint}" "/dev/mapper/${mntpoint}"
done
## mount & bootstrap ##
mkd "/mnt/boot"
mount "PARTLABEL=BOOTLOADER" "/mnt/boot"
## fallback system if things go bad someday ##
#mkd "/mnt/backsys"
#mount "/dev/mapper/backsys" "/mnt/backsys"
#mkd "/mnt/backsys/home"
#mount "/dev/mapper/data" "/mnt/backsys/home"
## main system ##
mkd "/mnt/mainsys"
mount "/dev/mapper/mainsys" "/mnt/mainsys"
mkd "/mnt/mainsys/var"
mount "/dev/mapper/mainvar" "/mnt/mainsys/var"
mkd "/mnt/mainsys/home"
mount "/dev/mapper/data" "/mnt/mainsys/home"
# supposedly, there is only one NIC around... and your lspci format is same as mine's!
ETH_MODULE="$(lspci -v | awk 'BEGIN{flag=0}/^[0-9:.]* Ethernet controller:/{flag=1}/^$/{flag=0}/^[ \t]*Kernel modules/{if(flag && (x=index($0,":")))printf "%s\n",substr($0,x+2)}')"
if test -d etc
then
for system in mainsys
#for system in backsys mainsys
do
cp -ar "etc" "/mnt/${system}/"
chown -R root:root "/mnt/${system}/etc"
printf "127.0.0.1 localhost\n127.0.1.1 %s\n::1 localhost\n::1 %s\n" "$(cat etc/hostname)" "$(cat etc/hostname)"
done
fi
BASE_PKGS="runit-init,linux-image-$(dpkg --print-architecture),busybox-static,cryptsetup-initramfs,dropbear-initramfs"
SYSLINUX_PKGS="syslinux,syslinux-efi,syslinux-common,syslinux-utils"
EFI_PKGS="efibootmgr,efitools,efivar,dosfstools"
TOOLS_PKGS="openssh-server,iptables,udhcpc,iproute2"
PKGS="$BASE_PKGS,$SYSLINUX_PKGS,$EFI_PKGS,$TOOLS_PKGS"
# main system pre-setup
mkd /mnt/mainsys/etc
mkd /mnt/mainsys/etc/dropbear-initramfs/
cp srvcryptkey /mnt/mainsys/etc/lukskey
cp authorized_keys /mnt/mainsys/etc/dropbear-initramfs/
cat > /mnt/mainsys/etc/crypttab <<EOF
mainsys PARTLABEL=mainsys none cipher=$CIPHER,size=$KEYSZ,hash=$HASH
mainvar PARTLABEL=mainvar /etc/lukskey cipher=$CIPHER,size=$KEYSZ,hash=$HASH
home PARTLABEL=data /etc/lukskey cipher=$CIPHER,size=$KEYSZ,hash=$HASH
EOF
cat > /mnt/mainsys/etc/fstab <<EOF
tmpfs /tmp tmpfs 0 0
tmpfs /run tmpfs 0 0
/dev/mapper/mainsys / ext4 rw 0 1
/dev/mapper/mainvar /var ext4 rw 0 0
/dev/mapper/data /home ext4 rw 0 0
EOF
# fallback system pre-setup
mkd /mnt/backsys/etc
mkd /mnt/mainsys/etc/dropbear-initramfs/
cp srvcryptkey /mnt/backsys/etc/lukskey
cp authorized_keys /mnt/mainsys/etc/dropbear-initramfs/
cat > /mnt/backsys/etc/crypttab <<EOF
mainsys PARTLABEL=backsys none cipher=$CIPHER,size=$KEYSZ,hash=$HASH
home PARTLABEL=data /etc/lukskey cipher=$CIPHER,size=$KEYSZ,hash=$HASH
EOF
cat > /mnt/backsys/etc/fstab <<EOF
tmpfs /tmp tmpfs 0 0
tmpfs /run tmpfs 0 0
PARTLABEL=backsys / ext4 rw 0 1
PARTLABEL=data /home ext4 rw 0 0
EOF
# installing them
debootstrap --variant=minbase --include=$BASE_PKGS buster /mnt/mainsys
#debootstrap --variant=minbase --include=$BASE_PKGS buster /mnt/backsys
for system in mainsys
#for system in backsys mainsys
do
for user in $(cut -d: -f1 passwords)
do
# vars here are *not* meant to be protected when used
SKEL="$( test -d "${user}" && printf "--skel ${user}" )"
GROUP_LIST="$(sed -n '/'"${user}"'/ s!:!,!gp' passwords | cut -f1,2 -d, --complement)"
GROUPS="$( test -n "${GROUP_LIST}" && printf "-G ${GROUP_LIST}" )"
#TODO create non-existing groups before that
#TODO glibc might have version conflicts for useradd
test "${user}" = "root" || useradd -R "/mnt/${system}" $SKEL $GROUPS --create-home "${user}"
done
cut -d: -f1,2 passwords | chpasswd -R "/mnt/${system}"
for metafs in dev sys proc
do
mount --bind /${metafs} /mnt/${system}/${metafs}
done
chroot /mnt/${system} update-initramfs -u
for metafs in dev sys proc
do
umount /mnt/${system}/${metafs}
done
done
syslinux -i /dev/disk/by-partlabel/BOOTLOADER
cat > /mnt/boot/syslinux.cfg <<EOF
timeout 50
#prompt 0
#ui vesamenu.c32
menu title what should I boot?
append ro crypto=$HASH:$CIPHER:$KEYSZ:0:
default mainsys
label mainsys
menu label debian buster
linux /buster/vmlinuz
initrd /buster/initrd.img
append rootfstype=ext4 cryptroot=PARTLABEL=mainsys cryptdm=root dropbear root=/dev/mapper/mainsys ip=192.168.1.185:::255.255.255.0:test:enp0s8
EOF
mkd /mnt/boot/buster/
cp /mnt/mainsys/initrd.img /mnt/mainsys/vmlinuz /mnt/boot/buster/Pour donner un peu de contexte sur l'idée initiale, je voulais avoir en gros un disque formaté en GPT, voire si je peux utiliser EFI (il me faut encore expérimenter ça) formaté ainsi:
- 1 partition de «data», le «/home», encore que j'ai un doute sur son affectation;
- 1 partition de «bootloader», le «/boot/EFI», d'a peu près 256Mio (histoire d'être peinard);
- 1 partition «backsys», ou système de secours, au cas ou une MàJ pète le principal, avec 768Mio. Son installation est zombifiée, debootstrap échouant avec «si peu» d'espace…
- 1 partition «mainsys», 2Gio, le «/» quoi;
- 1 partition «mainvar», 2Gio, le «/var»;
parce que le VPS en question n'a que 20Gio d'espace disque, et puis, c'est un serveur, 5Gio pour le système, c'est déjà excessif pour moi.
Les systèmes qui résultent de ce script se baserons sur runit, qui dans buster est un est init packagés (avant, il n'y avais que le runsvdir qui l'étais sous forme de paquet assez clean) qui réutilise les scripts de sysV/rc.d, comme l'a fait systemd-init a une époque.
Ils sont aussi très minimaux, et selon ma VM, ça nécessite moins de 600Mio d'espace disque (tiens, c'est gros ça, c'est louche), il reste a installer le confort, mais ça me semble une bonne de travail.
Je voulais le partager, à la fois pour voir vos réactions, parce que, l'air de rien, ce trucs m'a demandé plusieurs jours, et parce que je n'ai pas été foutu de trouver une vraie doc sur comment faire…
Ah, j'oubliais… quand on se log via ssh sur la cible, il faut utiliser la commande cryptroot-unlock.
Merci à ceux qui ont lu jusqu'ici, m'en vais raffiner ça, tester, raffiner, tester, et p'tet même «pousser en prod» (mais probablement pas ce soir, le poussage sur vrai système…).
# Une partition pour les gouverner tous
Posté par Glandos . Évalué à 6.
Ben en fait… c'est bien. Parce que de toutes façons, quand /var est plein parce que les logs ont tout pourri, on peut quand même plus se logger à distance, et tout se pète la gueule. Quand / est tout petit, mais que hé, en fait, on va s'en servir pour mettre un /tmp quelque part.
Finalement, les problèmes arrivent plus vite avec plusieurs partitions.
Alors attention, je parle dans le cas d'un serveur géré par un admin. Pas un serveur avec plusieurs comptes utilisateurs qui peuvent stocker des trucs. Là, évidemment, c'est bien de limiter la casse, notamment avec un /home adapté.
[^] # Re: Une partition pour les gouverner tous
Posté par Psychofox (Mastodon) . Évalué à 4.
Jamais eu de problème à me logger sur une machine car le /var était plein.
[^] # Re: Une partition pour les gouverner tous
Posté par adrrob . Évalué à 2.
En revanche, j'ai déjà eu des soucis pour me logger sur une machine dont le / était plein …
C'est plus safe de mettre /home et /var ailleurs.
[^] # Re: Une partition pour les gouverner tous
Posté par claudex . Évalué à 5.
Moi, je n'en ai jamais eu pour me logguer en ssh sur une machine. C'était dans quelles conditions ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Une partition pour les gouverner tous
Posté par Panhwein . Évalué à 2.
Ca m'est arrivé il y a une semaine.
Chose à préciser, il n'y avait pas de partitions /var, elle fait partit de la racine
C'est /tmp qui était plein.
Et impossible de se loguer, j'ai fait un reboot hard
[^] # Re: Une partition pour les gouverner tous
Posté par freem . Évalué à 2.
Et /tmp étais sur le disque réel, pas un tmpfs?
[^] # Re: Une partition pour les gouverner tous
Posté par nanard . Évalué à 1. Dernière modification le 05 février 2020 à 09:24.
Les partition c'est bien ça permet de mettre des droits adaptés et lvs permet de gérer l'espace assez efficacement.
Après tout est relatif, j'ai ajouté un dd ssd récemment et j'ai pas était plus loin que le formatage et le rejout du volume, n'aillant pas encore sauvegarde jme suis arreté la, j'ai peur que ça pête en cours de route.
Allez tous vous faire spéculer.
[^] # Re: Une partition pour les gouverner tous
Posté par jihele . Évalué à 3.
Ah bon ?
J'ai déjà eu des soucis de log qui explose tout et j'ai déplacé le log sur une partition à part (en fait une partition virtuelle dans un fichier mais c'est pas grave, ça fait un quota).
A l'avenir je pense faire une partition /var séparée sur mes machines.
[^] # Re: Une partition pour les gouverner tous
Posté par freem . Évalué à 2.
C'est vrai et faux. Dans mon cas, je pense être un utilisateur, disons, avancé, et je pense savoir quel espace maxi prendrons certaines partitions.
Et, quand je me trompe sur une machine (ça m'est arrivé, une fois, j'avais rempli
/var/cache/apt-cacherou un truc du genre, j'ai été au plus rapide), ben je suis capable de contourner le problème, avec ou sans LVM.Avec LVM, en vrai, je saurais pas comment faire.
Sans LVM, c'est «facile», il suffit de créer un fichier d'une certaine taille, par exemple avec dd, de le formater en ext4 ou autre, et de lui coller un point de montage. C'est sale, je sais, mais ça marche.
Depuis que ça m'est arrivé, cela dis, je garde systématiquement un espace non alloué sur mes disques qui dépassent les 80 Gio (presque tous). C'est p'tet du gâchis, mais le jour ou y'a besoin pour une raison X ou Y d'une nouvelle partoche, utilisable par n'importe quel système, c'est agréable d'avoir un p'tit espace de 2+Gio a dispo (moins de 5% du disque, et ça diminue avec la capacité du disque).
D'un autre côté, tu as dis «Alors attention, je parle dans le cas d'un serveur géré par un admin.».
Je suis pas admin, j'ai pas les compétences, et pas la vision nécessaire pour ça. Je suis un dev, qui s'est improvisé admin pendant plus de deux ans, parce que le seul a savoir (vaguement, au début, pas beaucoup mieux maintenant) comment marchent les réseaux et systèmes.
Mon recul reste faible, et ira pas plus loin concernant cette boîte, mais mes réglages ont permis d'avoir un dual boot sur des systèmes «embarqués» (~200, sans accès physique, par radio… j'ai appris beaucoup), et l'espace disque (8Gio max, 4Gio sur une majorité du parc, je sais, j'ai joué dans le grand luxe, d'où les «») n'a jamais été un problème, malgré l'usage d'outils pas adaptés (pour diverses raisons).
En théorie, ce dual boot si on poussait les racines que j'ai mises, permettrait un fallback automatique sur système sain si une MàJ merde. Ironiquement, le mécanisme est implémenté que sur les beaglebone black, Das-UBoot étant moins pire que UEFI quand il s'agit de trouver des infos: au moins, y'a le source!
Bref, pour moi, pas besoin d'être admin. Ou du moins, pas de métier… p'tet qu'il suffit d'avoir plus de 30 ans? Se souvenir d'une époque ou il existait des disques durs de moins de 20Gio, ou l'on faisait régulièrement du propre dans les données obsolètes? Je ne sais pas.
[^] # Re: Une partition pour les gouverner tous
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Se souvenir d'une époque ou il existait des disques durs de moins de 20Mio (probablement des Mo d'ailleurs, ça a dû être défini plus tard les Mio), où l'on faisait régulièrement du propre dans les données obsolètes?
[^] # Re: Une partition pour les gouverner tous
Posté par barmic 🦦 . Évalué à 2. Dernière modification le 09 février 2020 à 23:11.
La notation Mio a juste était créé pour rendre compréhensible les puissances d'unité de stockage en base 2. Les notations étaient probablement en MB (mais en comptant en base 2) ou Mb (en base 10 le plus souvent). Ouais ils étaient tout de même de 20 Mio ou moins. Tout comme l'atmosphère terrestre n'a pas changée quand on est passé des bar aux Pa ;-)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une partition pour les gouverner tous
Posté par Benoît Sibaud (site web personnel) . Évalué à 6.
Pendant longtemps, les vendeurs de disque ont pipoté en mélangeant 1000 et 1024 dans leur concours de la plus grosse, de capacité. On avait des disque(ttes) de capacité 1000x1000, 1000x1024, 1000x1000x1024, 1000x1024x1024, etc. pour des raisons de pur marketing. (Alors que maintenant on est au-dessus de ça bien sûr… Le marketing a disparu et les achats sont rationnels).
[^] # Re: Une partition pour les gouverner tous
Posté par barmic 🦦 . Évalué à 1.
Tu as des infos là dessus, parce que je l'ai beaucoup entendu mais rarement vu et ça a tellement une tête de légende urbaine que j'ai un doute.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Une partition pour les gouverner tous
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
2006 (dans les commentaires) : https://www.generation-nt.com/disque-dur-secteur-octet-actualite-12393.html
https://www.dell.com/support/article/fr/fr/frbsdt1/sln115145/non-concordance-entre-la-capacit%C3%A9-du-disque-dur-et-la-capacit%C3%A9-annonc%C3%A9e?lang=fr
https://fr.tipsandtrics.com/hard-drives-explained-767458
…
Ce ne sont pas les liens qui manquent pour expliquer que certains annoncent des multiples de 1000 (des fabricants de disques durs par exemple) et d'autres de 1024 (les systèmes de fichiers notamment).
Ou :
https://fr.wikipedia.org/wiki/Disquette#Caract%C3%A9ristiques_de_quelques_disquettes
« Une idée répandue est qu'il existe des disquettes de capacité standard de 1,44 Mo ou 1,44 Mio, alors que la capacité exacte est de 1 474 560 octets (2×80×18×512), c'est-à-dire :
» (soit 1,44 x 1000 x 1024 octets pour une disquette dite faussement 1,44 Mo ou 1,44 Mio)
[^] # Re: Une partition pour les gouverner tous
Posté par Anthony Jaguenaud . Évalué à 2. Dernière modification le 14 février 2020 à 09:08.
Je confirme, j’avais un PC avec un 8086 vers 1990 avec un disque dur de 30Mo, soit 31 457 280 octets. À l’époque on nous expliquait que c’était pas des vrais kilo mais que ça restait proche, et que ça permettait d’annoncer des chiffres rond pour ne pas expliquer pourquoi un disque devrait faire 31Mo ;-).
Ensuite, le marketing s’en est mêlé, puis un jour, quelqu’un m’a retoqué sèchement, ici même, en me disant que j’avais rien compris et que je parlais de Mio quand j’écrivais Mo :'( Sûrement un jeune qui n’a connu que ça, ou un vieux qui a évolué plus vite que moi :-p
[^] # Re: Une partition pour les gouverner tous
Posté par Kerro . Évalué à 3.
De mémoire ça a basculé de Mio à Mo vers 1990 lorsque les capacités ont été vers 100 Mo/Mio.
Une recherche sur de vieux modèles :
Miniscribe M8425 (vers 1987) vendu pour 20 Mio : 615 pistes / 4 têtes / 17 secteurs de 512 octets --> 20,42 Mio / 21,41 Mo
Kalok KL-320 (vers 1989) vendu pour 20 Mio : 615 pistes / 4 têtes / 17 secteurs de 512 octets --> 20,42 Mio / 21,41 Mo
Maxtor 8051A (1990) vendu pour 40 Mio : 745 pistes / 4 têtes / 28 secteurs de 512 octets --> 40,74 Mio / 42,72 Mo
Maxtor 7080AT (1991) vendu pour 80 Mio : 981 pistes / 10 têtes / 17 secteurs de 512 octets --> 81,43 Mio / 85,39 Mo
Conner CFS210A (1994) vendu pour 210 Mo : 685 pistes / 16 têtes / 38 secteurs de 512 octets --> 203,36 Mio / 213,24 Mo
Seagate Decathlon (1995) vendu pour 850 Mo : 1656 pistes / 16 têtes / 63 secteurs de 512 octets --> 815,06 Mio / 854,65 Mo
Pour trouver la capacité annoncée, ce n'était généralement pas indiqué sur les disques. Il faut se fier aux pubs de l'époque (pas aux annonces actuelles sur eBay pas exemple, qui utilisent le vocabulaire actuel). C'est difficile à trouver pour pas mal de modèles.
[^] # Re: Une partition pour les gouverner tous
Posté par freem . Évalué à 2.
J'avoue, les notations étaient en Mo à l'époque, et je serais incapable de dire s'il s'agit de Méga au sens USI, ou au sens informaticien. J'ai préféré supposer le sens informatien et supposer Mio, donc, qui ne laisse pas de flou sur ce que j'ai voulu dire. Je reste un optimiste après tout (même si le temps me rends puissamment cynique).
# KVM
Posté par Sylvain (site web personnel) . Évalué à 5.
Avec un dedié tu as accès au KVM pour installer l'iso de ton choix ;)
[^] # Re: KVM
Posté par freem . Évalué à 3.
Le prix semble pas être le même.
# Public Cloud OVH au lieu VPS
Posté par Jeremy685 . Évalué à 2.
Je te conseillerais d'utiliser le Public Cloud d'OVH au lieu des VPS classiques, c'est plus pratiques et flexibles, les deux utilisent en théroie la même technologie.
Tu peux spécifier une clé SSH qui sera utilisée lors de l'installation des VMs.
Tu peux ajouter des images disques, bouter, avoir des disques externes et créer des reseaux privés.
Voici le lien:
https://www.ovhcloud.com/fr/public-cloud/
[^] # Re: Public Cloud OVH au lieu VPS
Posté par Kerro . Évalué à 3.
C'est 11 fois plus cher en 24h/24.
[^] # Re: Public Cloud OVH au lieu VPS
Posté par Jeremy685 . Évalué à 3.
Tout dépend de la machine que tu choisis, les prix commencent à 2,99€ / mois si tu choisis payement mensuel. C'est pas plus chez qu'un VPS à mon sens.
[^] # Re: Public Cloud OVH au lieu VPS
Posté par Kerro . Évalué à 4.
Effectivement, je n'avais pas vu qu'on pouvais avoir en réglement mensuel.
https://www.ovhcloud.com/fr/public-cloud/prices/ --> la gamme Sandox rivalise probablement avec un VPS « ordinaire »
# Fatiguant ce bashing ovh
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 05 février 2020 à 10:37.
C'est surtout de ta faute : si tu n'indiques pas de clé ssh dans ton profil, il faut bien, que puisses te connecter sur ton VPS fraîchement installé. Tu veux qu'ils t'envoient ton mot de passe par télépathie ?
Ensuite, faut vraiment pas avoir de bol pour se faire pirater son VPS fraîchement installé, entre le moment où ils t'envoient le mail, et le moment où tu te connectes la première fois et que tu changes ton mot de passe ;-).
"mon compte > services > clés ssh"
Les dépôts sont ceux d'OVH, pour plusieurs raisons :
Mais :
Pour le reste, peut être que l'offre VPS n'est pas ce qu'il te faut pour ton besoin. Je ne sais plus pour les VPS, mais je sais qu'en prenant un serveur physique (j'en gère des dizaines), tu partitionnes comme tu veux avant l'installation de l'OS.
J'aimerais bien un retour d'expérience pour les VPS chez d'autres hébergeurs, voir si c'est aussi "compliqué" de partitionner et de chiffrer…
[^] # Re: Fatiguant ce bashing ovh
Posté par Ben . Évalué à 0.
le point qui m'a fait bizarre, c'est que le login ET le mot de passe soit dans le même message. ça me semblait être le B.A.-BA de la séparation des informations. je dois être un peu old school !
Et pourquoi ne peut-on pas choisir le mot de passe lors de la création du compte / à l'inscription ?
[^] # Re: Fatiguant ce bashing ovh
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 8.
Ce dont on parle, c'est le mot de passe root de la machine qui vient d'être installé. Rien à voir avec le mot de passe de ton compte OVH.
Ce mot de passe root est généré aléatoirement lors de l'installation du système.
[^] # Re: Fatiguant ce bashing ovh
Posté par Ben . Évalué à 0.
Justement, je ne comprends pas pourquoi le mot de passe root ne peut pas être choisi lors de l'initialisation du compte.
Mes dernières installations datent un peu, mais on peut le choisir lors d'une installation normale. Il n'y a pas de paramètre de ce type lors de l'installation du système ?
[^] # Re: Fatiguant ce bashing ovh
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 9.
De quel compte parles-tu ?
Si tu parles du compte OVH, heureusement que le mot de passe root n'est pas indiqué au moment où tu créés ton compte, car cela signifie alors qu'il est stocké/haché quelque part. Conséquence : sécurité moyenne, et surtout, si tu changes ton mot de passe root sur la machine, celui stocké dans ton compte OVH n'est plus valide.
Si tu parles du compte root proprement dit, que tu saisirais dans le formulaire d'installation de la machine, je ne vois pas l’intérêt. Parce que là, tout comme sa génération automatique et envoi par mail comme aujourd'hui, tu ne sais pas où le mot de passe est passé et stocké (même temporairement) lors du processus OVH d'installation de la machine, donc de toute façon, il faut le changer à la première connexion sur ta machine.
Et puis de toute façon, c'est une hérésie d'utiliser un mot de passe pour le compte root : dés la première connexion, la première chose à faire est de changer le mot de passe, poser sa clé ssh, et interdire les connexions par mot de passe (au moins pour le root) dans la config du serveur ssh de la machine.
[^] # Re: Fatiguant ce bashing ovh
Posté par Panhwein . Évalué à 5. Dernière modification le 05 février 2020 à 18:43.
Je suis chez ovh (dédiés) depuis longtemps! Les années 2000.
C'est très simple: Ils génèrent un mot de passe root au moment de l'installation de ta machine.
Et ils te l'envoient par mail. Par contre eux, déposent une clef dans /root/.ssh
Tu peux changer de mot de passe, le perdre, ils auront accès à ta machine.
Quel cas est le plus grave?
1 - Tu loues un dédie ou un vps, ta boite mail est corrompue, pas de chance le vilain nhacker à nageoire jaune n'a que ça a foutre et l'intercepte. Il se connecte, et rootkit le temps que tu aie fini de lire le mail, te connecter, et changer le passe.
2 - Tu loues un dédie ou un vps, ta boite mail est corrompue, ton vilain nacker à najoires jaune à déjà un acces à ton espace client, ou tes mots de passes sont tranquillement à disposition, et évidement hachés/stocké chez ovh. Bonjour les ravages sur une dizaine de machines.
Perso, je préfère leur système actuel, la première solution.
Tu te logues, tu changes ton passe, hy hasta. Et tu laisses leur clef!
Surtout qu'en plus ils te disent: vous serez livré d'ici 2h.
Tu efface le mail terminé
Ce sont quand même pas des débutants chez ovh.
[^] # Re: Fatiguant ce bashing ovh
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Tu réponds à qui ?
Les deux.
Et moi aucune des deux.
La vrai solution, et la plus sécurisée : tu met ta clé publique dans ton compte OVH, tu la choisi lors de l'installation de la machine. Tu reçois un mail sans mot de passe et tu n'as pas de souci de pirate qui scruterai ta boite mail.
Au sujet du compte OVH piraté : ça ne devrait pas arriver. Si cela arrive, c'est que tu n'as pas assez sécurisé son accès (par une double authentification par exemple).
Bref, comme tu dis, OVH ne sont pas des débutants…
[^] # Re: Fatiguant ce bashing ovh
Posté par Anonyme . Évalué à 5.
Ou qu’OVH eux même se fasse pirater.
[^] # Re: Fatiguant ce bashing ovh
Posté par Panhwein . Évalué à 1.
Oui tu as certainement raison!
Mais ovh à une clientèle grand public qui pour la majorité ne savent même pas ce qu'est ssh, et encore moins comment créer une clef! Alors je pense que leur solution est la bonne(au niveau de l'entreprise)
Pour de l'hébergement à l'abri des balles, et réservé aux barbus il doit y avoir certainement mieux.
[^] # Re: Fatiguant ce bashing ovh
Posté par freem . Évalué à 2.
Je suis intéressé, si tu as un nom. S'il me faut apprendre, je le ferais, de toute façon, l'air de rien, je l'ai fait ici.
[^] # Re: Fatiguant ce bashing ovh
Posté par freem . Évalué à 2. Dernière modification le 08 février 2020 à 00:44.
J'ai jamais remarqué de bashing OVH particulier, tu veux dire qu'il y pas que moi?
Tu as donc raté ceci:
Auquel tu réponds ensuite. Je t'en remercie, d'ailleurs. Je reste quand même surpris des liens morts comme celui-ci qui sont inclus dans le mail. Nope, même pas un 404, juste une page neutre.
Aussi, sache qu'il m'a semblé obligatoire de renseigner certaines infos, type @physique. Me suis dis que c'était pour aider la sécurité…
Bref, je dois encore regardé ce cheminement, oui, mais de manière générale, c'est même pas clair qu'il est possible de le faire. La sécu, c'est pour les initiés?
Ça, en vrai, je comprend un point: la bande passante.
Mais pour ça, il est possible d'utiliser un proxy. Bon, pour être honnête, c'est juste un point en plus sur le reste, hein. J'aurai du le mettre en 1er, en théorie, vue que c'est le point le plus faible: après tout, un utilisateur peut vérifier les signatures.
Il s'agit du point que tu mentionnes aussi. Pour le kernel, j'ai un doute, et pour les installs d'outils de monitoring, c'est avéré, ils en ajoutent, sur l'install par défaut. Mais je n'ai pas vu d'indice évident pour expliquer ce qu'ils font. Bon, je doute qu'ils aillent pourrir leurs propres perfs quand même.
Ma foi, s'ils avaient vraiment voulu être lours, ils auraient remplacés les paquets de debootstrap, et j'aurais été bien emmerdé.
En gros, je considère juste avoir enfin assez de «connaissances» a partager pour utiliser une machine dans un DC, et je compte aussi y héberger du code public. Même y coller un blog, si le coeur m'en dit. Rien qui ne mérite un dédié, pour moi.
Je suis preneur aussi. Après, tu sembles rôdé, hors, comme je ne crois pas l'avoir caché, mon retour est celui, à chaud, d'un dev (pas d'un admin, donc, donc pas forcément habitué à utiliser des machines des autres: sur mes machines, je suis dieu, je fais la pluie et le beau temps, la, c'était différent) qui s'y essaie, et essaie de faire les choses pas trop mal.
Mais, je reconnaît avoir été trop loin sur certains points.
NB: voila pourquoi j'apprécie ce site, y'a toujours quelqu'un pour me montrer mes erreurs. Je le pense sérieusement.
[^] # Re: Fatiguant ce bashing ovh
Posté par freem . Évalué à 2.
Désolé, je rajoutes une réponse, enfin, une question.
Qu'est-ce qui empêche d'avoir une signature GPG dans ce type de mails? Personne n'est obligé de la prendre en compte, j'ai utilisé mon contrat actuel pour le vérifier: tous mes mails étaient signés via GnuPG, je n'ai eu aucune question a ce sujet. Je ne suis même pas sûr, en vrai, de ce que ça a impliqué sur le message lui-même.
Ais-je raté un autre épisode?
# intérêt difficile à déterminer.
Posté par Psychofox (Mastodon) . Évalué à 10.
De quel type d'attaque tu voudrais te prémunir avec ce chiffrement ?
Si ça vient de l'extérieur, les attaques se feront au niveau des applis et de l'OS qui a déjà déchiffré le disque. Si c'est pour te protéger de ovh eux-même, tu restes sur du virtualisé donc la clé de déchiffrement est en mémoire sur l'hyperviseur. De plus un vps a tendance à tourner 24h/7j alors que le chiffrement luks n'est vraiment utile que quand le serveur est arrêté.
Du coup je ne sais pas trop en quoi le chiffrement te protège de quoique ce soit ni quel est l'intérêt de tout cela ? Un exemple concret ?
[^] # Re: intérêt difficile à déterminer.
Posté par Samuel (site web personnel) . Évalué à 3.
Une hypothèse : ça protège les images disque (snaphots) qui peuvent être récupérées / envoyées dans un endroit non sûr.
Mais sinon, effectivement, il y a un petit trou dans l'explication ou le raisonnement.
[^] # Re: intérêt difficile à déterminer.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Mouai.. En imaginant qu'un "indélicat" arrive à se procurer un snapshot. Rien ne l'empêche de le remonter sur sa becane avec les bons outils. La VM démarre, déchiffre le disque. Et… au final le chiffrement du disque ne protège rien.
Sauf si le chiffrement s'est fait avec une clé avec passphrase. Mais pas très pratique pour un serveur. D'ailleurs je doute qu'on puisse indiquer la passphrase au lancement d'un serveur sur OVH…
[^] # Re: intérêt difficile à déterminer.
Posté par Anonyme . Évalué à 4.
On a déjà du mal à voir l’utilité du chiffrement sur un VPS, alors si en plus c’est avec une clé en clair, c’est même pas la peine de faire tous ces efforts.
Tu peux utiliser dropbear, qui va démarrer dans l’initramfs et te permettre de déchiffré le disque à travers SSH. Je sais pas comment fonctionne les VPS d’OVH, mais je le fais sur du bare-métal.
[^] # Re: intérêt difficile à déterminer.
Posté par freem . Évalué à 2. Dernière modification le 08 février 2020 à 00:58.
Je ne saurais garantir la sécurité, de toute façon, un autre a accès physique dans ce cas, mais, l'apprentissage était fun, surtout que j'ai trouvé très peu doc sur comment le faire, et pire avec debian (ou il faut passer par l'installateur officiel de debian), c'est pour ça que j'ai pensé que ça serais partageable.
[^] # Re: intérêt difficile à déterminer.
Posté par freem . Évalué à 5.
Si, justement, c'était une des raisons qui m'ont persuadé de faire ça :) jouer avec l'initrd, améliorer ma compréhension du système. Désolé, j'y suis accroc, le LL me donne la possibilité de comprendre comment marche mon système, en automatiser les trucs chiants, simplifier le compliqué, adapter l'outil au côté humain qu'il me reste, et ça, moi, j'aime.
[^] # Re: intérêt difficile à déterminer.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Je crois savoir l'intérêt (relatif): une fois que tu rend la machine, celle-ci est louée à une autre personne. Cette personne pourrait analyser le contenu du disque, et essayer de récupérer le contenu des anciennes partitions (avec beaucoup de patience).
Si les partitions sont chiffrés, cela devient bien plus compliqué. Il faut pouvoir retrouver la clé de déchiffrement de la partition. Ce qui, il me semble, est d'autant plus compliqué qu'il y a de forte chance que l'endroit ou elle était stockée ait été écrasé lors de la réinstallation du système.
Toutefois, cette précaution de chiffrer une partition n'est utile que pour les serveurs physiques. Pour les VM et autres conteneurs "cloud", ce sont des disques virtuels donc, données irrécupérables après recréation des partitions virtuelles.
Et encore, pour les serveurs physiques, OVH dit qu'il détruit toutes les données sur les disques avant de remettre le serveur en location. Par contre je n'ai pas trouvé l'information qui explique en quoi consistait exactement cette destruction.
[^] # Re: intérêt difficile à déterminer.
Posté par Anonyme . Évalué à 4. Dernière modification le 06 février 2020 à 15:29.
On parle de VPS, pas de serveur dédier.
J’espère sérieusement que tu ne chiffres pas tes partitions avec une clef stocké en clair sur la même machine.
Oui, voilà donc ça répond pas à la question : de qui se protège-t-on en chiffrant les disque d’un VPS ?
Ça consiste à faire l’équivalent d’un shred.
[^] # Re: intérêt difficile à déterminer.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
Je ne chiffres pas les partitions de mes serveurs, puisque je n'en vois pas trop l'interet.
Par contre, vraie question : si la clé n'est pas sur le serveur, comme fait-on pour avoir un serveur qui puisse rebooter tout seul ? Ou comment fait-on pour indiquer la clé au redémarrage d'un serveur distant ?
[^] # Re: intérêt difficile à déterminer.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
ok, trouvé : https://benediktkr.github.io/ops/2015/05/01/remote-fde.html
[^] # Re: intérêt difficile à déterminer.
Posté par jyes . Évalué à 5.
La réponse est dans le journal et dans de nombreux commentaires sur cette page : dropbear, un mini-serveur SSH embarqué dans l’initramfs.
Tu as aussi la solution alternative de Samuel qui permet de démarrer la machine mais n’assure aucune sécurité quand le mot de passe est transféré (mais ce serait faisaible avec un « simple » tunnel TLS).
[^] # Re: intérêt difficile à déterminer.
Posté par freem . Évalué à 2.
Si ça fait référence au fait que la clé soit envoyée non-chiffrée dans mon script, il me faut poser 2 questions:
[^] # Re: intérêt difficile à déterminer.
Posté par Anonyme . Évalué à 3. Dernière modification le 09 février 2020 à 21:31.
Tu chiffres
/avec une passphrase et tu chiffres les autres partitions avec des fichiers de clef que tu stockes sur/.[^] # Re: intérêt difficile à déterminer.
Posté par kna . Évalué à 3.
Ou alors, tu fais du LVM sur LUKS
[^] # Re: intérêt difficile à déterminer.
Posté par Anonyme . Évalué à 2.
Oui, j’ai lu « plusieurs partitions » et j’ai pensé à plusieurs disques.
[^] # Re: intérêt difficile à déterminer.
Posté par freem . Évalué à 3.
J'essaies de monter en compétence petit à petit, et je pense que je n'ai pas encore assez de compréhension du fonctionnement interne de LVM pour l'utiliser.
Je ne sais pas pourquoi, il me faut une compréhension relativement bas niveau d'un système pour l'appréhender, et j'ai pas encore étudié LVM.
Ce que j'en comprend, de très loin, c'est que c'est une sorte de méta-format de disque, une sur-couche à GPT/DOS/whatever, qui, j'imagine, considère le disque entier comme un FS, et chaque partition comme un fichier? Enfin, c'est un raccourcis très gros…
Bref, du peu de compréhension que je suppose avoir, je n'aime pas trop l'idée de LVM, sans trop pouvoir expliquer pourquoi. C'est purement subjectif je pense, et se combine au fait que je vois peu d'intérêts objectifs à un truc qui correspond à l'image décrite plus tôt (qui est fausse, j'en suis persuadé).
Mais, si quelqu'un fait de la vulga sur LVM, je serais très curieux de lire ça, et je poserais surement un tas de questions bêtes!
[^] # Re: intérêt difficile à déterminer.
Posté par Anonyme . Évalué à 3.
Si tu es à l’aise avec l’anglais : LVM sur le wiki Archlinux.
Dans une installation classique (sans parler de RAID ou quoi que ce soit), tu aurais quelque chose comme :
[^] # Re: intérêt difficile à déterminer.
Posté par freem . Évalué à 2.
C'est ce que j'ai fait, non?
[^] # Re: intérêt difficile à déterminer.
Posté par freem . Évalué à 2.
Je vais être honnête, je l'ai fait uniquement sur conseil d'une personne (certes, sans expérience pro a ma connaissance) qui a été formée pour ça (être admin), et ses arguments m'ont pas semblé stupides, même s'ils m'ont pas frappé par la pertinence.
Mais, ajoutes à ça le fait de faire un truc que je savais pas faire, et de l'automatiser… ça a titillé mes instincts.
Aussi, je fait de savoir le faire sur un serveur (vps, au pire les mecs ont accès à la ram… et je compte juste y stocker du libre, t'façon…) implique que je saurais le faire sur des machines plus critiques, si besoin est.
# installation automatique avec Debian preseed et LUKS
Posté par Andre Rodier (site web personnel) . Évalué à 5.
Apès une mauvaise expérience avec OVH, j'utiliserai par exemple Vultr ou Linode.
J'avais un disque chiffré avec LUKS, qu'ils ont supprimé, en pensant qu'il ne contenait pas de données.
Pour un disque dur chiffré sur un VPS, j'ai crée ce projet:
https://github.com/progmaticltd/debian-iso-builder
Ce projet permet de créer une image d'installation automatique, avec disque chiffré. Utilise Ansible dans Docker.
Testé avec succès sur Vultr.
# Interface de déchiffrement : web ?
Posté par Samuel (site web personnel) . Évalué à 3.
Bonjour,
Pour le déchiffrement de serveur distant, à ma connaissance la seule option actuellement est d'utiliser dropbear, mini-serveur SSH embarqué dans l'initramfs (c'est ce qui est fait dans ce journal).
Je trouve ça un peu limité : ça réserve ce genre de configurations aux gens qui sont à l'aise avec SSH, c'est-à-dire aux informaticiens tendance Linux. J'aimerai transférer cette responsabilité aux non-techniciens. Dans ce but, j'ai rédigé un prototype/brouillon de serveur web embarqué dans initramfs pour entrer la phrase de passe.
Bon pour le moment le mot de passe circule en clair car TLS ne fonctionne pas donc l'intérêt est nul ! Mais si quelqu'un trouve l'idée intéressante, toutes les contributions sont bienvenues !
[^] # Re: Interface de déchiffrement : web ?
Posté par Anonyme . Évalué à 2.
Wut! Je découvre que busybox intègre un serveur HTTP.
[^] # Re: Interface de déchiffrement : web ?
Posté par freem . Évalué à 2.
Busybox est quasiment une distro, il lui manque surtout un kernel. Par contre, son http, il intègre pas, à ma connaissance, SSL.
Il existe un concurrent à BB, qui s'appelle toybox, l'argument principal étant la licence. Il est un peu tard pour invoquer zenitram, mais j'espère qu'il répondra à mon invocation :) (désolé, Zenitram, mais je te considère comme une référence sur ce genre de sujets)
[^] # Re: Interface de déchiffrement : web ?
Posté par freem . Évalué à 2.
Tu m'excuseras de pas aller lire le code, apprendre a gérer correctement une machine (c'est à dire par scripts, sans interactions humaine) me prendra déjà bien assez de temps.
Par contre: bravo pour l'idée et l'effort!
Je vote pour que tu fasses un journal pour présenter ta solution a ce problème intéressant, parce que d'ici, je vois pleins de problèmes théoriques, genre, justement, la preuve de l'identité par chiffrement ou signature numérique (arf, j'ai un truc a répondre que j'ai oublié du coup).
[^] # Re: Interface de déchiffrement : web ?
Posté par Samuel (site web personnel) . Évalué à 1.
À vrai dire, c'est un tout petit prototype et je n'ai pas le temps d'améliorer pour le moment. Ce qui manque, au minimum :
Ensuite, dans une optique d'utilisabilité plus large il faudrait :
[^] # Re: Interface de déchiffrement : web ?
Posté par freem . Évalué à 3. Dernière modification le 11 février 2020 à 23:20.
Je comprend.
Si c'est faire un vrai paquet source, je peux pas t'aider, mais faire un paquet binaire, c'est assez simple. Ça implique qu'on ait confiance en toi, certes, mais ça sera de toute façon le cas.
Pour moi, la bureaucratie debian, elle n'a de sens que pour faire des deb intégrés au dépôt central, avec un haut degré de qualité.
Du coup, je pense que, pour juste partager un repo a toi qui sera ajouté dans les sources, pas besoin de te prendre trop la tête, suffit de créer un dossier pour le projet foobar
foobar/DEBIANavec divers fichiers, genrecontrol(obligatoire),sha512sum(de mémoire, et pas obligatoire) et autres du même genre.Si tu veux plus d'infos pour faire un truc qui soit installable par dpkg, je peux t'aider, voire contribuer.
J'avoue n'avoir aucune idée de comment traduire les messages de scripts… en C, je sais faire, mais en sh? Ceci est un appel à bonne âme: un journal sur comment traduire du script serait plussé par au moins moi :)
Je suis vexé.
Vraiment.
Parce que, hé, debian 10 intègre
runit-initdans les variantes deinit(même si c'est pas mon fait, mais j'espère rendre mes scripts assez solides pour les contribuer).Blague à part, systemd impacte vraiment l'initrd? Pour dracut, il me semblait que c'est juste un système de de build, une sorte d'autotools spécialisé, et clevis, je connais pas.
Mais, parles-moi un peu plus de tout ça, je souhaite aider a avoir un système debian portable et potentiellement maintenable par un nombre réduit de personnes, et je pense que runit correspond a ma façon de penser, malgré ses défauts (il faudrait que j'étudie nosh, en vrai).
[^] # Re: Interface de déchiffrement : web ?
Posté par Samuel (site web personnel) . Évalué à 1.
S'il y a peu de chaînes de caractères, on peut se contenter de définir un fichier shell par langue, chacun exportant les variables contenant les chaînes de caractères dans une langue particulière, puis au moment de la conception de l'initrd copier la langue voulue dans l'image.
en_US.UTF-8.sh :
fr_FR.UTF-8.sh :
Puis dans le script générant la page web :
systemd peut se charger de déverrouiller un périphérique et chercher le programme approprié pour récupérer le mot de passe auprès de l'utilisateur si besoin. On pourrait imaginer ajouter un "provider de mot de passe" consistant en ce petit serveur. Par contre, un initrd n'embarque a priori pas systemd, donc je ne sais pas si c'est pertinent de chercher dans cette direction.
clevis est un système générique pour déverrouiller des choses, avec plusieurs mécanismes pour stocker/récupérer le secret voulu. Parmi ces mécanismes : sss (Shamir secret) pour diviser le secret en plusieurs bouts, tpm2 pour stocker la clé sur un module matériel dédié à la protection des secrets (Hardware security module), tang consistant à verrouiller le secret par une clé présente sur un serveur, permettant de faire en sorte que le déverrouillage ne se fasse que si l'ordinateur est sur le réseau avec ce serveur (network-bound disk encryption). Clevis est notamment utilisé pour déverrouiller des disques LUKS dans des initrd générés par dracut (cf. par exemple clevis-dracut dans Debian).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.