Re: Cryptsetup - impossible d'accéder à une machine Jessie chiffrée

[Pascal Hambourg]

Le 06/09/2017 à 23:48, roger.tar...@free.fr a écrit :


J'ai tenté le Debian Recovery mode proposé par Grub2 pour lancer un shell et 
jeter un oeil, mais j'atterris en fait sur le module qui demande la passphrase 
comme pour un boot normal.
Je peux éditer les commandes avant le boot avec 'e'.

C'est peut-être là qu'il faut indiquer de lancer un minishell de secours ?
Quelle commande ?


Il faut ajouter l'option "break" à la ligne de commande du noyau qui 
commence par "linux".
Mais de toute façon, il me semble que si on échoue à ouvrir le volume 
chiffré qui contient la racine, on tombe automatiquement sur le shell de 
secours de l'initramfs. Lorsque cryptsetup est présent, la disposition 
du clavier devrait être configurée dès cette étape.



Pour info, là, j'arrive juste à lancer le shell du Debian 4 de ma clef USB. 
Après, je suis sec.


Debian 4 ?
L'installateur Debian en mode rescue est une alternative au shell de 
secours de l'initramfs.



Si j'arrive à lancer un shell,
je devrai être capable de tester si le déchiffrement fonctionne 


Il me semble que la commande est incomplète : elle devrait contenir le 
nom du volume device-mapper créé pour accéder au contenu en clair.

Re: Cryptsetup - impossible d'accéder à une machine Jessie chiffrée

[roger . tarani]

Bonsoir Jean-Marc,

C'est un PC. 
J'utilise Grub 2. 
J'ai tenté le Debian Recovery mode proposé par Grub2 pour lancer un shell et 
jeter un oeil, mais j'atterris en fait sur le module qui demande la passphrase 
comme pour un boot normal.
Je peux éditer les commandes avant le boot avec 'e'. 

C'est peut-être là qu'il faut indiquer de lancer un minishell de secours ?
Quelle commande ?

Pour info, là, j'arrive juste à lancer le shell du Debian 4 de ma clef USB. 
Après, je suis sec. 

Si j'arrive à lancer un shell, 
je devrai être capable de tester si le déchiffrement fonctionne 

Ensuite, ok pour monter (si ça déchiffre). 

On verra pour monter et réparer le système plus tard !

Merci





- Original Message -
From: Jean-Marc 
To: Liste Debian 
Sent: Wed, 06 Sep 2017 22:25:55 +0200 (CEST)
Subject: Re: Cryptsetup - impossible d'accéder à une machine Jessie chiffrée

Wed, 6 Sep 2017 19:08:39 +0200 (CEST)
roger.tar...@free.fr écrivait :

> Bonjour Jean-Marc,

bonsoir Roger,

