Передача X процессов через SSH автоматически сценарием

Я пытался настроить носатый для контроля некоторой основной статистики (процессор/использование памяти, использование HDD и т.д.) с моего домашнего сервера.

После большого бездельничания сегодня мне удалось заставить процесс работать путем входа на пути

screen ssh -X 

и затем выполнение

conky -c /path/to/config

Носатый процесс затем запускает на моем ноутбуке и сохраняется, даже когда я закрыл ssh сеанс вниз.

Однако я пытаюсь заставить это начинать со сценария на моем ноутбуке, таким образом, я могу автоматическое выполнение он при начальной загрузке.

Я настроил пользователя, который регистрирует на пути ключ без пароля, чтобы попытаться получить все это работа (в конечном счете, я стремлюсь пытаться заставить его просто просить пароль, когда я войду в систему, и процесс запускается), но я просто не могу заставить его работать.

Сценарий, который я использую,

#/bin/bash
screen ssh -X myconkyuser@myserverip "conky -c /path/to/config"

но это просто отказывается отображаться носатый.

Даже вручную ввод

screen ssh -X myconkyuser@myserverip "conky -c /path/to/config" 

от терминала не сделает этого.

Если я делаю

screen ssh -X -vv myconkyuser@myserverip "conky -c /path/to/config" 

Я вижу, что соединение SSH происходит, и носатый запускает, оно просто не передается X-серверу моего ноутбука правильно.

Я также попытался поместить conky -c /path/to/config как его собственный сценарий на сервере и использовании

screen ssh -X myconkyuser@myserverip "sh /path/to/conkystartupscript" 

но результатом является то же.

Я присоединю вывод от -vv чтобы видеть, может ли это пролить какой-либо свет, я предполагаю, что проблема могла бы состоять в том, что сессия закрывается перед носатым процессом на самом деле выводы к дисплею, но я попытался добавить a pause 10 ниже носатой строки напрасно.

Кто-либо может помочь?

will@will-Inspiron-7520 ~ 19:46:44 $ ssh -X -vv myconkyuser@myserverip "conky -c /path/to/myconky/config "
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /my/ssh/folder/config
debug1: /my/ssh/folder/config line 1: Applying options for myserverip
debug1: /my/ssh/folder/config line 8: Applying options for myserverip
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "myserverip" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to myserverip [myserverip] port 22.
debug1: Connection established.
debug1: identity file /my/ssh/folder/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file /my/ssh/folder/id_ed25519-cert type -1
debug1: identity file /my/ssh/folder/myconkyuserid_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /my/ssh/folder/myconkyuserid_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to myserverip:22 as 'myconkyuser'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: 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,ext-info-c
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,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,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-ed25519 SHA256:yXsLEfcX1vuLtfzDI/flPwX4OYATC0Usa9EKmZFojWE
debug1: Host 'myserverip' is known and matches the ED25519 host key.
debug1: Found key in /my/ssh/folder/known_hosts:5
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /my/ssh/folder/myconkyuserid_rsa (0x5560479c2e00), explicit, agent
debug2: key: will@will-Inspiron-7520 (0x5560479c2ea0), agent
debug2: key: /my/ssh/folder/id_ed25519 (0x5560479b5060), explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /my/ssh/folder/myconkyuserid_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:PanRCck33pj+N8mNWoTLkaoaVudzUQlv5CTaF12SJ0Y
debug1: Authentication succeeded (publickey).
Authenticated to myserverip ([myserverip]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: exec
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth  list :0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending environment.
debug1: Sending env LC_PAPER = 
debug2: channel 0: request env confirm 0
debug1: Sending env LC_ADDRESS = 
debug2: channel 0: request env confirm 0
debug1: Sending env LC_MONETARY = 
debug2: channel 0: request env confirm 0
debug1: Sending env LC_NUMERIC = 
debug2: channel 0: request env confirm 0
debug1: Sending env LC_TELEPHONE = 
debug2: channel 0: request env confirm 0
debug1: Sending env LC_IDENTIFICATION = 
debug2: channel 0: request env confirm 0
debug1: Sending env LANG = en_GB.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_MEASUREMENT = 
debug2: channel 0: request env confirm 0
debug1: Sending env LC_TIME = en_GB.UTF-8
debug2: channel 0: request env confirm 0
debug1: Sending env LC_NAME = 
debug2: channel 0: request env confirm 0
debug1: Sending command: conky -c /path/to/myconky/config 
debug2: channel 0: request exec confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: X11 forwarding request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: exec request accepted on channel 0
debug2: channel 0: rcvd ext data 7
conky: debug2: channel 0: written 7 to efd 7
debug2: channel 0: rcvd ext data 108
debug2: channel 0: rcvd ext data 62
Syntax error (/path/to/myconky/config:2: unexpected symbol near '#') while reading config file. 
conky: Assuming it's in old syntax and attempting conversion.
debug2: channel 0: written 170 to efd 7
debug1: client_input_channel_open: ctype x11 rchan 3 win 65536 max 16384
debug1: client_request_x11: request from 127.0.0.1 36372
debug2: fd 8 setting O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug2: channel 0: rcvd ext data 65
conky: desktop window (1a00022) is subwindow of root window (d5)
debug2: channel 0: written 65 to efd 7
debug2: channel 0: rcvd ext data 28
conky: window type - normal
debug2: channel 0: written 28 to efd 7
debug2: channel 0: rcvd ext data 45
conky: drawing to created window (0x5200001)
debug2: channel 0: written 45 to efd 7
debug2: channel 0: rcvd ext data 32
conky: drawing to double buffer
debug2: channel 0: written 32 to efd 7
debug2: channel 0: rcvd ext data 42
conky: forked to background, pid is 14055
debug2: channel 0: written 42 to efd 7
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
debug2: channel 0: rcvd eow
debug2: channel 0: close_read
debug2: channel 0: input open -> closed
debug2: channel 1: rcvd eof
debug2: channel 1: output open -> drain
debug2: channel 1: obuf empty
debug2: channel 1: close_write
debug2: channel 1: output drain -> closed
debug1: channel 1: FORCE input drain
debug2: channel 1: ibuf empty
debug2: channel 1: send eof
debug2: channel 1: input drain -> closed
debug2: channel 0: rcvd eof
debug2: channel 0: output open -> drain
debug2: channel 0: obuf empty
debug2: channel 0: close_write
debug2: channel 0: output drain -> closed
debug2: channel 0: rcvd close
debug2: channel 0: almost dead
debug2: channel 0: gc: notify user
debug2: channel 0: gc: user detached
debug2: channel 0: send close
debug2: channel 0: is dead
debug2: channel 0: garbage collecting
debug1: channel 0: free: client-session, nchannels 2
debug2: channel 1: send close
debug2: channel 1: rcvd close
debug2: channel 1: is dead
debug2: channel 1: garbage collecting
debug1: channel 1: free: x11, nchannels 1
Transferred: sent 16740, received 12920 bytes, in 3.8 seconds
Bytes per second: sent 4378.2, received 3379.1
debug1: Exit status 0

Существует несколько синтаксических ошибок в носатом файле (это - очень старое, но это делает задание, которое я хочу), но я не думаю, что они вызывают проблему как будто я ssh -X в сервер и затем запускаются носатый, все работает, как желаемый.

(NB, который вывод кода выше, не используя экран в качестве использующий экран, очищает терминал. Похоже, что это проходит по существу тот же процесс хотя),