Reprise du message précédent :
Un seul device. Et une seule VM dessus. Limite la virtu sert a rien (mais en fait si pour des raisons très spécifiques).
J'suis dans une branche où 80+To de stockage sur un serveur, c'est normal

En même temps 80To c'est pas extraordinaire et 8To c'est limite ridicule

Ça dépend. Avec 8 dac et en prenant 16U au total, ouai.
Dans 2U, ça commence à être pas mal. Surtout avec du compute et pas un Xeon D
Dans 1U en full flash, ça doit être sexy

Juste pour faire des snapshots  

Y'en a qui jouent avec des pure storage (fa) et ansible/api rest ?

Drapal  

Pendant ce temps chez Cisco
 
https://www.reddit.com/r/networking [...] nd_sydney/

 
Are you happy with the customer service?  

"He said he doesn't care!"

Ca va faire du boulot pour Plam  

https://fr.aliexpress.com/item/4000 [...] 724dsLv2So
 
Tout le monde a son masque ?

Niiiice

3.12€ le masque, + 2,49€  de frais de port..
 

Il est moche et si vous portez un masque c'est que vous avez fait un mauvais choix

 
C'est sûr qu'en ne faisant rien de ses journées, c'est difficile d'être le héros de quelqu'un au taff

Je suis très actif

 
C’est le héros de la hype  

un classique    
 
https://www.redbubble.com/i/mug/sys [...] duct-title

M'sieurs d'ames je déterre un vieux truc mais on discutait de la meilleure façon de se connecter en tant que root sur un serveur.
 
Vous êtes plutôt root@server via clé ssh ou user@server puis sudo ... ?

Jamais root.
Et sudo que si nécessaire.

root@serveur avec clé ssh depuis des bastions

Ca nous évite de taper sudo devant chaque commandes ou de faire un sudo su - des qu'on est saoulé du sudo

Après ça dépend aussi des outils/scripts/playbooks don't on dispose pour se facilité la vie

 
Mais quand je me connecte sur un serveur c'est dans tous les cas pour faire des manip root
 

 
C'est ce que je fais aussi, SSH root depuis ma machine. Très rarement depuis une autre.

 
plusieurs avantage à ne pas se connecter en root direct ;

• principe du least privilege ; valable surtout pour les plus grosses équipes, mais si un jour vous avez besoin qu'une personne puisse faire certaines actions seulement, si sudo est en place c'est plus facile
• ça rajoute une forme de 2fa ; il faut avoir une chose (clé ssh, certificat), et savoir une chose (le pwd user pour sudo). Même si avoir du vrai 2fa pour se connecter au serveur/bastion c'est encore mieux
• dans une équipe, un gros intérêt c'est de pouvoir faire de l'audit. Si tout le monde se connecte en root, impossible de savoir qui a fait quoi et quand.
• gestion des clés simplifiées ; ça évite de devoir enlever et remettre des clés à la mains ( ) voire de parser l'authorized_keys de root ( ). On peut avoir plusieurs fichiers authorized_keys, mais chaque modif de liste suppose alors de toucher à la conf sshd. Ce point peut être limiter si on utilise de la gestion de config (ce que tout le monde fait j'espère )

on se connecte plus aux machines