> 
> Oui, j'ai aperçu des discussions de forum sur ce problème suite à update 
> system (qui faisait passer le clavier en qwerty voir 
> http://linuxfr.org/forums/linux-debian-ubuntu/posts/resolu-cryptsetup-est-passe-en-qwerty)

Cette discusion semble décrire un problème similaire, effectivement.

> 
> Non, je n'ai pas vu de problème enregistré chez Debian mais ai-je bien 
> cherché ??
> 
> Oui j'ai un accès physique à la machine et j'ai déjà démarré avec un LiveCD 
> sur USB juste pour observer que le disque apparaît bien. 

C'est un PC ? Peux-tu interrompre le boot ?
Et passer sur un shell de secours, par exmple ?
Histoire de confirmer ou infirmer la configuration du clavier ?

Je ne sais pas ce tu utilises comme programme d'amorçage.
Vérifie si tu peux interrompre la séquence de démarrage pour faire ces 
vérifications.

> Mais je n'ai effectué AUCUNE commande avant de savoir quoi faire exactement. 
> 
> Je comprends que la commande  que tu proposes est sans 
> risque. 

 ne fait 
qu'ouvrir/déchiffrer le périphérique.

Tu n'y auras accès et tu ne pourras modifier son contenu que si tu le montes.

Une doc' intéressante sur luks ici :
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption

> Pour éviter tout dommage lié à une mauvaise manip/à mon modeste niveau, y 
> a-t-il besoin de sauvegarder qqchose avant ?...
> (Image du disque, sauvegarde d'un fichier de boot, etc. )

Une copie de type image disque du périphérique bloc est utile pour éviter une 
perte liée à une erreur de manip', oui.

> 
> Desolé pour ma prudence !

Pas de soucis.

> 
> Merci beaucoup

De rien,

Jean-Marc 

P.S. merci de répondre à la liste. Cette discussion peut être utile à d'autres.

gnome - tracker HS ?

[Jean-Marc]

salut la liste,

Je viens de remarque que mon bureau Gnome (Debian buster) ne retrouve plus les 
fichiers quand je tape sur superKey puis que je rentre les premières lettres du 
fichier.

D'autres que moi rencontreaient le même soucis ?

Un effet de bord du début de mise à jour vers la version 3.25 de certains 
morceaux de Gnome ?

Bonne soirée.

Jean-Marc 


pgp1v_Lgp_Rce.pgp
Description: PGP signature

Re: ftp-upload avec ftps ?

[Pierre L.]

Le 06/09/2017 à 22:06, Thierry Bugier a écrit :
> Et si on est en mode SSL explicite c'est au client de réclamer un
> basculement en SSL. du coup si le client ne la réclame pas et envoie
> des identifiants, ils seront envoyés en clair. Même si le serveur les
> rejette car la communication n'est pas chiffrée, des identifiant
> (potentiellement VALIDES) auront transité en clair.
Il apparaît pourtant possible de configurer le serveur FTP pour qu'il
rejette systématiquement les connexions non chiffrées...
Le login/pass et tout le reste passera en chiffré automatiquement, sur
la demande du serveur. Je pense qu'il s'agit de la config par défaut ?
Chez proftpd (désolé pour l'anglais :s)
http://www.proftpd.org/docs/howto/TLS.html :

Question: Does FTPS protect both the control connection *and* the data
connections?
Question: Short answer: yes.

The long answer is, of course, that it depends. In the case of
|mod_tls|, it depends on your |TLSRequired| setting. If you use:

TLSRequired on

then you are configuring |mod_tls| to *require* SSL/TLS protection for
both control connections (/e.g./ protecting the username and password
used to log in) /and/ data connections. If you have:

  TLSRequired off

then it is up to the FTPS client whether both control and data
connections will be protected via SSL/TLS. Other |TLSRequired| settings
can be used to specify specific combinations: data connections only,
control connections only, authentication plus data data connections
only, /etc/. The |TLSRequired| documentation
 has the details.
(dommage, erreur 404 pour le lien vers la doc°)

> Je ne dis pas le contraire, mais ssh est si facile à mettre en oeuvre
> et sans risque majeur d'erreur ! 
>
> apt install openssh-server et hop ! (après les paranos iront désactiver
> le port forwarding et autres joyeusetés)
Justement j'essaie de temps en temps à heure perdue de comprendre
comment ces histoires d’échanges de clés entre serveurs fonctionnent,
j'ai rien capté ! Je pense utiliser rsync via SSH, avec tâches cron
derrière qui gèrent l'automatisme du truc... Où trouver ces clés, où les
installer pour que ca fonctionne sans les mots de passe, comment bien
configurer le serveur ssh (et les clients) pour un max de sécurité
(virer "root" me parait la base car j'aime pas beaucoup savoir que mon
serveur pourra être administrable par n'importe qui via internet, éviter
que les autres comptes utilisateurs puissent fouiner dans tout le
système... etc...). Mais là c'est un autre sujet ;)))  (apparemment
assez touffu !)



signature.asc
Description: OpenPGP digital signature

Re: Cryptsetup - impossible d'accéder à une machine Jessie chiffrée

[Jean-Marc]

Wed, 6 Sep 2017 19:08:39 +0200 (CEST)
roger.tar...@free.fr écrivait :

> Bonjour Jean-Marc,

bonsoir Roger,

> 
> Oui, j'ai aperçu des discussions de forum sur ce problème suite à update 
> system (qui faisait passer le clavier en qwerty voir 
> http://linuxfr.org/forums/linux-debian-ubuntu/posts/resolu-cryptsetup-est-passe-en-qwerty)

Cette discusion semble décrire un problème similaire, effectivement.

> 
> Non, je n'ai pas vu de problème enregistré chez Debian mais ai-je bien 
> cherché ??
> 
> Oui j'ai un accès physique à la machine et j'ai déjà démarré avec un LiveCD 
> sur USB juste pour observer que le disque apparaît bien. 

C'est un PC ?  Peux-tu interrompre le boot ?
Et passer sur un shell de secours, par exmple ?
Histoire de confirmer ou infirmer la configuration du clavier ?

Je ne sais pas ce tu utilises comme programme d'amorçage.
Vérifie si tu peux interrompre la séquence de démarrage pour faire ces 
vérifications.

> Mais je n'ai effectué AUCUNE commande avant de savoir quoi faire exactement. 
> 
> Je comprends que la commande  que tu proposes est sans 
> risque. 

 ne fait 
qu'ouvrir/déchiffrer le périphérique.

Tu n'y auras accès et tu ne pourras modifier son contenu que si tu le montes.

Une doc' intéressante sur luks ici :
https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption

> Pour éviter tout dommage lié à une mauvaise manip/à mon modeste niveau, y 
> a-t-il besoin de sauvegarder qqchose avant ?...
> (Image du disque, sauvegarde d'un fichier de boot, etc. )

Une copie de type image disque du périphérique bloc est utile pour éviter une 
perte liée à une erreur de manip', oui.

> 
> Desolé pour ma prudence !

Pas de soucis.

> 
> Merci beaucoup

De rien,

Jean-Marc 

P.S. merci de répondre à la liste.  Cette discussion peut être utile à d'autres.


pgpsLn2WeVVQa.pgp
Description: PGP signature

Re: ftp-upload avec ftps ?

[Thierry Bugier]

Le mercredi 06 septembre 2017 à 19:29 +0200, Pierre L. a écrit :
> Salut,
> 
> Le 06/09/2017 à 16:44, Thierry Bugier a écrit :
> > SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour
> > l'envoi
> > de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
> > requiert l'ouverture d'au moins 2 ports: 22 pour le canal de
> > commandes
> > et 1 port ou une plage de ports pour le transfert de fichiers.
> 
> FTPS, oui c'est le transfert entre un client FTP et un serveur FTP.
> Le S
> pour la version sécurisée par chiffrement
> Port 21 selon la convention, mais on peut le changer. C'est par ici
> que
> le client viendra "causer" au serveur.
> Puis le serveur proposera une fourchette de port (passif) pour le
> transfert de fichiers.
> 
> > Il faut aussi configurer le mode passif ou actif sur les
> > passerelles du client,
> > et du serveur... 
> 
> Uniquement du coté serveur. Le client reçoit automatiquement les
> infos à
> propos des ports passifs à utiliser ;)
> Parfois dans un client graphique comme Filezilla, c'est mieux de lui
> annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).
> 
> > Bref, un vrai bazar, sans compter que la transmission des
> > identifiants peut encore se faire en clair avant le basculement en
> > mode chiffré.
> 
> A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
> rendant la connexion chiffrée, et une fois que le client a accepté,
> hop
> le client envoie l'identifiant + pass au serveur, le tout entant
> chiffré.

Et si on est en mode SSL explicite c'est au client de réclamer un
basculement en SSL. du coup si le client ne la réclame pas et envoie
des identifiants, ils seront envoyés en clair. Même si le serveur les
rejette car la communication n'est pas chiffrée, des identifiant
(potentiellement VALIDES) auront transité en clair.

Comme on n'a pas forcément la main sur la configuration des clients,
c'est très dangereux, et ceux qui ne maîtrisent pas assez bien le sujet
auront vite fait de se mettre en péril.

> 
> > Du coup j'ai estimé il y a pas mal d'années que FTP est un
> > protocole
> > obsolète et quelques lectures que j'ai pu avoir vont dans ce sens.
> > SFTP
> > est bien plus facile à mettre en oeuvre et est plus sûr.
> 
> Le FTP c'est vieux comme les rues,
> c'est dans les vieux pots ;)

Je ne dis pas le contraire, mais ssh est si facile à mettre en oeuvre
et sans risque majeur d'erreur ! 

apt install openssh-server et hop ! (après les paranos iront désactiver
le port forwarding et autres joyeusetés)

> Et en plus si c'est chiffré comme il faut, c'est pénard ;)
> Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS
> 
> Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer
> ;)
> 

