Contenu | Rechercher | Menus

Annonce

Si vous rencontrez des soucis à rester connecté sur le forum (ou si vous avez perdu votre mot de passe) déconnectez-vous et reconnectez-vous depuis cette page, en cochant la case "Me connecter automatiquement lors de mes prochaines visites".
nombre réponses : 25

#0 -1 »  Fatal Python error: pycurl: libcurl link-time version is older ... » Le 16/01/2015, à 22:56

JujuLand
Réponses : 2

Bonjour,

je ne saurais dire ce qui pourrais être à l'origine du problème, mais lorsque je veux ajouter une clé, j'ai l'erreur suivante:

alain@Gramps-JujuLand:~$ sudo add-apt-repository ppa:qmagneto/ppa
Fatal Python error: pycurl: libcurl link-time version is older than compile-time version

Lorsque je vérifie les version de ces deux paquets, je trouve ceci:

alain@Gramps-JujuLand:~$ sudo apt-get install python-pycurl libcurl3
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances        
Lecture des informations d'état... Fait
python-pycurl est déjà la plus récente version disponible.
libcurl3 est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 1 non mis à jour.

alain@Gramps-JujuLand:~$ paquet libcurl
ii  libcurl3                                          7.22.0-3ubuntu4.12                                  Multi-protocol file transfer library (OpenSSL)
ii  libcurl3:i386                                     7.22.0-3ubuntu4.12                                  Multi-protocol file transfer library (OpenSSL)
ii  libcurl3-gnutls                                   7.22.0-3ubuntu4.12                                  Multi-protocol file transfer library (GnuTLS)
ii  libcurl3-nss                                      7.22.0-3ubuntu4.12                                  Multi-protocol file transfer library (NSS)
ii  libcurl4-openssl-dev                              7.22.0-3ubuntu4.12                                  Development files and documentation for libcurl (OpenSSL)
ii  python-pycurl                                     7.19.0-4ubuntu3                                     Python bindings to libcurl

Je vois bien le problème, mais je ne sais pas comment le résoudre ...

De plus, je ne sais pas quel paquet aurait pu mettre le souk.
Il me semble me rappeler qu'ayant eu un problème avec cups et hplip, j'ai désinstallé, reinstallé, ... enfin plus de gestionnaire d'imprimante non plus, je ne sais pas surpris qu'il y ait un rapport.

Bref, si vous avez une idée.

Je suis sous Ubuntu 12.04

Merci

#1 Re : -1 »  Fatal Python error: pycurl: libcurl link-time version is older ... » Le 23/01/2015, à 09:09

JujuLand
Réponses : 2

Curieux, je n'aoi pas reçu de mail de suivi, raison de ma réponse tardive.

J'ai essayé, mais y'a un os:

alain@Gramps-JujuLand:~$ sudo apt-get install -f python-software-properties
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
python-software-properties est déjà la plus récente version disponible.
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.

alain@Gramps-JujuLand:~$ sudo apt-get remove python-software-properties
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances       
Lecture des informations d'état... Fait
Les paquets suivants seront ENLEVÉS :
  aptdaemon apturl landscape-client-ui-install language-selector-gnome
  nautilus-share python-aptdaemon python-aptdaemon.gtk3widgets
  python-aptdaemon.pkcompat python-software-properties sessioninstaller
  software-center software-properties-gtk ubuntu-desktop ubuntu-tweak
  xul-ext-ubufox
0 mis à jour, 0 nouvellement installés, 15 à enlever et 0 non mis à jour.
Après cette opération, 11,0 Mo d'espace disque seront libérés.

Je n'ai pas envie de tout casser ...

Autre idée ?

A+

#2 Re : -1 »  [Résolu] Connexion ssh : needpriv 0 » Le 20/12/2014, à 14:47

JujuLand
Réponses : 35

Bon, j'ai changé la livebox pro v3 pour une pro v2, mais pas de bol, la pro v2 n'est pas compatible vdsl (ou xdsl)
Retour avec une nouvelle pro v3.
J'ai eu la confirmation qu'avec un pro v3, il y avait des problèmes avec le NAT/PAT, mais qu'il y avait une astuce pour solutionner çà:
Au cas ou la livebox aurait déjà été paramétrée, et que çà ne fonctionne pas, il faut :
- faire un reset de la box
- enlever la carte sim
-faire tout le paramétrage connexion internet, parefeu, NAT/PAT sans la carte.
-remettre la carte

