Bonjour,
j’utilise debian wheezy et j’essaie de lancer une commande sur un poste distant via ssh. Voilà ce que je reçois:
sudo /etc/init.d/tkontrole-serv restart
Arret de Tkontrole-Serveur
Demarrage de Tkontrole-Serveur
user@debian:~$ No protocol specified
Application initialization failed: couldn't connect to display ":0.0"
No protocol specified
Et le programme bug…
Alors que si je lance la même commande sur le poste lui-même tout se passe très bien…
Merci de votre aide!
Quel environnement utilises tu? car sur certains bureaux comme GClassic, xfce tu n’as rien besoin de rajouter.
Tu configures les ports et tu peux prendre le controle à distance, c’est ce que je fais avec ces deux desktops
ps: as tu configuré les port de la station récalcitrante?
[mono]Application initialization failed: couldn’t connect to display ":0.0"
No protocol specified[/mono]
dénote un programme utilisant X, le serveur graphique.
option -X en ssh
Voir aussi les réglages du serveur ssh en /etc/ssh/sshd_config (X11Forwarding yes).
X11Forwarding n’est il pas activé d’office lorsque tu installes openssh?
car je n’ai pas touché à /etc/ssh/sshd_config depuis ma réinstallation et il est activé par défaut
Je pense surtout qu’à force d’installer (mal) des paquets il se crée des conflits
Merci pour vos réponses!
pour ssh -X, j’ai déjà essayé et ça ne change rien. Pour info, j’utilise lxde, mais j’ai besoin du terminal, en fait j’utilise cluster ssh pour administrer une quinzaine de pc…
Je vais regarder le X11Forwarding et je vous tiens au courant.
Merci
voilà mon sshd_config, apparemment X11Forwarding est activé…
[EDIT] Je viens de comparer avec un autre sshd_config sur un système pour lequel ça fonctionnait (ubuntu + lxde), et il est identique…
[code]# Package generated configuration file
Port 22
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
#IgnoreUserKnownHosts yes
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication yes
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM yes[/code]
[quote=“totola”]Merci pour vos réponses!
pour ssh -X, j’ai déjà essayé et ça ne change rien. Pour info, j’utilise lxde, mais j’ai besoin du terminal, en fait j’utilise cluster ssh pour administrer une quinzaine de pc…
Je vais regarder le X11Forwarding et je vous tiens au courant.
Merci[/quote]
Tu as quel type d’architecture? Un serveur pour 15 clients?
[quote=“Debianluver”]
Tu as quel type d’architecture? Un serveur pour 15 clients?[/quote]
architecture? Euh en fait j’utilise cluster ssh sur un poste pour me connecter sur 15 postes.
Avant j’étais sous lubuntu mais pour diverses raisons je suis passé à Debian (+lxde), sur tous mes postes, je gagne beaucoup en réactivité, mais je galère un peu plus sur des petits détails de configuration comme ça… Mais je suis presque au bout… Plus qu’à réussir cette commande ssh et j’y suis! 
Salut,
L’un d’eux ne serait-il pas défaillant ?
Une config à revoir/contrôler/vérifier ?
Hormis cette application [mono]clusterssh[/mono]. As-tu simplement tenté/testé d’établir une connexion [mono]ssh -X[/mono] individuelle ?
Comment tu établis la connexion ssh ? Connexions multiples ou connexion unique ? Par ssh simple ou par une de ces commandes spéciales de clusterssh :
packages.debian.org/wheezy/all/ … h/filelist
[quote]
File list of package clusterssh in wheezy of architecture all
/usr/bin/ccon
/usr/bin/clusterssh
/usr/bin/crsh
/usr/bin/cssh
/usr/bin/ctel
…[/quote]
Quels sont les arguments de la commande pour établir la connexion ? Citer la commande.
En quoi consiste [mono]sudo /etc/init.d/tkontrole-serv restart[/mono] (que nous ne connaissons pas) ? A-t-il un lien avec le serveur X ?
Est-ce que tu as essayé [mono]su[/mono]+ mot de passe de root + commande voire [mono]gksu[/mono] au lieu de [mono]sudo[/mono] commande ?
[quote=“totola”]…Application initialization failed: couldn’t connect to display “:0.0”…[/quote]Je me demande s’il ne s’agirait pas d’un message d’erreur généré par Tcl/Tk qui est utilisé par TKontrole,
mais le problème est le même : l’application a bien un problème d’accès à un écran.
Il ya un [mono]X11DisplayOffset 10[/mono] dans le [mono]sshd_config[/mono], et il faudrait connaître le numéro de display effectif utilisable chez le client.
Peut-être avec un [mono]echo $DISPLAY[/mono]
Et puis, j’ai pas tout lu au sujet de TKcontrole, mais il semble qu’il utilise [mono]vnc[/mono] (et même [mono]samba[/mono] + netbios pour “certains clients”).
[quote=“MicP”][quote=“totola”]…Application initialization failed: couldn’t connect to display “:0.0”…[/quote]Je me demande s’il ne s’agirait pas d’un message d’erreur généré par Tcl/Tk qui est utilisé par TKontrole,
mais le problème est le même : l’application a bien un problème d’accès à un écran.
Il ya un [mono]X11DisplayOffset 10[/mono] dans le [mono]sshd_config[/mono], et il faudrait connaître le numéro de display effectif utilisable chez le client.
Peut-être avec un [mono]echo $DISPLAY[/mono]
Et puis, j’ai pas tout lu au sujet de TKcontrole, mais il semble qu’il utilise [mono]vnc[/mono] (et même [mono]samba[/mono] + netbios pour “certains clients”).[/quote]
Bonjour et merci à tous,
je récapitule, j’utilise tkontrole un petit programme très sympa (tkontrole.vverdon.fr/telechargem … le-2.1.pdf) développé par Vincent Verdon, qui permet de prendre le contrôle et de faire des démos (entre autres) sur des postes serveurs distants depuis une machine cliente.
Effectivement, il utilise vnc et tcl/tk (samba et netbios, seulement pour prendre le contrôle de poste windows et linux en même temps, ce qui n’est pas mon cas).
Sur chaque serveur, il y a un service qui doit être démarré, c’est mon /etc/init.d/tkontrole-serv en question.
Il se trouve que je suis de temps en temps obligé de relancer manuellement le service avant de pouvoir me connecter aux postes depuis le client, je ne sais pas pourquoi, mais le service à du mal a se lancer au démarrage, sûrement un conflit dans l’ordre de démarrage des services dont il dépend? J’ai déjà cherché pas mal là-dessus, mais la meilleure solution que j’ai trouvé est de créer un script au démarrage avec une temporisation de 10 secondes puis relancement du service… Mais malgré tout cela, il y a parfois un, deux ou trois postes non-reconnus… Du coup, avant de me connecter, je lance un petit cssh sur tous les postes, et je relance les serveurs, et je suis tranquille pour toute la session… Donc, bah, c’est pas super génial, mais ça ne me prend que 5 secondes au début et j’y suis habitué.
En fait ça fait deux ans que je fonctionne comme ça dans trois salles différentes (sous ubuntu 12.04 et lubuntu 14.04).
Pour diverses raisons, je viens de passer de lubuntu 14.04 a debian Wheezy+lxde (et je suis très content, car tout est bien plus rapide et stable sur ces postes). J’ai tout reconfiguré comme je le souhaitais, excepté ce petit problème avec ssh…
Du coup, comme tout fonctionnait bien avec lubuntu, j’imagine que c’est bien un problème de configuration ou de versions de paquet, je soupçonne même tcl/tk car en cherchant sur google avec le message d’erreur, on voit revoir plusieurs fois tck/tk dans les réponses…
Faudrait-il tenter une mise à jour de ces paquets, il me semble que j’ai les versions 8.5…
Mais c’est bizarre, parce que lorsque je relance le service sur la machine directement (sans ssh) il n’y a pas de problèmes… Et puis pourquoi une erreur de serveur X en relançant un service?? Je suis perplexe…
Merci de votre aide!
[quote=“BelZéButh”]Salut,
L’un d’eux ne serait-il pas défaillant ?
Une config à revoir/contrôler/vérifier ?
Hormis cette application [mono]clusterssh[/mono]. As-tu simplement tenté/testé d’établir une connexion [mono]ssh -X[/mono] individuelle ?[/quote]
Merci pour la réponse
oui, j’ai bien testé ssh -X individuellement(sans passer par cssh), et ça ne marche pas …
PS: Voir plus haut pour un récapitulatif plus complet de la situation
[quote=“etxeberrizahar”]Comment tu établis la connexion ssh ? Connexions multiples ou connexion unique ? Par ssh simple ou par une de ces commandes spéciales de clusterssh :
packages.debian.org/wheezy/all/ … h/filelist
[quote]
File list of package clusterssh in wheezy of architecture all
/usr/bin/ccon
/usr/bin/clusterssh
/usr/bin/crsh
/usr/bin/cssh
/usr/bin/ctel
…[/quote]
Quels sont les arguments de la commande pour établir la connexion ? Citer la commande.
En quoi consiste [mono]sudo /etc/init.d/tkontrole-serv restart[/mono] (que nous ne connaissons pas) ? A-t-il un lien avec le serveur X ?
Est-ce que tu as essayé [mono]su[/mono]+ mot de passe de root + commande voire [mono]gksu[/mono] au lieu de [mono]sudo[/mono] commande ?[/quote]
Bonjour et merci de la réponse,
j’utilise cssh, les autres je ne connais pas?
J’ai déjà essayé su + mot de passe root au lieu de sudo et ça ne change rien…
Pour me connecter je fais un simple ssh user@ip (avec un système de clés + passphrase)
Pour le reste, j’ai répondu un peu plus-haut dans un message récapitulatif et un peu plus explicatif de mon problème
Merci
Salut,
Fais nous un copier/coller d’une connexion vers un poste client (tronques son ip) en mode verbeux (option -v)
puis lances un [mono]~$ echo $DISPLAY[/mono] si la session aboutit.
[quote=“BelZéButh”]Salut,
Fais nous un copier/coller d’une connexion vers un poste client (tronques son ip) en mode verbeux (option -v)
puis lances un [mono]~$ echo $DISPLAY[/mono] si la session aboutit.[/quote]
Voilà:
[code]ssh -X -v 192.168.1.18
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.1.18 [192.168.1.18] port 22.
debug1: Connection established.
debug1: identity file /home/user/.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/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-4+deb7u2
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4+deb7u2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
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 ac:a2:7a:7d:31:ef:b5:7b:eb:5d:62:7a:fc:e9:ec:12
The authenticity of host ‘192.168.1.18 (192.168.1.18)’ can’t be established.
ECDSA key fingerprint is ac:a2:7a:7d:31:ef:b5:7b:eb:5d:62:7a:fc:e9:ec:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ‘192.168.1.18’ (ECDSA) to the list of known hosts.
debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/user/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_parse_private_pem: PEM_read_PrivateKey failed
debug1: read PEM private key done: type
Enter passphrase for key ‘/home/user/.ssh/id_rsa’:
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.1.18 ([192.168.1.18]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR
Linux debian 3.16-0.bpo.3-486 #1 Debian 3.16.5-1~bpo70+1 (2014-11-02) i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Dec 5 13:38:16 2014 from debian-2.local
user@debian:~$ echo $DISPLAY
localhost:10.0
[/code]
[quote=“totola”][code]ssh -X -v 192.168.1.18
[…]
user@debian:~$ echo $DISPLAY
localhost:10.0[/code][/quote]
Sur cette machine visiblement ce n’est pas l’[mono]export display[/mono] ni la session ssh qui sont en causes.
Confirmes (si besoin) en lançant une application graphique (de ton choix) sur le poste [mono]192.168.1.18[/mono], par exemple : [mono]$ gksu gparted[/mono].
PS: il te faut vérifier/tester sur chacun des postes client que l’[mono]export display[/mono] soit fonctionnel , cela lèvera bon nombre de doute.
[mono]$ echo $DISPLAY[/mono]
Il y aura aussi un problème d’autorisation d’accès à ce DISPLAY 0:0 de la machine distante.
Je viens de lire cette page.
L’adresse IP de la machine (EeePC 1005PE) que j’utilise pour me connecter est [mono]192.168.0.16[/mono].
La machine distante est un G53SW.
Une fois connecté par [mono]ssh -X[/mono], j’ai lancé les commande suivantes :
DISPLAY=:0.0
xauth add 192.168.0.16:0 . aabbaabbaabbaabbaabbaabbaabbaabb
thunar
(aabbaabbaabbaabbaabbaabbaabbaabb <=> 32 octets au hasard)
Et [mono]thunar[/mono] s’est affiché sur la machine distante : j’avais donc permis à thunar d’accéder au [mono]DISPLAY 0:0[/mono] de la machine distante (machine “locale” pour thunar).
michel@debG53SW:~$ xauth list
debG53SW/unix:0 MIT-MAGIC-COOKIE-1 2cbad197766099ab6d3d24195cc80687
debG53SW/unix:10 MIT-MAGIC-COOKIE-1 8d401138ef99f856ada0011d2408e3e4
192.168.0.16:0 MIT-MAGIC-COOKIE-1 09090909090909090909090909090909
michel@debG53SW:~$
NOTE: Une fois déconnecté (ssh -X), thunar reste actif sur la machine distante, je suppose qu’il en sera de même pour Tkontrole-Serveur…
Non.
[quote=“totola”][mono]ssh -X -v 192.168.1.18
[…]
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR
[…]
user@debian:~$ echo $DISPLAY
localhost:10.0[/mono][/quote]
[code][11:30:12]:~$ ssh -X -v 192.168.1.20
[…]
debug1: Found key in /home/loreleil/.ssh/known_hosts:3
[…]
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
[…]
Last login: Sun Nov 30 12:08:49 2014 from 192.168.1.10
[11:30:40]:~$ [/code]
[11:30:45]:~$ echo $DISPLAY
localhost:10.0
[11:31:00]:~$
[11:58:37]:~$
[12:09:33]:~$ gksu gparted
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from ::1 36044
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 4 win 65536 max 16384
debug1: client_request_x11: request from ::1 36045
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: client_input_channel_open: ctype x11 rchan 5 win 65536 max 16384
debug1: client_request_x11: request from ::1 36046
debug1: channel 3: new [x11]
debug1: confirm x11
debug1: channel 1: FORCE input drain
debug1: channel 1: free: x11, nchannels 4
[12:10:05]:~$
Broadcast message from root@handy (pts/0) (Sat Dec 6 13:05:23 2014):
The system is going down for reboot NOW!
debug1: channel 0: free: client-session, nchannels 3
debug1: channel 2: free: x11, nchannels 2
debug1: channel 3: free: x11, nchannels 1
Connection to 192.168.1.20 closed by remote host.
Connection to 192.168.1.20 closed.
Transferred: sent 5456808, received 26519272 bytes, in 5686.5 seconds
Bytes per second: sent 959.6, received 4663.6
debug1: Exit status -1
[13:05:23]:~$
Je disais bien : “accès à ce DISPLAY 0:0”, puisque c’est ce display dont TKontrole cherche a obtenir l’accès, pas le [strike]10.0[/strike]