Re: Re: configuration reseau/serveur

[nico beal]

Envoyé de mon iPad

Re: ftp-upload avec ftps ?

[cont...@baal.fr]

bonjour,

moi j'utilise lftp; apt-get install lftp ;

quelques exemples http://momh.fr/tutos/Linux/lftp

moi j'utilise :lftp -c "open -u utilisateur,mot_de_passe ip_ou_dns; 
set ftp:ssl-allow yes; set ssl:verify-certificate no; mirror -vvv -e -R 
-x .banner dossier/local dossier/destination"


pour les scripts




Le 06/09/2017 à 19:29, Pierre L. a écrit :

Salut,

Le 06/09/2017 à 16:44, Thierry Bugier a écrit :

SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour l'envoi
de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
requiert l'ouverture d'au moins 2 ports: 22 pour le canal de commandes
et 1 port ou une plage de ports pour le transfert de fichiers.

FTPS, oui c'est le transfert entre un client FTP et un serveur FTP. Le S
pour la version sécurisée par chiffrement
Port 21 selon la convention, mais on peut le changer. C'est par ici que
le client viendra "causer" au serveur.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.


Il faut aussi configurer le mode passif ou actif sur les passerelles du client,
et du serveur...

Uniquement du coté serveur. Le client reçoit automatiquement les infos à
propos des ports passifs à utiliser ;)
Parfois dans un client graphique comme Filezilla, c'est mieux de lui
annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).