J'avais toujours des timeout, alors que canyouseeme me disais ok
Il m'a fallu ouvrir les ports dans le firewall coté client.

Cà semble fonctionner mieux, et j'ai été capable d'atteindre une des machines. La deuxième avait du être éteinte. Mais j'ai encore quelque problèmes, qui doivent se situer du coté du serveur:

alain@Gramps-JujuLand:~$ ssh -vvv -p 22111 jacques@xx.xx.xxx.xxx
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xxx.xxx [xx.xx.xxx.xxx] port 22111.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/alain/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/alain/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alain/.ssh/id_rsa-cert type -1
debug1: identity file /home/alain/.ssh/id_dsa type -1
debug1: identity file /home/alain/.ssh/id_dsa-cert type -1
debug1: identity file /home/alain/.ssh/id_ecdsa type -1
debug1: identity file /home/alain/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [xx.xx.xxx.xxx]:22111
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug3: put_host_port: [xx.xx.xxx.xxx]:22111
debug3: put_host_port: [xx.xx.xxx.xxx]:22111
debug1: checking without port identifier
The authenticity of host '[xx.xx.xxx.xxx]:22111 ([xx.xx.xxx.xxx]:22111)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'xx.xx.xxx.xxx]:22462' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/alain/.ssh/id_rsa (0x7ff09d3230e0)
debug2: key: /home/alain/.ssh/id_dsa ((nil))
debug2: key: /home/alain/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/alain/.ssh/id_dsa
debug3: no such identity: /home/alain/.ssh/id_dsa
debug1: Trying private key: /home/alain/.ssh/id_ecdsa
debug3: no such identity: /home/alain/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Je ne m'explique pas que çà ne passe pas cette fois ...

Je reverrai la config coté serveur, des fois que j'ai raté un truc ???

Merci
A+

#3 Re : -1 »  [Résolu] Connexion ssh : needpriv 0 » Le 27/12/2014, à 14:15

JujuLand
Réponses : 35

Bon, j'ai revu coté serveur, et je ne remarque rien d'incorrect.
J'ai autorisé aussi l'identification par mot de passe, Mais rien ne passe ...

Sur le premier serveur, j'ai un timeout, bien que le serveur soit bien lancé
Sur le deuxième serveur, j'ai les messages suivants (légèrement différents du post précédent, vu la possibilité des mots de passe, mais çà bloque toujours:

alain@Gramps-JujuLand:~$ ssh -vvv -p 22111 jacques@xx.xx.xxx.xxx
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xx.xxx.xxx [xx.xx.xxx.xxx] port 22111.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/alain/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/alain/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/alain/.ssh/id_rsa-cert type -1
debug1: identity file /home/alain/.ssh/id_dsa type -1
debug1: identity file /home/alain/.ssh/id_dsa-cert type -1
debug1: identity file /home/alain/.ssh/id_ecdsa type -1
debug1: identity file /home/alain/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.4
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [xx.xx.xxx.xxx]:22111
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug3: put_host_port: [xx.xx.xxx.xxx]:22111
debug3: put_host_port: [xx.xx.xxx.xxx]:22111
debug1: checking without port identifier
The authenticity of host '[xx.xx.xxx.xxx]:22111 ([xx.xx.xxx.xxx]:22111)' can't be established.
ECDSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '[xx.xx.xxx.xxx]:22111' (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/alain/.ssh/id_rsa (0x7f7bc8f32080)
debug2: key: /home/alain/.ssh/id_dsa ((nil))
debug2: key: /home/alain/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/alain/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/alain/.ssh/id_dsa
debug3: no such identity: /home/alain/.ssh/id_dsa
debug1: Trying private key: /home/alain/.ssh/id_ecdsa
debug3: no such identity: /home/alain/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
jacques@xx.xx.xxx.xxx's password: 
debug3: packet_send2: adding 32 (len 77 padlen 19 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
jacques@xx.xx.xxx.xxx's password: 
debug3: packet_send2: adding 64 (len 59 padlen 5 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
jacques@xx.xx.xxx.xxx's password: 
debug3: packet_send2: adding 64 (len 52 padlen 12 extra_pad 64)
debug2: we sent a password packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password).

Ce que je remarque, c'est que le client envoie bien la clé, puis le mot de passe, mais semble ne pas avoir de réponse à ces envois.

debug2: we sent a publickey packet, wait for reply
debug2: we sent a password packet, wait for reply

Quand on débloque le parefeu de la box sur un port bien spécifique, c'est dans un sens ou dans les deux ?

Je commence à désespérer d'arriver à me connecter ...

Merci de vos lumières
A+

#4 Re : -1 »  [Résolu] Connexion ssh : needpriv 0 » Le 01/01/2015, à 12:13

JujuLand
Réponses : 35

Je me réponds, vu que j'ai avancé un peu:

Quand on débloque le parefeu de la box sur un port bien spécifique, c'est dans un sens ou dans les deux ?

Normalement, si la box fait du PAT, il suffit d'indiquer le port coté serveur, et 'Tous' (ou 'any') pour le port coté client
Malheureusement, la Livebox Pro V3 est une vrai m... et ne permet pas (malgré ce qui est dit dans les menus et exemples) de faire du PAT, et il faut donc configurer le NAT/PAT ainsi:

NAT/PAT
Service              SSH_111
Protocole            TCP
Port interne         22111
Port externe         22111
IP serveur           192.168.1.111

Bon, le problème semble réglé coté PAT, et la connexion fonctionne enfin.Par contre, çà ne semble pas encore fonctionner coté NAT, car si j'arrive à atteindre un premier serveur, j'ai un timeout sur le deuxième. Mais il faut que je revérifie que le DMZ ne soit pas activé, car lors de mes essais, à un moment, je l'avais active, mais pourtant canyouseeme me donnerait une erreur sur le test avec le port utilisé par le second serveur ...

A suivre ...
A+ et Bonne Année 2015

#5 Re : -1 »  [Résolu] Connexion ssh : needpriv 0 » Le 06/01/2015, à 22:47

JujuLand
Réponses : 35

Je récapitule la config distante où se trouve les deux serveurs ssh derrière une Livebox Pro v3

gadel-pc2 : compte jacques (rsa)
gadel-pc1 : comptes anne-sophie (passwd) et gadel (rsa)

Voici les diverses tentatives de connexions:

Depuis mon domicile:

gadel-pc2:

alain@Gramps-JujuLand:~$ ssh -p 22222 jacques@xx.xx.xxx.xxx
Last login: Tue Jan  6 22:03:35 2015 from atoulouse-xxx-x-xxx-xx.wxx-xx.abo.wanadoo.fr
 
jacques@gadel-pc2:~$
jacques@gadel-pc2:~$ ls /home
jacques  kmaster  lost+found
jacques@gadel-pc2:~$ hostname
gadel-pc2

gadel-pc1:

alain@Gramps-JujuLand:~$ ssh -p 22111 gadel@xx.xx.xxx.xxx
ssh: connect to host xx.xx.xxx.xxx port 22111: Connection timed out

alain@Gramps-JujuLand:~$ ssh -p 22111 anne-sophie@xx.xx.xxx.xxx
ssh: connect to host xx.xx.xxx.xxx port 22111: Connection timed out

Depuis mon domicile mais

gadel-pc1 (depuis la connexion à gadel-pc2) passwd

jacques@gadel-pc2:~$ ssh -p 22111 anne-sophie@192.168.1.12
anne-sophie@192.168.1.12's password:
Last login: Tue Jan  6 21:53:12 2015 from gadel-pc2

anne-sophie@gadel-pc1:~$ hostname
gadel-pc1
anne-sophie@gadel-pc1:~$ ls /home
anne-sophie gadel
anne-sophie@gadel-pc1:~$ exit
déconnexion
Connection to 192.168.1.12 closed.

C'est correct ...

gadel-pc1 (depuis la connexion à gadel-pc2) RSA

jacques@gadel-pc2:~$ ssh -p 22111 gadel@192.168.1.12
Enter passphrase for key '/home/jacques/.ssh/id_rsa':
Last login: Tue Jan  6 21:59:09 2015 from gadel-pc2

gadel@gadel-pc1:~$
gadel@gadel-pc1:~$ hostname
gadel-pc1

La connexion passe, mais il me demande la clé située coté client (/home/jacques/.ssh). Est-ce normal ?
Il est vrai que la connexion est effectuée depuis une connexion sous pts/02 (par exemple) et non sous :0, et donc il travaille en mode texte, contrairement à une connexion depuis :0 comme depuis chez moi.
Je ne suis pas loin de penser que c'est normal.

Par contre, le fait de ne pouvoir se connecter à aucun des comptes de gadel-pc1 depuis chez moi, çà semble accuser la livebox, qui ne semble pas savoir faire du NAT sur plusieurs adresses.

Dans la config du parefeu et du NAT-PAT, les règles concernant gadel-pc1 ont été déclarées avant celle de gadel-pc2. Il semblerait que la deuxième règle écrase la première ... je vais tenter de changer, en deux fois, l'ordre d'apparition des règles voir si le défaut ne change pas de machine ... pour confirmer que c'est la box.

Après avoir relevé que cette saloperie ne savait pas faire du PAT, voilà maintenant qu'elle semble ne pas savoir faire du NAT sur plusieurs machines ... ggrrr ...

Une idée qui pourrait me débloquer ?

Merci
A+

#6 Re : -1 »  [Résolu] Connexion ssh : needpriv 0 » Le 10/01/2015, à 21:12

JujuLand
Réponses : 35

Bon, il semble normal que le client, après quelques échanges avec le serveur demande la clé qui est située sur le client. La saisie sera probablement ensuite comparée à la clée située dans authorized_keys sur le serveur.

Bon, même si le problème de NAT sur la livebox pro v3 m'empêche la connexion en direct sur le deuxième ordi, je passe au travers de la connexion sur lr premier.

Je le passe donc en résolu.

A+

#7 -1 »  [Résolu] Lancement de programmes avec ssh -X » Le 01/01/2015, à 12:03

JujuLand
Réponses : 1

bonjour et bonne année,

J'utilise en local, lorsque je construit des ordis, ssh -X qui permet de lancer des programmes graphiques. Cà fonctionne très bien, par contre, lorsque je passe les box, j'ai un problème, mais il n'est peut-être pas lié aux box. Je m'explique ...

Le client est sous Ubuntu 12.04, le serveur sous Ubuntu 14.04.
Quand je lance un programme comme gnome-terminal, Libreoffice, ... j'ai un tas d'erreur concernant GConf et D-BUS:

(soffice:26898): GConf-WARNING **: Client failed to connect to the D-BUS daemon:
Failed to connect to socket /tmp/dbus-Rnt0D3oe6g: Connexion refusée
Avertissement GConf : le listage des paires dans « /desktop/gnome/interface » a échoué : Aucun service D-BUS
en cours d'exécution

et le programme ne se lance pas, ou ne s'affiche pas sur le client.

Si je lance çà en sudo, çà fonctionne, mais il n'est pas intéressant de donner des droits root à des fichiers de données ...

Je présume que çà vient des droits du client (lors de la connexion), qui ne sont pas corrects, et que c'est peut-être lié à la version d'Ubuntu sur le serveur, en effet, je n'ai eu aucun soucis sur des serveurs en 12.04, ou en Xubuntu 14.04, mais il est vrai que c'était en local et sans passer par des box, ce qui pourrait aussi amener à penser qu'il s'agit peut-être de ports différents utilisés ?

Bref, je nage un peu, d'autant que je viens tout juste de régler une partie des problèmes que j'avais sur des connexions en passant par cette m... de livebox pro v3.

Si vous avez des pistes, ... ce n'est pas de refus

Merci
A+

#8 Re : -1 »  [Résolu] Lancement de programmes avec ssh -X » Le 10/01/2015, à 21:03

JujuLand
Réponses : 1

Bon, j'ai trouvé les raisons des erreurs gconf. Deux dossiers, pour des raisons que j'ignore, peut-être parce ce que j'avais fais des essais de lancement de progs en sudo (pas sûr), étaient root/root (.config/dconf et .cache.ibus)

Maintenant, j'arrive à lancer sans être sudo.

Donc, hormis l'impossibilité de me connecter directement sur le deuxième ordi, à cause de cette p... de Livebox 3 pro, mes problèmes sont réglés.
J'arrive toutefois à me connecter sur le deuxième ordi en passant par une connexion depuis le premier.

Voilà ...

#9 Re : -1 »  [Abandonné] Module BlueTooth à tort (?) + mot de passe à l'arrêt » Le 18/12/2014, à 10:51

JujuLand
Réponses : 5

Même raison pour xfce-note: il m'aime pas qu'on l'active par ssh -X
Défaut disparu après avoir davalidé le plugin dans le démarrage, et l'avoir revalidé en local.

Reste le mot de passe à l'arrêt ou redémarrage ...

A+

#10 Re : -1 »  [Abandonné] Module BlueTooth à tort (?) + mot de passe à l'arrêt » Le 05/01/2015, à 08:36

JujuLand
Réponses : 5

Mot de passe disparu aussi après réinstall

Bizarre ...

#11 Re : -1 »  [Résolu] Fenêtre de fermeture très longue à venir (Lubuntu & Xubuntu) » Le 19/12/2014, à 22:49

JujuLand
Réponses : 33

Même carte-mère, avec Ubuntu 12.04.5:
Plantage du serveur X lors d'un redémarrage.
Application du même correctif, j'ai simplement remplace le nom du driver radeon, et le libellé Radeon (moins important), tout çà par i915
=> plus de plantage.

Je précise que même si c'est 12.04, il y a semble-t-il eu mise à jour du noyau (43) et de xorg.
Comme quoi tout çà ne semble pas si innocent ...

D'ici que le correctif agisse aussi sur la plantage de serveur X que certain connaissent avec Ubuntu 14.04 (j'étais de ceux-là, et je me suis lassé ...), y'a qu'un pas ...

Cà semble fonctionner sur de l'intel (radeon et i915), ne me faites pas dire que çà pourrait fonctionner avec du nvidia ou du ATI, mais qui sait ...

A+

#12 Re : -1 »  [Résolu] Fenêtre de fermeture très longue à venir (Lubuntu & Xubuntu) » Le 20/12/2014, à 18:06

JujuLand
Réponses : 33

Confirmation du bienfait de l'emplâtre :

Plantage, depuis pas mal de temps sur les redémarrages avec carte nvidia et 12.04
Application de cette méthode en remplaçant radeon par nvidia
Plus de plantage...

A+

#13 Re : -1 »  [Résolu] Fenêtre de fermeture très longue à venir (Lubuntu & Xubuntu) » Le 30/12/2014, à 14:20

JujuLand
Réponses : 33

Plus de problème avec l'intel, alors peut-être une mise à jour ...

A+

#14 Re : -1 »  [résolu] Défaut extinction intel 915. Wifi en cause. » Le 20/12/2014, à 17:58

JujuLand
Réponses : 19

Remplace radeon par i915
Je suppose qu'il doit faire référence au driver, et si c'est un i915, il n'exécutera pas si ce n'est pas le même nom de driver.

Par exemple, j'avais un problème avec une nvidia sous 12.04, j'avais un plantage à l'arret, lors d'une demande de redémarrage. J'ai appliqué çà en remplaçant radeon par nvidia, et plus de plantage au redémarrage.

Alors, essaie, ça ne coûte pas grand chose.

A+

#15 Re : -1 »  [résolu] Défaut extinction intel 915. Wifi en cause. » Le 21/12/2014, à 21:17

JujuLand
Réponses : 19

Une solution, avant de tout casser et réinstaller:

Démarrer en mode recovery (Esc au boot et choisir un démarrage en mode recovery)
fsck
root
cd /home
mv <username> oldname
mkdir <username>
chown <username> <username>
chgrp <username> <username>
reboot

Ceci aura pour effet de repartir sur un dossier utilisateur vierge, et les conneries de paramétrage que tu as pu faire devraient avoir disparu ...

Après, essaye la modif que je propose.
Si çà fonctionne, il te suffira de récupérer les données de oldname (attention: pas .local, .config et .gnome2, les conneries étant là dedans)

A+

#16 Re : -1 »  [résolu] Défaut extinction intel 915. Wifi en cause. » Le 23/12/2014, à 11:25

JujuLand
Réponses : 19

Peut-être simplement, vu que les noms ressemblent, ajouter le param nomodeset dans la ligne de lancement dans grub.

A+

#17 Re : -1 »  [résolu] Défaut extinction intel 915. Wifi en cause. » Le 23/12/2014, à 22:18

JujuLand
Réponses : 19

Sinon, une autre méthode, donnée plus haut, mais incomplète, car il manque le -p:

sudo halt -p

Pour moi, quelque soit la version, çà fonctionne.
Seul inconvénient, ça demande un mot de passe

Fait un petit script :  stop

#!/bin/bash
halt -p

Met le à un endroit ou il peut être appelé sans préciser le chemin, par exemple dans /usr/local/bin

sudo mv stop /usr/local/bin

Ensuite crée une entrée de menu ou un raccourci l'appelant, attention, mettre application, et non terminal (Cà permet d'exécuter une commande ligne sans avoir de terminal visible.):

