> Le 21 juil. 2023 à 10:26, Michel Verdier a écrit :
>
> Le 19 juillet 2023 RogerT a écrit :
>
>> La validation par le gouvernement n’est en rien une garantie (sgdg…).
>
> Bien sûr, mais c'est quand même un plus par rapport à rien du tout.
Ça ne vaut rien du tout. Rien.
>
>> Pour
Le 19 juillet 2023 RogerT a écrit :
> La validation par le gouvernement n’est en rien une garantie (sgdg…).
Bien sûr, mais c'est quand même un plus par rapport à rien du tout.
> Pour Keepass, tu stockes ta BD où tu veux. Le problème était la possibilité
> d’exporter en clair les pwds :
>
On 2023-07-19 09:05:05 +0200, Michel Verdier wrote:
> Le 18 juillet 2023 roger tarani a écrit :
> > Quel est le mécanisme détaillé conduisant à l'authentification de
> > l'utilisateur par l'hôte distant ?
> > (la clef privée reste sur l'hôte local ; comment la clef publique et la
> > clef
De: "elguero eric"
> À: debian-user-french@lists.debian.org
> Envoyé: Mercredi 19 Juillet 2023 18:28:24
> Objet: Re: Authentification ssh et PAM
> pour moi crypter et décrypter ne sont que des mots
> et en réalité il s'agit de deux bijections inverses
> l'une de l'autr
Le 20/07/2023 à 10:48, RogerT a écrit :
[...]
En pratique, si j’utilise une clef USB sans chiffrement ou avec chiffrement ou
carrément un HSM, PAM est-il transparent à utiliser (cad qu’il suffit de
configurer account, auth, password, session) ou faut-il trouver/développer un
composant
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
>> travaillais c'est de l'authentification qui crypte avec la clef privée,
>> d'où mon inversion pour ssh.
>
> Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on se
> le dise ;-)
Le 19/07/23 à 16:28, elguero eric a écrit :
> pour moi crypter et décrypter ne sont que des mots
Mais les mots ont un sens ;-)
Et ici ce n'est pas le bon. En français, décrypter c'est déchiffrer un message
dont on a pas la
clé de chiffrement (et crypter n'existe pas car ça n'a pas de sens, ça
pour ssh.
Ah, c'est pas à moi que ça arriverait, ça: je ne me trompe jamais, qu'on
se le dise ;-)
D'ailleurs c'est à se demander quel phénomène occulte et maléfique est
intervenu pour corrompre et distordre mon message précédent, puisque à
le lire soigneusement ainsi que le lien qu'il cite
dia.org/wiki/Cryptographie_asym%C3%A9trique#M%C3%A9canismes_d'authentification
En français c'est mieux :)
On retrouve Alice et Bob. Et effectivement le dernier truc sur lequel je
travaillais c'est de l'authentification qui crypte avec la clef privée,
d'où mon inversion pour ssh.
andis que la clef publique permet à tout le monde de chiffrer un message.
Oui tu as raison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process
> Le 19 juil. 2023 à 17:58, Michel Verdier a écrit :
>
> Le 19 juillet 2023 RogerT a écrit :
>
Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>>>
>>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
>> Keepass[xc], etc.ne sont pas sûrs
ison, autant pour moi, ça fait du bien de relire les bases de
temps en temps. Voilà une description assez claire :
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process
Le 19 juillet 2023 RogerT a écrit :
>>> Ou alors il faut un gestionnaire de pwd pour stocker la phrase de passe…
>>
>> Tout à fait, c'est à ça que sert kwallet ou gnome-agent ou keepassxc
> Keepass[xc], etc.ne sont pas sûrs comme la plupart des gestionnaires de pwd
> qui ont tous déjà été
Pour autant que ça s'applique ici, Wikipedia a une explication d'un
mécanisme d'autentification à clés asymétriques par l'utilisation d'un
double chiffrement avec les deux clés publiques (celles de chaque partie):
COMPLÉMENT
J’ai approfondi ma vérification.
J’étais parti sur le seul schéma habituel : chiffrer avec la clef publique et
déchiffrer avec la clef privée.
Je crois que tu voulais parler de signature numérique, où Alice (ici le client
ssh) chiffre avec sa clef privée probablement un message
t a les deux clefs.
>> Seul le client peut déchiffrer une phrase chiffrée.
>
> Non, seul le client peut chiffrer
Tous ceux qui ont la clef publique peuvent chiffrer.
Et aussi celui qui a seulement la clef privée car elle permet de générer une
clef publique (je suppose qu’on peut chif
e serveur a seulement la clef publique.
Oui, tous les serveurs qui doivent te déchiffrer (= tous ceux sur
lesquels tu dois te connecter) ont la publique
> Le client a les deux clefs.
> Seul le client peut déchiffrer une phrase chiffrée.
Non, seul le client peut chiffrer
> Comment fait l
Le 19/07/2023 à 11:26, RogerT a écrit :
Merci beaucoup pour tes pointeurs. Je vais étudier ça.
Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection
beaucoup plus courte que la clef elle-même 2048 bits.
En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec
Merci beaucoup pour tes pointeurs. Je vais étudier ça.
Le HSM gérera la clef ; ou plutôt il gérera la passphrase de protection
beaucoup plus courte que la clef elle-même 2048 bits.
En pratique, sais-tu si pour utiliser un HSM on DOIT s’interfacer avec le
système via PAM ? (Je me dis que oui,
e comprends pas.
Pour chiffrer une phrase il suffit de la clef publique.
Pour déchiffrer une phrase il faut la clef privée.
Le serveur a seulement la clef publique.
Le client a les deux clefs.
Seul le client peut déchiffrer une phrase chiffrée.
Comment fait le serveur ssh pour savoir que c
je n'y connais rien mais tu peux éventuellement consulter ce qui suit:
- sur le fonctionnement général de PAM: la vieille doc de kernel.org
(The Linux-PAM System Administrators' Guide) n'est plus semble-t-il
disponible sur le site d'origine mais on la dtouve encore ailleurs:
mment dois-je procéder pour qu'elle soit utilisée par le système
sur le client il faut utiliser le paramètre -i pour utiliser le clef adhoc
ou l'indiquer dans ~/.ssh/config du client. Donc il faut monter ta clef
pour qu'elle soit accessible par le client.
> En cherchant, j'ai lu des cho
savoir si on doit utiliser PAM, et comment.
> Le 19 juil. 2023 à 00:00, ajh-valmer a écrit :
>
> Il suffit de taper 3 mots dans un moteur de recherche :
> www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
> :-)
>
>>
Il suffit de taper 3 mots dans un moteur de recherche :
www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server-fr
:-)
On Tuesday 18 July 2023 18:16:21 roger.tar...@free.fr wrote:
> Un utilisateur dispose d'une clef ssh privée et d'une c
Bonjour,
Un utilisateur dispose d'une clef ssh privée et d'une clef publique rangés dans
~/.ssh/ , avec des droits 600.
S'il a copié la clef publique sur un serveur distant, l'agent local saura "lier
la clef publique et la privée" pour lui donner accès à l'hôte distant sans
besoin
Basile Starynkevitch a écrit :
> C'était ma faute, j'avais git clone-é en
> https://github.com/RefPerSys/RefPerSys au lieu de
> ssh://github.com/RefPerSys/RefPerSys
Voilà, tout s'explique. ;)
Sébastien
--
Sébastien Dinot, sebastien.di...@free.fr
http://www.palabritudes.net/
Ne gout
On 5/7/23 21:13, Sébastien Dinot wrote:
Bonsoir Basile,
Basile Starynkevitch a écrit :
Bien sûr, j'ai des clef SSH
Mais github demande maintenant un mot de passe à chaque git push.
Pourrais-tu nous expliquer exactement ce qui se passe, en nous
fournissant des copies des messages affichés
Hugues Larrive a écrit :
> J'ai déjà essayé ça et je peux vous dire qu'il faut un Serveur avec un
> grand 'S'. Ce truc est littéralement obèse, ils disent 4Go de RAM pour
> 500 utilisateurs mais en fait il "mange" déjà les 4Go avant même la
> création du premier utilisateur.
Je le confirme, le «
Bonsoir Basile,
Basile Starynkevitch a écrit :
> Bien sûr, j'ai des clef SSH
>
> Mais github demande maintenant un mot de passe à chaque git push.
Pourrais-tu nous expliquer exactement ce qui se passe, en nous
fournissant des copies des messages affichés par Git ? Je viens de fair
Bonjour,
--- Original Message ---
Le dimanche 7 mai 2023 à 14:00, benoit a écrit :
> Le top serait d'installer sa propre instance de Gitlab sur un serveur
>
J'ai déjà essayé ça et je peux vous dire qu'il faut un Serveur avec un grand
'S'. Ce truc est littéralement obèse, ils disent
Le samedi 6 mai 2023 à 13:26, NoSpam a écrit :
>
>
> Framagit
>
+1
Framagit est une instance de Gitlab.
Mais Framasoft essaye de rendre les gens indépendants.
Le top serait d'installer sa propre instance de Gitlab sur un serveur
https://framacloud.org/fr/cultiver-son-jardin/gitlab.html
Le 6 mai 2023 Jean-Marc a écrit :
> À Bruxelles, il y a https://www.domainepublic.net.
>
> Tu peux ouvrir un compte avec plein de services pour 30€ par an.
Et en France il y a le collectif https://www.chatons.org (issu de
Framasoft) qui héberge plusieurs fournisseurs pour ce service :
/RefPerSys
Bien sûr, j'ai des clef SSH
Mais github demande maintenant un mot de passe à chaque git push.
Connaissez vous une alternative en Europe? (je suis prêt à payer une
douzaine d'€ par mois, si nécessaire).
Il y a pas mal de fournisseurs de services locaux un peu partout.
À Bruxelles, il y
epo ?
Est-ce le mot de passe de ta clef SSH ou bien celui de ton compte github
?
Mes 2¢
Bien sûr, j'ai des clef SSH
Mais github demande maintenant un mot de passe à chaque git push.
Connaissez vous une alternative en Europe? (je suis prêt à payer une
douzaine d'€ par mois, si nécessaire).
Framagit
--
Daniel
dans ton profil ?
Oui.
https://github.com/bstarynk/
Comment créer la clef wsh?
(j'en ai en ssh)
Le sam. 6 mai 2023 à 10:18, Basile Starynkevitch
a écrit :
Bonjour la liste
Sur mon temps libre je développe avec d'autres le moteur d'inférences
RefPerSys (en logiciel
sûr, j'ai des clef SSH
Mais github demande maintenant un mot de passe à chaque git push.
Connaissez vous une alternative en Europe? (je suis prêt à payer une
douzaine d'€ par mois, si nécessaire).
Avec les fichiers executables, RefPerSys consomme actuellement environ
250Mo d'espace disque
Bonjour la liste
Sur mon temps libre je développe avec d'autres le moteur d'inférences
RefPerSys (en logiciel libre GPLv3+, pour Debian ou autre Linux): voir
http://refpersys.org/ et code en https://github.com/RefPerSys/RefPerSys
Bien sûr, j'ai des clef SSH
Mais github demande maintenant
Ben oui, il y a plein de doc en plus :
https://duckduckgo.com/?q=SSH+key++authentication+with+LDAP=ffab=web
Avec gratitude,
--
Benoit
Envoyé avec la messagerie sécurisée ProtonMail.
--- Original Message ---
Le lundi 11 avril 2022 à 16:57, Roberto C. Sánchez a écrit
:
> On
On Mon, Apr 11, 2022 at 01:16:41PM +, benoit wrote:
>Bonjour à tous,
>Si sur le serveur SSH on a désactivé l’authentification par mot de passe,
>comment fait-on pour ajouter les clés de nouveaux utilisateurs ?
>Une fois qu'on à configuré ssh avec
>Passwor
Bonjour à tous,
Si sur le serveur SSH on a désactivé l’authentification par mot de passe,
comment fait-on pour ajouter les clés de nouveaux utilisateurs ?
Une fois qu'on à configuré ssh avec
PasswordAuthentication no
On ne sait plus ajouter de nouveaux utilisateur avec
ssh-keygen
ssh-copy-id
Bonjour
De mon expérience avec fail2banet ssh, dans une situation similaire (NAT
derrière une box) les IP des attaquants sont celles venant de l'extérieur.
Donc si dans les logs les ip appartiennent au réseau local, c'est que
l'attaquant s'y trouve, ou bien utilise une machine locale pour
Bonjour,
C'est possible que ça vienne de l'extérieur (a l'époque ca pouvait être une
attaque par IP spoofing/paquet martien). Mais ça ne ce fait plus trop de
nos jours , les routeurs/firewall savent gérer cela
Le mar. 22 févr. 2022 à 11:50, Sil a écrit :
> Le 22/02/2022 à 09:27, Sil a écrit :
On Tuesday 22 February 2022 09:27:46 Sil wrote:
> Bonjour la liste,
> Pourriez-vous m'enlever un doute... sur un réseau local derrière une
> box, j'ai des postes w$ DHCP et un serveur Debian stable à jour. Ce
> serveur est accessible via SSH sur le réseau local via le port classique
Le 22/02/2022 à 09:27, Sil a écrit :
/var/log/auth.log.2.gz:Feb 7 09:34:58 monserveur sshd[]:
Disconnected from invalid user Admin 192.168.X.X port [preauth]
Mais est-ce que l'IP du fichier log peut provenir de l’extérieur ? Ou
est-ce impossible ?
Est-il possible de différencier
Sil a écrit :
> Bonjour la liste,
>
> Pourriez-vous m'enlever un doute... sur un réseau local derrière une
> box, j'ai des postes w$ DHCP et un serveur Debian stable à jour. Ce
> serveur est accessible via SSH sur le réseau local via le port classique
> et depuis l’extérieur sur
Bonjour la liste,
Pourriez-vous m'enlever un doute... sur un réseau local derrière une
box, j'ai des postes w$ DHCP et un serveur Debian stable à jour. Ce
serveur est accessible via SSH sur le réseau local via le port classique
et depuis l’extérieur sur un autre port via le NAT de la box
G2PC a écrit :
> A tout hasard, tu as assez de ram ?
> Si le fichier est trop lourd, ça peut jouer ?
> Sinon, tu peux tenter de gérer les tailles des fichiers de logs pour
> n'avoir que 1 ou 5Mo max par fichier ?
> Le tail pourrait alors peut être ne plus tuer la connexion ?
Je pense que
A tout hasard, tu as assez de ram ?
Si le fichier est trop lourd, ça peut jouer ?
Sinon, tu peux tenter de gérer les tailles des fichiers de logs pour
n'avoir que 1 ou 5Mo max par fichier ?
Le tail pourrait alors peut être ne plus tuer la connexion ?
marc
> Non, non, ce n'est pas ça. Ce problème peut survenir mais pas dans mon
> cas où il est exclu par construction. Les paquets passent quels que
> soient leur taille.
y'a des dispositifs filtrant entre toi et le serveur? le problème n'est
pas dans les bouts?
marc
Charles Plessy a écrit :
> Bonsoir à tous,
>
> je me souviens d'avoir eu exactement le même problème.
>
> J'ai même peut-être eu la solution sur cette liste (ou le LUG de
> Strasbourg ?), mais je n'arrive pas à la retrouver.
>
> Je vais peut-être me tromper, mais il me semble que le problème
Bonsoir à tous,
je me souviens d'avoir eu exactement le même problème.
J'ai même peut-être eu la solution sur cette liste (ou le LUG de
Strasbourg ?), mais je n'arrive pas à la retrouver.
Je vais peut-être me tromper, mais il me semble que le problème était
lié à la MTU ou un système similaire:
Bonjour Sébastien,
> Quoi qu'il en soit, cette hypothèse me semble très probable, c'est pour
> cela que j'en ai fait part, mais ce n'est qu'une hypothèse.
c'est bien pour ca que ca m'intéresse: si tmux,screen ou mosh
contournent le problème, ca ne le corrige ni ne l'explique et j'étais
curieux.
st pas ce qu'il a dit :
1. « Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
plusieurs jours et *sans aucune action de ma part*, la connexino
ssh ne plante pas »
2. « dès que je fais dérouler un tail -F /var/log/apache2/access.log
(par exemple), la connexio
de sessions plutôt qu'à la connexion ssh liée au terminal
> courant. Du coup tu peux te déconnecter, te reconnecter depuis une autre
> machine, te connecter a plusieurs sur la même sessions ...
>
> ca te permet aussi d'ouvrir plusieurs fenetres ou de splitter les
> fenetres ex
> Cela ne stabilise rien du tout, bien au contraire, un trafic incessant
> révèle l'instabilité de la connexion, là où une connexion entretenue par
> un simple « ping applicatif » ponctuel ne révèle rien du tout.
Oui mais du coup ca n'explique pas le comportement curieux que décrit
Bertrand. je
salut Joel,
> Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
> plusieurs jours et sans aucune action de ma part
tmux est parfait pour ce genre d'usages: il te permet de lier tes applis
à un serveur de sessions plutôt qu'à la connexion ssh liée au terminal
courant. Du c
BERTRAND Joël a écrit :
> Sébastien Dinot a écrit :
>> Basile Starynkevitch a écrit :
>>> je crois qu'il faut le compiler depuis son code source
>>
>> Inutile, l'outil est disponible en version 1.3.2 (dernière version
>> publiée par le projet, en juillet 2017) dans les versions stable,
>> testing
on, là où une connexion entretenue par
un simple « ping applicatif » ponctuel ne révèle rien du tout. Et c'est
d'autant plus vrai avec SSH, qui est conçu pour supporter un certain
nombre de requêtes restent sans réponse (cf. ServerAliveCountMax dans la
page de manuel de ssh_config).
Sébastien
--
> Ne serait-ce tout simplement pas révélateur d'une connexion instable,
> intermittente? Tu ne t'en rends pas compte dans le terminal inactif,
> car la coupure passe justement inaperçue (les sockets restent valides).
> Mais lorsque le flux est continu, là, l'intermittence de la connexion se
>
Sébastien Dinot a écrit :
> Basile Starynkevitch a écrit :
>> je crois qu'il faut le compiler depuis son code source
>
> Inutile, l'outil est disponible en version 1.3.2 (dernière version
> publiée par le projet, en juillet 2017) dans les versions stable,
> testing et unstable de Debian :
>
>
Basile Starynkevitch a écrit :
> je crois qu'il faut le compiler depuis son code source
Inutile, l'outil est disponible en version 1.3.2 (dernière version
publiée par le projet, en juillet 2017) dans les versions stable,
testing et unstable de Debian :
https://tracker.debian.org/pkg/mosh
Basile Starynkevitch a écrit :
>
> On 4/16/21 10:01 PM, Sébastien Dinot wrote:
>> BERTRAND Joël a écrit :
>>> Rien à signaler dans tcpdump. C'est la première chose que j'ai
>>> regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
>>> un routeur quelque part qui coupe, mais je ne
On 4/16/21 10:01 PM, Sébastien Dinot wrote:
BERTRAND Joël a écrit :
Rien à signaler dans tcpdump. C'est la première chose que j'ai
regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
un routeur quelque part qui coupe, mais je ne vois pas comment il
ferait la différence
BERTRAND Joël a écrit :
> Rien à signaler dans tcpdump. C'est la première chose que j'ai
> regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
> un routeur quelque part qui coupe, mais je ne vois pas comment il
> ferait la différence entre un terminal inactif et un tail -F.
Ne
Thomas Trupel a écrit :
> Bonjour,
>
> Un tcpdump permettrait de savoir qui met fin à la session tcp.
Bonsoir,
Rien à signaler dans tcpdump. C'est la première chose que j'ai
regardé... Ça s'arrête sur un broken pipe. J'ai l'impression que c'est
un routeur quelque part qui coupe,
s d'un genre de
> kvm IP) et j'y accède en ssh. Ce n'est pas exactement une Debian mais
> une Devuan. Côté client, on est en devian, l'honneur est sauf !
>
> Parfait.
>
> Je peux laisser des terminaux ouverts, des éditeurs, le tout durant
> plusieurs jours et sans aucun
Bonjour à tous,
Chose louche que je ne m'explique pas. J'ai un serveur distant en
centre d'hébergement. J'ai accès à la console (au travers d'un genre de
kvm IP) et j'y accède en ssh. Ce n'est pas exactement une Debian mais
une Devuan. Côté client, on est en devian, l'honneur est
Bonjour Charles,
Charles Plessy, on 2020-11-14 18:23:21 +0900:
> Le Thu, Nov 12, 2020 at 09:51:06PM +0100, Étienne Mollier a écrit :
> > $ export GIT_SSH_COMMAND='ssh -vvv'
> > $ git clone g...@salsa.debian.org:med-team/perlprimer.git
>
> Merci du tuyau, ça bloq
Bonjour
Le 14/11/2020 à 10:23, Charles Plessy a écrit :
[...]
(Je n'ai pas encore testé le changement de MTU; je ne sais pas comment
le faire sure une interface wifi gérée par GNOME...)
en ligne de commande: sudo ip link set mtu 1492 dev
--
Daniel
Le Thu, Nov 12, 2020 at 09:51:06PM +0100, Étienne Mollier a écrit :
>
> Je n'ai pas rencontré de problèmes de mon côté. En grattant un
> peu, la variable d'environnement GIT_SSH_COMMAND peut être
> exploitée pour augmenter le verbiage de ssh:
>
> $ export GIT_SSH
On 12/11/2020 21:51, Étienne Mollier wrote:
De mon point de vue, Github n'est pas accessible en IPv6, ou du
moins, n'en fait pas la publicité :
$ host github.com
github.com has address 140.82.113.3
github.com mail is handled by 10 alt3.aspmx.l.google.com.
Bonjour
Le 12/11/2020 à 21:22, Charles Plessy a écrit :
Bonjour à tous,
j'ai à nouveau la fibre. Et en IPv6 en plus. Mais Git n'arrive plus à
contacter des sites distants en SSH.
Curieusement, les sessions SSH interactives ont l'air de s'établir
normalement. Example:
$ ssh -6 g
Bonjour Charles,
Charles Plessy, on 2020-11-13 05:22:08 +0900:
> j'ai à nouveau la fibre. Et en IPv6 en plus. Mais Git n'arrive plus à
> contacter des sites distants en SSH.
>
> Curieusement, les sessions SSH interactives ont l'air de s'établir
> normalement. Example:
>
Bonjour à tous,
j'ai à nouveau la fibre. Et en IPv6 en plus. Mais Git n'arrive plus à
contacter des sites distants en SSH.
Curieusement, les sessions SSH interactives ont l'air de s'établir
normalement. Example:
$ ssh -6 g...@salsa.debian.org
PTY allocation request failed on channel
> Bizarement l'option est dans la page de manuel d'apt-get mais pas celle
> d'apt...
dans man apt(8)
Exactement comme apt lui-même, cette page de manuel vise à être une
interface pour
l'utilisateur et ainsi elle ne mentionne que les commandes et les
options les plus
Le 19/09/2020 14:10:35, Eric Laly a écrit :
> Bonjour,
> ou un paramètre sur la ligne de commande apt...
> par exemple:
> 'apt install mercurial tortoisehg tortoisehg-nautilus -y'
> Bizarement l'option est dans la page de manuel d'apt-get mais pas
> celle d'apt...
Peut-être parce qu’apt n’est
Bonjour,
ou un paramètre sur la ligne de commande apt...
par exemple:
'apt install mercurial tortoisehg tortoisehg-nautilus -y'
Bizarement l'option est dans la page de manuel d'apt-get mais pas celle
d'apt...
Éric.
Le 18/09/2020 à 16:46, Dominique Dumont a écrit :
On Thursday, 17 September
On Thursday, 17 September 2020 15:53:49 CEST Pierre Malard wrote:
> Je n’ai pas encore trouver le moyen de forcer le YES.
Tu peux essayer la commande "yes".
par exemple: yes | apt install stuff
HTH
refesant tout le processus d'install. C'est plus
>> rapide et utilise
>> moins le reseau.
>>
>> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
>> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
>> copie, on se retrouve
Bonjour,
Il te suffit de régénérer ces clés du serveur avec un « ssh-keygen » une
fois la copie effectuée sur chaque type de clé. Par exemple en exécutant
ceci :
# for i in $(ls -1d /etc/ssh/ssh_host_*_key) ; do ssh-keygen -t "$(echo
${i/\/etc\/ssh\/ssh_host_} | cut -d_ -f1)" -N '' -f
lise
>> moins le reseau.
>>
>> Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
>> identifier l'ordi quand on s'y connecte en ssh. Si on installe par
>> copie, on se retrouve donc avec plusieurs ordis qui ont les memes clef
>> d'identification.
Le 17/09/2020 à 12:26, hamster a écrit :
> Salut.
>
> Comme d'autres, j'aime bien installer debian en copiant un système
> existant plutot qu'en refesant tout le processus d'install. C'est plus
> rapide et utilise
> moins le reseau.
>
> Je viens de percuter qu'il y a da
salut,
Je cherche donc a renouveller ces clef après copie,
> mais tant dans google que dans les man, je me perds.
je n'ai regardé ni le man, ni google pour te répondre mais
apt source openssh-server
vim openssh-8.3p1/debian/openssh-server.postinst
regarde la fonction create_keys et tu
Bonjour,
Tu peux la recréée facilement avec une ligne de commande: ssh-keygen -t rsa.
Le jeu. 17 sept. 2020 12:41, hamster a écrit :
> Le 17/09/2020 à 12:31, Bernard Schoenacker a écrit :
> >
> > - Mail original -
> >> De: "hamster"
> >
Le 17/09/2020 à 12:31, Bernard Schoenacker a écrit :
>
> - Mail original -
>> De: "hamster"
>> À: debian-user-french@lists.debian.org
>> Envoyé: Jeudi 17 Septembre 2020 12:26:23
>> Objet: install par copie et ssh
>>
>> Salut.
>>
- Mail original -
> De: "hamster"
> À: debian-user-french@lists.debian.org
> Envoyé: Jeudi 17 Septembre 2020 12:26:23
> Objet: install par copie et ssh
>
> Salut.
>
> Comme d'autres, j'aime bien installer debian en copiant un système
> existant pl
Salut.
Comme d'autres, j'aime bien installer debian en copiant un système
existant plutot qu'en refesant tout le processus d'install. C'est plus
rapide et utilise
moins le reseau.
Je viens de percuter qu'il y a dans /etc/ssh des clef qui servent a
identifier l'ordi quand on s'y connecte en ssh
Bonjour,
Le 2020-04-22 20:11, ajh-valmer a écrit :
Du client :
ssh -v -p root@ -X xeyes
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command: xeyes
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max
16384
debug1: client_request_x11: request
Le 22/04/2020 à 23:43:08 (+0200), ajh-valmer a écrit :
> On Wednesday 22 April 2020 21:49:25 NoSpam wrote:
> > Je trouve que votre agressivité est déplacée, des personnes tentent de
> > vous aider et vous focalisez sur vous même. Vous êtes coutumier du fait,
> > hélas, et les personnes de la
Hmm, peux être une piste.
Je vois que tu te connectes au serveur via SSH en Root.
Par défaut les connections en Root sont refusées par SSH.
Frédéric ZULIAN
Le mer. 22 avr. 2020 à 20:12, ajh-valmer a écrit :
> Comment dialoguer et me reprocher,
> si vous persistez à envoyer toujours vos
re comme celui ci, malgré cette demande
> > dans le précédent.
> >
> > Du client :
> > ssh -v -p root@ -X xeyes
> >
> > debug1: Requesting X11 forwarding with authentication spoofing.
> > debug1: Sending command: xeyes
> > debug1: client_input_channel_ope
persistez à envoyer toujours vos mails en TROIS exemplaires,
encore comme celui ci, malgré cette demande
dans le précédent.
Du client :
ssh -v -p root@ -X xeyes
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command: xeyes
debug1: client_input_channel_open: ctype
Comment dialoguer et me reprocher,
si vous persistez à envoyer toujours vos mails en TROIS exemplaires,
encore comme celui ci, malgré cette demande
dans le précédent.
Du client :
ssh -v -p root@ -X xeyes
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending command
On Wed, Apr 22, 2020 at 11:24:24AM +0200,
ajh-valmer wrote
a message of 67 lines which said:
> > Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
> > DISPLAY (ce qu'il ne faut pas faire, ssh le faisant très bien tout seul) :
>
> L'erreur affichée a touj
elles énormités... ? Pourquoi ?
>
> > Tu ne les indiques pas :
> Faux (cf. ma réponse à Pierre Malard) :
> > et ni même une piste de solution :
> Faux encore (la solution est de ne pas utiliser xhost du tout, ssh
> marche sans lui) :
> > C'est un problème de n° de d
Ne peut-on arrêter cette polémique ridicule ?
Ok, tu as raison, fermons le ban…
> Le 22 avr. 2020 à 10:39, Stephane Bortzmeyer a écrit :
>
> On Sun, Apr 19, 2020 at 10:10:53AM +0200,
> Pierre Malard wrote
> a message of 100 lines which said:
>
>> Sauf que, avant d’être méprisant et
aux (cf. ma réponse à Pierre Malard)
> et ni même une piste de solution.
Faux encore (la solution est de ne pas utiliser xhost du tout, ssh
marche sans lui)
> C'est un problème de n° de display.
Non. À moins qu'il n'y ait un script quelque part qui redéfinisse
DISPLAY (ce qu'il ne faut pas fair
On Sun, Apr 19, 2020 at 10:10:53AM +0200,
Pierre Malard wrote
a message of 100 lines which said:
> Sauf que, avant d’être méprisant et sentencieux on peut aussi être
> constructif et … pédagogue.
Quand quelqu'un donne des conseils absurdes et dangereux, il n'y a
aucune raison d'être patient.
Bonjour la liste,
Je cherche un système de fichier crypté sur une partition vierge d'un
disque local (d'un portable récent, voir ceci
<https://unix.stackexchange.com/q/564066/50557>) dont la clef serait
partagée avec SSH.
Autrement dit, après un ssh-add je souhaiterais avoir accè
1 - 100 sur 2792 matches
Mail list logo