Bref, un vrai bazar, sans compter que la transmission des identifiants peut 
encore se faire en clair avant le basculement en mode chiffré.

A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
rendant la connexion chiffrée, et une fois que le client a accepté, hop
le client envoie l'identifiant + pass au serveur, le tout entant chiffré.


Du coup j'ai estimé il y a pas mal d'années que FTP est un protocole
obsolète et quelques lectures que j'ai pu avoir vont dans ce sens. SFTP
est bien plus facile à mettre en oeuvre et est plus sûr.

Le FTP c'est vieux comme les rues,
c'est dans les vieux pots ;)
Et en plus si c'est chiffré comme il faut, c'est pénard ;)
Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS

Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer ;)

Re: ftp-upload avec ftps ?

[Pierre L.]

Salut,

Le 06/09/2017 à 16:44, Thierry Bugier a écrit :
> SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour l'envoi
> de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
> requiert l'ouverture d'au moins 2 ports: 22 pour le canal de commandes
> et 1 port ou une plage de ports pour le transfert de fichiers.
FTPS, oui c'est le transfert entre un client FTP et un serveur FTP. Le S
pour la version sécurisée par chiffrement
Port 21 selon la convention, mais on peut le changer. C'est par ici que
le client viendra "causer" au serveur.
Puis le serveur proposera une fourchette de port (passif) pour le
transfert de fichiers.

> Il faut aussi configurer le mode passif ou actif sur les passerelles du 
> client,
> et du serveur... 
Uniquement du coté serveur. Le client reçoit automatiquement les infos à
propos des ports passifs à utiliser ;)
Parfois dans un client graphique comme Filezilla, c'est mieux de lui
annoncer qu'il s'agit d'un serveur explicit (avec ports passifs).

> Bref, un vrai bazar, sans compter que la transmission des identifiants peut 
> encore se faire en clair avant le basculement en mode chiffré.
A mon avis c'est l'inverse. Il y a échange de clés dans un premier,
rendant la connexion chiffrée, et une fois que le client a accepté, hop
le client envoie l'identifiant + pass au serveur, le tout entant chiffré.

> Du coup j'ai estimé il y a pas mal d'années que FTP est un protocole
> obsolète et quelques lectures que j'ai pu avoir vont dans ce sens. SFTP
> est bien plus facile à mettre en oeuvre et est plus sûr.
Le FTP c'est vieux comme les rues,
c'est dans les vieux pots ;)
Et en plus si c'est chiffré comme il faut, c'est pénard ;)
Petit bouquinage rapide du soir : https://fr.wikipedia.org/wiki/FTPS

