Le 24/06/15 à 12:23, a écrit :
Je me suis un peu trompé, on peut ne pas mettre de mot de passe,
via le fichier "/etc/shadow", mais c'est prendre un risque...
Lequel ? :
Si on efface le mot de passe dans "/etc/shadow" et que ssh est en rade,
ou mal configuré, il est facile de prendre possession du serveur,
par exemple, via une console KVM, sinon en face physiquement
du serveur.
Si tu modifie /etc/shadow, le fait qu'il y avait ou pas un mot de passe
avant ne change rien au risque, donc je persiste à penser que pas de mo t de
passe est plus sécure qu'un mot de passe.
Daniel
Le 24/06/15 à 12:23, andre_debian@numericable.fr a écrit :
Je me suis un peu trompé, on peut ne pas mettre de mot de passe,
via le fichier "/etc/shadow", mais c'est prendre un risque...
Lequel ? :
Si on efface le mot de passe dans "/etc/shadow" et que ssh est en rade,
ou mal configuré, il est facile de prendre possession du serveur,
par exemple, via une console KVM, sinon en face physiquement
du serveur.
Si tu modifie /etc/shadow, le fait qu'il y avait ou pas un mot de passe
avant ne change rien au risque, donc je persiste à penser que pas de mo t de
passe est plus sécure qu'un mot de passe.
Daniel
Le 24/06/15 à 12:23, a écrit :
Je me suis un peu trompé, on peut ne pas mettre de mot de passe,
via le fichier "/etc/shadow", mais c'est prendre un risque...
Lequel ? :
Si on efface le mot de passe dans "/etc/shadow" et que ssh est en rade,
ou mal configuré, il est facile de prendre possession du serveur,
par exemple, via une console KVM, sinon en face physiquement
du serveur.
Si tu modifie /etc/shadow, le fait qu'il y avait ou pas un mot de passe
avant ne change rien au risque, donc je persiste à penser que pas de mo t de
passe est plus sécure qu'un mot de passe.
Daniel
Le 24/06/15 à 11:40, Sébastien NOBILI a écrit :
SN> Bonjour,
SN>
SN> Le mardi 23 juin 2015 à 17:03, Daniel Caillibaud a écrit :
SN> > Par ex, pour autoriser seulement certaines commandes prédéfinies pour le user foo, dans
SN> > son ~/.ssh/authorized_keys on peut mettre
SN> >
SN> > command="/path/to/shell-foo.sh" ...la clé...
SN>
SN> J'en profite pour une remarque au passage, si l'utilisateur est amené à éditer
SN> des fichiers et qu'on le restreint à l'utilisation de VI, alors on introduit une
SN> énorme faille puisque VI est capable de démarrer un shell. L'utilisateur qu'on
SN> pensait avoir restreint se retrouve avec les pleins pouvoirs.
SN>
SN> Cette remarque s'applique également à sudo.
Je parlais de commande prédéfinies, évidemment pas de truc interactifs, si tu lui donnes accès
à un éditeur en root il peut modifier n'importe quel fichier du serveur (conf ssh ou
syslog comprise), autant lui filer l'accès root directement.
S'il doit modifier un fichier, tu lui créé une commande rsync qui va bien, et il ne pourra
mettre à jour que ce ou ces fichiers (en les éditant chez lui, pas sur le serveur puisqu'il n'a
ni shell ni éditeur).
Le 24/06/15 à 11:40, Sébastien NOBILI <sebnewsletter@free.fr> a écrit :
SN> Bonjour,
SN>
SN> Le mardi 23 juin 2015 à 17:03, Daniel Caillibaud a écrit :
SN> > Par ex, pour autoriser seulement certaines commandes prédéfinies pour le user foo, dans
SN> > son ~/.ssh/authorized_keys on peut mettre
SN> >
SN> > command="/path/to/shell-foo.sh" ...la clé...
SN>
SN> J'en profite pour une remarque au passage, si l'utilisateur est amené à éditer
SN> des fichiers et qu'on le restreint à l'utilisation de VI, alors on introduit une
SN> énorme faille puisque VI est capable de démarrer un shell. L'utilisateur qu'on
SN> pensait avoir restreint se retrouve avec les pleins pouvoirs.
SN>
SN> Cette remarque s'applique également à sudo.
Je parlais de commande prédéfinies, évidemment pas de truc interactifs, si tu lui donnes accès
à un éditeur en root il peut modifier n'importe quel fichier du serveur (conf ssh ou
syslog comprise), autant lui filer l'accès root directement.
S'il doit modifier un fichier, tu lui créé une commande rsync qui va bien, et il ne pourra
mettre à jour que ce ou ces fichiers (en les éditant chez lui, pas sur le serveur puisqu'il n'a
ni shell ni éditeur).
Le 24/06/15 à 11:40, Sébastien NOBILI a écrit :
SN> Bonjour,
SN>
SN> Le mardi 23 juin 2015 à 17:03, Daniel Caillibaud a écrit :
SN> > Par ex, pour autoriser seulement certaines commandes prédéfinies pour le user foo, dans
SN> > son ~/.ssh/authorized_keys on peut mettre
SN> >
SN> > command="/path/to/shell-foo.sh" ...la clé...
SN>
SN> J'en profite pour une remarque au passage, si l'utilisateur est amené à éditer
SN> des fichiers et qu'on le restreint à l'utilisation de VI, alors on introduit une
SN> énorme faille puisque VI est capable de démarrer un shell. L'utilisateur qu'on
SN> pensait avoir restreint se retrouve avec les pleins pouvoirs.
SN>
SN> Cette remarque s'applique également à sudo.
Je parlais de commande prédéfinies, évidemment pas de truc interactifs, si tu lui donnes accès
à un éditeur en root il peut modifier n'importe quel fichier du serveur (conf ssh ou
syslog comprise), autant lui filer l'accès root directement.
S'il doit modifier un fichier, tu lui créé une commande rsync qui va bien, et il ne pourra
mettre à jour que ce ou ces fichiers (en les éditant chez lui, pas sur le serveur puisqu'il n'a
ni shell ni éditeur).
Bonjour,
Comment gérez-vous la mise à jour régulière des mots de passe root sur un ensemble de serveur, avec en option la mise à jour de ces infos dans une base KeePass svp ?
La génération des mots de passe est effectuée avec apg.
David
Bonjour,
Comment gérez-vous la mise à jour régulière des mots de passe root sur un ensemble de serveur, avec en option la mise à jour de ces infos dans une base KeePass svp ?
La génération des mots de passe est effectuée avec apg.
David
Bonjour,
Comment gérez-vous la mise à jour régulière des mots de passe root sur un ensemble de serveur, avec en option la mise à jour de ces infos dans une base KeePass svp ?
La génération des mots de passe est effectuée avec apg.
David
Comment gérez-vous la mise à jour régulière des mots de passe root sur un
ensemble de serveur, avec en option la mise à jour de ces infos dans une
base KeePass svp ?
La génération des mots de passe est effectuée avec apg.
Comment gérez-vous la mise à jour régulière des mots de passe root sur un
ensemble de serveur, avec en option la mise à jour de ces infos dans une
base KeePass svp ?
La génération des mots de passe est effectuée avec apg.
Comment gérez-vous la mise à jour régulière des mots de passe root sur un
ensemble de serveur, avec en option la mise à jour de ces infos dans une
base KeePass svp ?
La génération des mots de passe est effectuée avec apg.
Avoir une carte KVM sur son serveur distant n'est pas un "HS".
C'est la seule solution pour être sûr de pouvoir le contacter
et avoir toujours la main sur lui.
Ton argumentation serait valable si il est possible facilement
de se mettre physiquement face au serveur.
Avoir une carte KVM sur son serveur distant n'est pas un "HS".
C'est la seule solution pour être sûr de pouvoir le contacter
et avoir toujours la main sur lui.
Ton argumentation serait valable si il est possible facilement
de se mettre physiquement face au serveur.
Avoir une carte KVM sur son serveur distant n'est pas un "HS".
C'est la seule solution pour être sûr de pouvoir le contacter
et avoir toujours la main sur lui.
Ton argumentation serait valable si il est possible facilement
de se mettre physiquement face au serveur.
> Avoir une carte KVM sur son serveur distant n'est pas un "HS".
> C'est la seule solution pour être sûr de pouvoir le contacter
> et avoir toujours la main sur lui.
> Ton argumentation serait valable si il est possible facilement
> de se mettre physiquement face au serveur.
Qui reprochait à quelqu'un d'être trop péremptoire ? :) :
Avoir un KVM n'est *pas* la *seule* solution!
Je n'ai jamais eu de KVM, mais je me suis plusieurs fois "enfermé
dehors", en faisant de la merde avec iptables, par exemple.
Une fois, j'ai aussi perdu mon mot de passe root. Sur un serveur.
Et pour réparer, j'ai redémarré ma machine sur un systà ¨me de secours
(fourni par mon hébergeur, qui utilise trinity rescue kit, déma rré par
le réseau, monté en ram), j'ai monté mes disques, chroot é dans le
serveur, et réparé mes erreurs :
C'est sur qu'avec un KVM ç'aurait été plus simple, mais ça n'est
clairement pas la seule solution, surtout qu'elle est plus coûteuse
(beaucoup d'hébergeurs te font payer ce service, et ça demande une IP
supplémentaire).
Bien à vous !
> Avoir une carte KVM sur son serveur distant n'est pas un "HS".
> C'est la seule solution pour être sûr de pouvoir le contacter
> et avoir toujours la main sur lui.
> Ton argumentation serait valable si il est possible facilement
> de se mettre physiquement face au serveur.
Qui reprochait à quelqu'un d'être trop péremptoire ? :) :
Avoir un KVM n'est *pas* la *seule* solution!
Je n'ai jamais eu de KVM, mais je me suis plusieurs fois "enfermé
dehors", en faisant de la merde avec iptables, par exemple.
Une fois, j'ai aussi perdu mon mot de passe root. Sur un serveur.
Et pour réparer, j'ai redémarré ma machine sur un systà ¨me de secours
(fourni par mon hébergeur, qui utilise trinity rescue kit, déma rré par
le réseau, monté en ram), j'ai monté mes disques, chroot é dans le
serveur, et réparé mes erreurs :
C'est sur qu'avec un KVM ç'aurait été plus simple, mais ça n'est
clairement pas la seule solution, surtout qu'elle est plus coûteuse
(beaucoup d'hébergeurs te font payer ce service, et ça demande une IP
supplémentaire).
Bien à vous !
> Avoir une carte KVM sur son serveur distant n'est pas un "HS".
> C'est la seule solution pour être sûr de pouvoir le contacter
> et avoir toujours la main sur lui.
> Ton argumentation serait valable si il est possible facilement
> de se mettre physiquement face au serveur.
Qui reprochait à quelqu'un d'être trop péremptoire ? :) :
Avoir un KVM n'est *pas* la *seule* solution!
Je n'ai jamais eu de KVM, mais je me suis plusieurs fois "enfermé
dehors", en faisant de la merde avec iptables, par exemple.
Une fois, j'ai aussi perdu mon mot de passe root. Sur un serveur.
Et pour réparer, j'ai redémarré ma machine sur un systà ¨me de secours
(fourni par mon hébergeur, qui utilise trinity rescue kit, déma rré par
le réseau, monté en ram), j'ai monté mes disques, chroot é dans le
serveur, et réparé mes erreurs :
C'est sur qu'avec un KVM ç'aurait été plus simple, mais ça n'est
clairement pas la seule solution, surtout qu'elle est plus coûteuse
(beaucoup d'hébergeurs te font payer ce service, et ça demande une IP
supplémentaire).
Bien à vous !
Une fois, j'ai aussi perdu mon mot de passe root. Sur un serveur.
Et pour réparer, j'ai redémarré ma machine sur un système de secours
(fourni par mon hébergeur, qui utilise trinity rescue kit, démarré par
le réseau, monté en ram), j'ai monté mes disques, chrooté dans le
serveur, et réparé mes erreurs :
Donc un système équivalent à un KVM (Kernel-based Virtual Machine),
que je pourrais baptiser un TRK (Trinity Rescue Kit).
Je serais heureux d'avoir des infos sur le "trinity rescue kit",
car si un kvm est une option payante, c'est intéressant pour
tous ceux qui ont un serveur distant.
"Trinity " rescue kit vient-il du bureau du même nom Trinity DEsktop (TDE) ?
Une fois, j'ai aussi perdu mon mot de passe root. Sur un serveur.
Et pour réparer, j'ai redémarré ma machine sur un système de secours
(fourni par mon hébergeur, qui utilise trinity rescue kit, démarré par
le réseau, monté en ram), j'ai monté mes disques, chrooté dans le
serveur, et réparé mes erreurs :
Donc un système équivalent à un KVM (Kernel-based Virtual Machine),
que je pourrais baptiser un TRK (Trinity Rescue Kit).
Je serais heureux d'avoir des infos sur le "trinity rescue kit",
car si un kvm est une option payante, c'est intéressant pour
tous ceux qui ont un serveur distant.
"Trinity " rescue kit vient-il du bureau du même nom Trinity DEsktop (TDE) ?
Une fois, j'ai aussi perdu mon mot de passe root. Sur un serveur.
Et pour réparer, j'ai redémarré ma machine sur un système de secours
(fourni par mon hébergeur, qui utilise trinity rescue kit, démarré par
le réseau, monté en ram), j'ai monté mes disques, chrooté dans le
serveur, et réparé mes erreurs :
Donc un système équivalent à un KVM (Kernel-based Virtual Machine),
que je pourrais baptiser un TRK (Trinity Rescue Kit).
Je serais heureux d'avoir des infos sur le "trinity rescue kit",
car si un kvm est une option payante, c'est intéressant pour
tous ceux qui ont un serveur distant.
"Trinity " rescue kit vient-il du bureau du même nom Trinity DEsktop (TDE) ?
Le Sat, 27 Jun 2015 a écrit :
> On Saturday 27 June 2015 15:46:30 gagou9 wrote:
> > > Avoir une carte KVM sur son serveur distant n'est pas un "HS".
> > > C'est la seule solution pour être sûr de pouvoir le conta cter
> > > et avoir toujours la main sur lui.
> > > Ton argumentation serait valable si il est possible facilement
> > > de se mettre physiquement face au serveur.
> Donc un système équivalent à un KVM (Kernel-based Virtua l Machine),
> que je pourrais baptiser un TRK (Trinity Rescue Kit).
> > C'est sur qu'avec un KVM ç'aurait été plus simple, mai s ça n'est
> > clairement pas la seule solution, surtout qu'elle est plus coûte use
> > (beaucoup d'hébergeurs te font payer ce service, et ça dema nde une
> > IP supplémentaire).
> > Bien à vous !
> J'en profite alors :
> Je serais heureux d'avoir des infos sur le "trinity rescue kit",
> car si un kvm est une option payante, c'est intéressant pour
> tous ceux qui ont un serveur distant.
voiic un article de korben :
http://korben.info/trinity-rescue-kit-quand-linux-vient-au-secours-de-win do
ws.html
bernard
Le Sat, 27 Jun 2015 andre_debian@numericable.fr a écrit :
> On Saturday 27 June 2015 15:46:30 gagou9 wrote:
> > > Avoir une carte KVM sur son serveur distant n'est pas un "HS".
> > > C'est la seule solution pour être sûr de pouvoir le conta cter
> > > et avoir toujours la main sur lui.
> > > Ton argumentation serait valable si il est possible facilement
> > > de se mettre physiquement face au serveur.
> Donc un système équivalent à un KVM (Kernel-based Virtua l Machine),
> que je pourrais baptiser un TRK (Trinity Rescue Kit).
> > C'est sur qu'avec un KVM ç'aurait été plus simple, mai s ça n'est
> > clairement pas la seule solution, surtout qu'elle est plus coûte use
> > (beaucoup d'hébergeurs te font payer ce service, et ça dema nde une
> > IP supplémentaire).
> > Bien à vous !
> J'en profite alors :
> Je serais heureux d'avoir des infos sur le "trinity rescue kit",
> car si un kvm est une option payante, c'est intéressant pour
> tous ceux qui ont un serveur distant.
voiic un article de korben :
http://korben.info/trinity-rescue-kit-quand-linux-vient-au-secours-de-win do
ws.html
bernard
Le Sat, 27 Jun 2015 a écrit :
> On Saturday 27 June 2015 15:46:30 gagou9 wrote:
> > > Avoir une carte KVM sur son serveur distant n'est pas un "HS".
> > > C'est la seule solution pour être sûr de pouvoir le conta cter
> > > et avoir toujours la main sur lui.
> > > Ton argumentation serait valable si il est possible facilement
> > > de se mettre physiquement face au serveur.
> Donc un système équivalent à un KVM (Kernel-based Virtua l Machine),
> que je pourrais baptiser un TRK (Trinity Rescue Kit).
> > C'est sur qu'avec un KVM ç'aurait été plus simple, mai s ça n'est
> > clairement pas la seule solution, surtout qu'elle est plus coûte use
> > (beaucoup d'hébergeurs te font payer ce service, et ça dema nde une
> > IP supplémentaire).
> > Bien à vous !
> J'en profite alors :
> Je serais heureux d'avoir des infos sur le "trinity rescue kit",
> car si un kvm est une option payante, c'est intéressant pour
> tous ceux qui ont un serveur distant.
voiic un article de korben :
http://korben.info/trinity-rescue-kit-quand-linux-vient-au-secours-de-win do
ws.html
bernard