gksudo stop

Tu peux te faire çà a la main, avec un éditeur, par exemple:

#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Icon=/usr/share/icons/Humanity/actions/48/system-shutdown.svg
Exec=gksudo stop
Name=Arrêter le système

A+

#18 Re : -1 »  [résolu] Défaut extinction intel 915. Wifi en cause. » Le 30/12/2014, à 14:18

JujuLand
Réponses : 19

Ayant eu un D630 entre les mains, et ayant installé Ubuntu dessus, il y a très longtemps, je me souviens maintenant avoir eu des problèmes avec ce chipset ... mais je ne me souviens pas comment j'avais réglé çà.

Tant mieux si tu as enfin réussi à régler 2 problèmes en même temps.
Tu ne nous a pas fait perdre de temps ...

Bonne année 2015

#19 Re : -1 »  [Abandonné] Passage à 14.10: Écran noir pendant plusieurs boots » Le 21/12/2014, à 21:32

JujuLand
Réponses : 4

Essaye la méthode que j'ai posé ici, à tout hasard ... comme en ce moment, les problèmes liés au serveur X font des petits ...

A+

#20 Re : -1 »  [Résolu] problème d'affichage suite à une mise à jour (écran noir) » Le 23/12/2014, à 11:37

JujuLand
Réponses : 88