Je pense ne pas avoir raconté de bêtises, si un "sage" peut confirmer ;)



signature.asc
Description: OpenPGP digital signature

Re: Cryptsetup - impossible d'accéder à une machine Jessie chiffrée

[Jean-Marc]

Wed, 6 Sep 2017 13:48:47 +0200 (CEST)
roger.tar...@free.fr écrivait :

> Bonjour,

bonjour Roger,

> Le chiffrement du volume a été configuré avec l'installateur de Debian Jessie 
> vers octobre 2016 (LVM+Cryptsetup). 
> Aucun problème jusqu'à avril-mai 2017. Puis impossible de relancer la machine 
> vers juin. 
> 
> Nous sommes certain de la passphrase. 
> 
> Certaines personnes auraient rencontré un tel problème après une mise à jour. 

As-tu trouvé des bugs enregistrés chez Debian relatant ce genre de problème ?

> 
> Que faut-il vérifier ?

As-tu un accès physique à la machine ?

Si c'est le cas, j'essayerai de la démarrer avec un LiveCD pour essayer un 
 manuel.

> 
> Merci


Jean-Marc 


pgpI7EKlt0aO_.pgp
Description: PGP signature

Re: ftp-upload avec ftps ?

[Thierry Bugier]

Bonjour

Si je me souviens bien SFTP n'est pas FTPS

SFTP est pour l'envoi de fichier par serveur SSH, FTPS est pour l'envoi
de fichiers avec un serveur FTP prenant en charge SSL/TLS. FTP(S)
requiert l'ouverture d'au moins 2 ports: 22 pour le canal de commandes
et 1 port ou une plage de ports pour le transfert de fichiers. Il faut
aussi configurer le mode passif ou actif sur les passerelles du client,
et du serveur... Bref, un vrai bazar, sans compter que la transmission
des identifiants peut encore se faire en clair avant le basculement en
mode chiffré.

Du coup j'ai estimé il y a pas mal d'années que FTP est un protocole
obsolète et quelques lectures que j'ai pu avoir vont dans ce sens. SFTP
est bien plus facile à mettre en oeuvre et est plus sûr.


Le mercredi 06 septembre 2017 à 16:26 +0200, Artur a écrit :
> Effectivement. J'étais un peu réticent, mais ça le fait très bien :
> 
> $ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
> ftp://user:pass@host
> 
> sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça
> marche,
> mais c'est une autre config que la mienne (cf. la réponse de Jean-
> Paul).
> A moins que j'ai loupé un truc.
> 
> Merci.
> 
> Le 06/09/2017 à 15:51, Dominique Asselineau a écrit :
> > curl supporte à peu près tous les protocoles
> 
> 

Re: ftp-upload avec ftps ?

[Dominique Asselineau]

Artur wrote on Wed, Sep 06, 2017 at 04:26:35PM +0200
> Effectivement. J'étais un peu réticent, mais ça le fait très bien :
> 
> $ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
> ftp://user:pass@host
> 
> sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça marche,
> mais c'est une autre config que la mienne (cf. la réponse de Jean-Paul).
> A moins que j'ai loupé un truc.

Sftp n'est pas ftps effectivement.

Dominique
--

Re: ftp-upload avec ftps ?

[Artur]

Effectivement. J'étais un peu réticent, mais ça le fait très bien :

$ /usr/bin/curl --silent --ssl --upload-file file_to_upload.txt
ftp://user:pass@host

sftp, par contre, utilise le serveur ssh, pas le serveur ftp. Ça marche,
mais c'est une autre config que la mienne (cf. la réponse de Jean-Paul).
A moins que j'ai loupé un truc.

Merci.

Le 06/09/2017 à 15:51, Dominique Asselineau a écrit :
> curl supporte à peu près tous les protocoles

-- 
Cordialement,
Artur.

Re: ftp-upload avec ftps ?

[Jean-Paul Bouchet]

On 06/09/2017 15:35, Artur wrote:

Bonjour les gens,