Ici c'est, autant que possible, SSH avec user (traçabilité) et sudo/password LDAP ou clef SSH, et à travers un VPN Wireguard (chaque VM a une patte dans le réseau « privé », et uniquement nécessaire une IP publique si besoin dans un autre réseau public). Aucun SSH n'écoute sur une IP publique, sauf une machine de rebond en cas de VPN down (et qu'avec une clef SSH, pas de root).

Ça permet d'avoir à la fois de la souplesse et en même temps de pas sacrifier à la sécu

Tiens chez nous on va déployer de L'IAM avec OneIdentity.

Je ferais un retour.

D'autres groupes que root ou sudoers existent, et d'autant plus manageable avec des cgroups pour isoler les systèmes qui ont besoin d'accès spécifiques.
Wheel (sans polkit/systemd) permet de faire toute l'admin soft, sudoers (sans polkit/systemd) permet de faire l'admin soft + 90% du hard. Faut vraiment en avoir besoin pour devoir faire du root (changement de kernel, modif des uid/partitions/mount système), et ce, dans le cadre du bare. Sinon, c'est isolation et démerde toi dans ton périmètre.

 
  je veux bien effectivement.
 
Tu as des infos sur le choix du produit vs un Okta ou autre ?
(moi, c'est ça que je recherche typiquement: okta vs OneIdentity vs un outil non saas type IdentityServer)

Ah bah c'est des appliances physiques chez nous

En lisant cette page, on se demande pourquoi la majorité des distributions bloque par défaut l'accès ssh pour le compte root  

Pour faire chier ceux qui bossent sûrement

Je trouve moins hypocrite de se connecter en root directement et de l'assumer que de se connecter avec un user et taper sudo su - en guise de premiere commande (déjà vu des centaines de fois)

Suivant ce qu'on a à faire, ajouter sudo à chaque fois c'est penible. Il y a sûrement des alternatives, mais comme partout, il faut du temps pour changer les gens et l'entreprise.

Dans un monde parfait, Puppet/ansible/autre et on ne se connecte plus sur les serveurs pour les taches de bases, et seulement pour régler des problèmes

root direct (via clé ssh commune) pour le n3 unix dans mon ancien boulot et accès via compte d'équipe pour tout le reste (on avait aussi cette méthode) avec sudo selon les droits.

Mais tout était loggué, donc on pouvait savoir qui avait fait quoi, même pour notre équipe.

 
faire chier ceux qui bossent, ce qu'il faut pas lire    
 
allez je remets ici quelques unes des raisons  

et pour info, tu peux toujours logger/auditer meme après un sudo su - (d'ailleurs ya que moi qui utilise sudo -i plutôt ?)
 

 
comment tu audites si il n'y a qu'un seul compte avec une seule clé ?    
 
 
En passant je remets ça là, ça devrait être une lecture obligatoire https://www.ssi.gouv.fr/uploads/201 [...] r-v1.2.pdf

Sauf que même comme ça, tu peux tracer qui est passé en Root et quelles commandes il a tapé en Root. C'est pas le cas si tu te connecte direct en root. Et je parle même pas de révocation des accès.
Perso je suis plus sudo -s sinon

root avec clé ssh personnel pour l’équipe système (petite équipe)
user interactif commun par mdp ou clé ssh personnel pour le reste (en fonction de l’historique du service, clé ssh par défaut maintenant)
gestion des clés ssh avec ansible
 
On a de la sécurité mais niveau log c’est pas fou à part la clé ssh utilisée. Au moins j’arrive à faire évoluer tout ça dans le bon sens.
 
Jo dois revoir énormément nos process pour passer à du compte nominatif…  

C'est ton point de vue, et comme le trou du cul, tout le monde en a un, et ils sont tous égaux

Ici tout est enregistré par CyberArk et on passe par son PSMP donc aucun problème de traçabilité

Je me suis déjà tapé la propagande de l'anssi pour la LPM et c'est beau la théorie. Mais en pratique pour de la prod critique où la réactivité est importante, c'est inadapté.

C'est l'éternel discussion entre les admins/users et les personnes en charge de la sécurité.

Un serveur rend un service et si c'est trop compliqué/long pour le maintenir en état de rendre ce service à cause de la sécurité, il y a un problème quelque part

Bref c'est un débat sans fin root ou pas root, chacun à sa vision, ses contraintes, ses habitudes, etc

Mais ça anime des topics sur internet

Centrify, CyberArk et sailpoint ici pour tout ça

Parce que pour le n3 Unix, tu faisais bastion-> serveur du n3 Unix-> accès root direct à tout le parc, donc tu es bien connecté sur le bastion avec ton compte et ta clé perso, ce qui permet de savoir qui fait quoi, vu que l'audit commence au niveau du bastion.

 C'est une belle merde cyberark.
Maintenant, j'ai wallix, c'est pas mal.

Ou alors c'est que tu sais pas faire.
Parceque chez moi, ça pause pose a peu près aucune difficulté

 
Si ça "pause" effectivement, ya aucune difficulté ...  
 
Et on va peut-être pas relancer ici les échanges désagréables du topic des aigris, hein ?