nam1962,

J'ai quand même eu un problème avec Xubuntu ...
Je suis en train, peut-être, de le régler.

J'installe Xubuntu
Reboot => upgrade
reboot ok
install d'un certains nombre de paquets
Reboot => la session X  est plantée
rien de spécial dans xorg.0.conf
ctrl-alt-F2 => connexion, startx => le serveur est lancé correctement.

J'ai donc bricolé mon script d'install, en le saucissonnant en 6 scripts, afin de voir ou çà coince.
Cà ne semble plus coincer ... j'en suis au 5eme / 6)
Arrêt et relance entre chaque rondelle de saucisson (pas d'ajout comme précédemment d'une rustine dans X11)

On va voir au bout de tout çà ..., et aussi si le redémarrage fonctionne ...
Ce qui est curieux, c'est qu'avant cette mise à jour, j'ai fait l'ordi de ma fille en Xubuntu sans problème, et j'ai vérifié, elle a bien depuis la mise à jour de xorg ...

Y'a quelque chose de pas très sain, tout de même ...
Quand à Unity , j'avais réessayé avec la 14.04 et la 12.04, et impossible de m'en sortir ...
Comme j'adore Unity quand je n'ai pas à m'en servir, ce n'est pas un problème ...

A+

#21 Re : -1 »  Comment créer un lanceur sous Ubuntu 14.04 LTS ? » Le 22/12/2014, à 14:43