J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
ligne de commande d'uploader un fichier sur un serveur ftp.
Ça marche très bien, pas de souci.

Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
la même manière (dans un script et avec un un serveur ftp avec TLS). Une
idée de l'outil qui permettrait de faire ça, svp ?



sftp — secure file transfer program
sftp -b batchfile [user@]host

Re: ftp-upload avec ftps ?

[Dominique Asselineau]

Artur wrote on Wed, Sep 06, 2017 at 03:35:20PM +0200
> Bonjour les gens,
> 
> J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
> ligne de commande d'uploader un fichier sur un serveur ftp.
> Ça marche très bien, pas de souci.
> 
> Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
> la même manière (dans un script et avec un un serveur ftp avec TLS). Une
> idée de l'outil qui permettrait de faire ça, svp ?

curl supporte à peu près tous les protocoles

Dominique
--

ftp-upload avec ftps ?

[Artur]

Bonjour les gens,

J'utilise un petit utilitaire appelé ftp-upload qui permet depuis la
ligne de commande d'uploader un fichier sur un serveur ftp.
Ça marche très bien, pas de souci.

Je cherche à utiliser ftps à la place de ftp pour le même besoin et de
la même manière (dans un script et avec un un serveur ftp avec TLS). Une
idée de l'outil qui permettrait de faire ça, svp ?

-- 
Cordialement,
Artur.

Re: chroot ssh sftp

[Marc Chantreux]

hello,

> Si je pousse le concept bien plus loin que mon besoin, quid des
> ressources nécessaires pour avoir 2000, 5000, 1 comptes sftp/ssh? 

ah mais j'etais pas en train de dire que je validais... je disais
justement "pas docker" mais debbootstrap te permettrait probablement
d'avoir un truc rapidement ... autres pistes:

* autre outils ? guix ? singularity ?
* utiliser des binaires compilés statiquement pour créer un env a la
   main


bonne chance
marc 

Re: chroot ssh sftp

[Wallace]

Le 06/09/2017 à 10:35, Marc Chantreux a écrit :
> On Wed, Sep 06, 2017 at 10:19:28AM +0200, Wallace wrote:
>> Je vois bien ce mécanisme mais il ne permet pas de chroot en ssh ou
>> alors c'est pas clair dans la documentation.
> OK du coup je comprend mieux l'idée de François:
>
> docker utilise les containers pour embarquer toutes la distribution dans
> le package d'une application. tu peux monter des volumes (ceux que tu
> voudrais partager) dans ton docker. l'idée donc s'est que quand tu te
> connecte en ssh, ca te force a te connecter a un container qui contient
> un systeme complet et les repertoires que tu voulais rendre visible).
>
> mais du coup t'as pas les paramètrages de la machine sur laquelle tu te
> connectais et le container est complet (autre ip et tout ...)
>
> bref ... est une idée mais perso j'aurais plutot tendance a regarder du
> coté de debootstrap.
>
> https://wiki.debian.org/Debootstrap
Je vois mieux l'idée mais clairement elle n'est pas viable niveau sécurité.

L'os minimal qu'il soit docker ou debootstrap n'est pas maintenu
quotidiennement = failles systèmes qui s'accumule, l'os n'est pas
iso27001, pci-dss, hds compliant de base et le faire en une image ou une
suite d'action après debootstrap alourdirait considérablement la tâche
et le poids quand il s'agit de faire que de simples comptes sftp / ssh
sur un seul os.

Si je pousse le concept bien plus loin que mon besoin, quid des
ressources nécessaires pour avoir 2000, 5000, 1 comptes sftp/ssh?

Sur un seul serveur avec 4Go de ram et 2 cpu ça devrait tenir facilement
plusieurs milliers de comptes, Docker va consommer disons 256/512Mo x le
nombre de compte et Debootstrap comme Docker lorsqu'il faut passer une
mise à jour quotidienne sur l'OS ça fait plusieurs milliers d'images à
mettre à jour / redémarrer ou plusieurs milliers de debootstrap à lancer.
Si le principe est intéressant, l'usage l'est clairement beaucoup moins.




signature.asc
Description: OpenPGP digital signature

Cryptsetup - impossible d'accéder à une machine Jessie chiffrée

[roger . tarani]

Bonjour,
Le chiffrement du volume a été configuré avec l'installateur de Debian Jessie 
vers octobre 2016 (LVM+Cryptsetup). 
Aucun problème jusqu'à avril-mai 2017. Puis impossible de relancer la machine 
vers juin. 

Nous sommes certain de la passphrase. 

Certaines personnes auraient rencontré un tel problème après une mise à jour. 

Que faut-il vérifier ?

Comment rendre visible la saisie de la passphrase (pour verifier un éventuel 
problème azerty/qwerty) ?
L'équipe cryptsetup nous invite à vous contacter compte tenu du code Debian 
présent autour du code Cryptsetup. 

Quel est le mode opératoire complet à respecter pour ne jamais être bloqué avec 
le chiffrement du disque ? (Sauvegarde de certains fichiers, etc. )

Merci

Re: utilisation open.vpn chez OVH

[daniel huhardeaux]

J'ai dis *PAS* de message privé, répond à la liste STP

Le 06/09/2017 à 10:03, herve.thib...@free.fr a écrit :

Le 05/09/2017 à 20:06, daniel huhardeaux a écrit :

Ton fichier openvpn.conf doit être vérolé: es tu certain que les fins 
de ligne ne sont pas celles de WIndows?


Si le fichier openvpn.conf fonctionne avec Ubuntu il doit fonctionner 
avec Debian. C'est le cas chez moi: serveur openvpn Debian Jessie, 
client Ubuntu 16.04, Debian stretch et Debian wheezy, aucun soucis. 
Mets verbose 5 dans le fichier de conf. Peux tu envoyer la conf 
uniquement partie remote, port et proto



Ci-dessous mon fichier client.ovpn sans le détall des clés
Tout semble être correctement exécuté jusqu'à "comp-lzo no"
Les certificats ne sont pas récupérés...


Pour debian il s'appelle bien client.conf ? Si non, il n'est pas pris en 
compte au démarrage (voir /etc/default/openvpn)



[...]
remote 37.59.122.236 1194 udp
remote 37.59.122.236 1194 udp
remote 37.59.122.236 443 tcp
remote 37.59.122.236 1194 udp
remote 37.59.122.236 1194 udp
remote 37.59.122.236 1194 udp
remote 37.59.122.236 1194 udp
remote 37.59.122.236 1194 udp


Il ne devrait y avoir qu'une seule ligne

remote 37.59.122.236 1194 udp

sauf si (extrait du man de Jessie)

--remote host [port] [proto]
  Remote  host  name  or IP address.  On the client, 
multiple --remote options may be specified for redundancy, each 
referring to a different OpenVPN server.
  Specifying multiple --remote options for this purpose is 
a special case of the more general connection-profile feature. See the 
 documentation

  below.


verb 5
tu executes bien la commande sudo openvpn --config client.conf dans un 
terminal afin d'avoir les logs à l'écran ?


[...]

--
Daniel

Re: chroot ssh sftp

[Marc Chantreux]

On Wed, Sep 06, 2017 at 09:40:14AM +0200, Francois Mescam wrote:
> docker ?

je suis curieux: en quoi docker peut aider ?

marc

Re: chroot ssh sftp

[Marc Chantreux]

On Wed, Sep 06, 2017 at 09:19:07AM +0200, Wallace wrote:
> Bonjour à tous,
> 
> J'utilise MySecureShell couplé à lshell pour chroot des comptes sftp/ssh
> et limiter les commandes qu'ils peuvent y faire.

https://serverfault.com/questions/354615/allow-sftp-but-disallow-ssh

tout est inclus dans openssh maintant ... enfin si j'ai tout compris ta
demande.

marc

Re: chroot ssh sftp

[Wallace]

Le 06/09/2017 à 09:40, Francois Mescam a écrit :
> docker ?
Docker isole des applications entre elles, Docker n'isole pas un compte
utilisateur de son micro OS.
Et puis Docker en prod, quand je vois le massacre chez certains
clairement loin de moi cette idée, OS des images pas à jour / plus
maintenu, aucun hardening du micro OS, aucune configuration
d'optimisation de perf.
Pour moi c'est utile que pour du prototypage et développement,
clairement pas pour de la prod.