JujuLand
Réponses : 4

Le répertoire d'ou sera lancé le programme, ce que tu faisais en tapant la commande
cd ~/captvty/
soit
~/captvty/

A+

#22 Re : -1 »  [Résolut] Perte d'affichage HDMI » Le 22/12/2014, à 09:06

JujuLand
Réponses : 1

Cà se pourrait, car ce sont des signes un peu inquétants d'un mauvais état du disque dur.
Il faudrait faire un fsck.

Le plus simple, démarrer en mode recovery (touche shift ou esc au démarrage) => menu grub
choisir autre puis mode recovery
Et choisir fsck
voir s'il donne des erreurs et les corrige.

A+

#23 Re : -1 »  problème graphique » Le 21/12/2014, à 21:23

JujuLand
Réponses : 3

Normal, Ubuntu utilise Unity qui en terme de ressources utilisées est une vrai catastrophe, comparé à xfce (Xubuntu) ou lxde (Lubuntu)

A+

#24 Re : -1 »  blocage au redemarrage » Le 20/12/2014, à 18:03

JujuLand
Réponses : 15

Je viens d"essayer une solution que j'avais trouvé sur une résolution de bug pour des chipset radeon.

J'ai une carte nvidia at sous 12.04 gnome.

* Ouvrir un terminal (Ctrl+T)
  sudo mkdir -p /etc/X11/xorg.conf.d/
  sudo nano /etc/X11/xorg.conf.d/20-nvidia.conf
* Dans le fichier de configuration vide, ajouter les lignes suivantes:
  Section "Device"
      Identifier "nVidia"
      Driver "nvidia"
      Option "AccelMethod" "EXA"
  EndSection
* Sortir par CTRL+X, puis O pour sauvegarder
* Arrêter
* Relancer
* Quitter => Redémarrer

Normalement, plus de plantage. Enfin pour moi, çà a été ok

A+