signature.asc
Description: OpenPGP digital signature

Re: chroot ssh sftp

[Francois Mescam]

docker ?

On 06/09/2017 09:19, Wallace wrote:

Bonjour à tous,

J'utilise MySecureShell couplé à lshell pour chroot des comptes sftp/ssh
et limiter les commandes qu'ils peuvent y faire.

En voulant installer lshell sur une nouvelle Debian 8 je me rend compte
que le package n'existe plus. Et je vois sur la page du package que ce
dernier a été enlevé car une faille de sécu assez sympa traîne depuis
l'été 2016. En allant voir le github du logiciel en effet les issues
s'accumulent, des contributeurs proposent des solutions mais le
mainteneur n'agit plus depuis 1 an.

Je suis vraiment content de ce que fait Debian à ce niveau, j'ai beau
être abonné rss à différents flux qu'ils proposent pour suivre les mises
à jour mais je n'ai pas vu le retrait, va falloir que j'améliore ma veille.

Tout cela pour finalement me dire qu'il serait peut être temps de revoir
ce couple mysecureshell et lshell. Il y a bien une fonctionnalité de
chroot dans la partie sftp de ssh mais pour faire un vrai chroot dans
ssh il faut refaire pour chaque compte des répertoires /bin /lib ... et
mettre des liens hard vers les binaires utiles (cp, mv, ls, ...) Cette
méthode est clairement la meilleure et la plus logique mais je la trouve
lourde à gérer et je vois déjà des utilisateurs essayer de virer les
répertoires parce qu'ils en ont pas besoin ou se plaindre que ça n'aide
pas à la lecture des dossiers ou fichiers qu'ils vont y déposer.

Avez-vous des idées d'alternatives entre mon système actuel et le vrai
chroot?

Merci




--
 Francois Mescam

chroot ssh sftp

[Wallace]

Bonjour à tous,

J'utilise MySecureShell couplé à lshell pour chroot des comptes sftp/ssh
et limiter les commandes qu'ils peuvent y faire.

En voulant installer lshell sur une nouvelle Debian 8 je me rend compte
que le package n'existe plus. Et je vois sur la page du package que ce
dernier a été enlevé car une faille de sécu assez sympa traîne depuis
l'été 2016. En allant voir le github du logiciel en effet les issues
s'accumulent, des contributeurs proposent des solutions mais le
mainteneur n'agit plus depuis 1 an.

Je suis vraiment content de ce que fait Debian à ce niveau, j'ai beau
être abonné rss à différents flux qu'ils proposent pour suivre les mises
à jour mais je n'ai pas vu le retrait, va falloir que j'améliore ma veille.

Tout cela pour finalement me dire qu'il serait peut être temps de revoir
ce couple mysecureshell et lshell. Il y a bien une fonctionnalité de
chroot dans la partie sftp de ssh mais pour faire un vrai chroot dans
ssh il faut refaire pour chaque compte des répertoires /bin /lib ... et
mettre des liens hard vers les binaires utiles (cp, mv, ls, ...) Cette
méthode est clairement la meilleure et la plus logique mais je la trouve
lourde à gérer et je vois déjà des utilisateurs essayer de virer les
répertoires parce qu'ils en ont pas besoin ou se plaindre que ça n'aide
pas à la lecture des dossiers ou fichiers qu'ils vont y déposer.

Avez-vous des idées d'alternatives entre mon système actuel et le vrai
chroot?

Merci




signature.asc
Description: OpenPGP digital signature

Re: debian 9 et java jdk 1.8 ? - version officiel sous debian

[C. Mourad Jaber]

Bonjour,

le package java-package est fait pour toi...

pour installer la version officiel de oracle :

- installer java-package

- telecharger le tar.gz officiel

- utiliser la commande make-jpkg nom_du_fichier_jdk.tar.gz

- installer le .deb genéré...

Les détails sont ici : https://wiki.debian.org/JavaPackage

Mes 2cents

Mourad


Le 05/09/2017 à 18:50, G2PC a écrit :

Navré pour cette question, ceux qui savent vont rire, mais, comment
avoir debian 9 et java jdk 1.8 ?

Pour lancer mcmyadmin2, il me faut jdk 1.8