>> vncviewer -via euripide
> Shouldn't the format of the command be something like...
> vncviewer SERVERNAME:1 -via localhost
No: the -via option of vncviewer is a short way to setup an ssh tunnel
to the SERVER running Xvnc (vncserver).
On Sun, 16 Feb 2020 13:44:43 +0100 "Patrick Dupre" wrote:
> vncviewer -via euripide
...
> ssh: connect to host euripide.u-bourgogne.fr port 3022: Connection refused
I suspect that you have specified the 3022 port fo connect to euripide
in your ~/.ssh/config file.
1)
I do an an issue with vncserver:
I can run remmina (ssh) on 2 machines, but never vncserver
Can you verify (and undo) that?
Before retrying vncviewer simply test an ssh connection:
Example; ssh -v euripide id
OpenSSH_8.0p1, OpenSSL 1.1.1d FIPS 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/05-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Connecting to 192.168.1.12 [192.168.1.12] port 22.
debug1: Connection established.
debug1: identity file /home/pdupre/.ssh/id_rsa type -1
debug1: identity file /home/pdupre/.ssh/id_rsa-cert type -1
debug1: identity file /home/pdupre/.ssh/id_dsa type -1
debug1: identity file /home/pdupre/.ssh/id_dsa-cert type -1
debug1: identity file /home/pdupre/.ssh/id_ecdsa type -1
debug1: identity file /home/pdupre/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/pdupre/.ssh/id_ed25519 type -1
debug1: identity file /home/pdupre/.ssh/id_ed25519-cert type -1
debug1: identity file /home/pdupre/.ssh/id_xmss type -1
debug1: identity file /home/pdupre/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.0
debug1: match: OpenSSH_8.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.1.12:22 as 'pdupre'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: aes256-gcm(a)openssh.com MAC: <implicit>
compression: none
debug1: kex: client->server cipher: aes256-gcm(a)openssh.com MAC: <implicit>
compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256
SHA256:xwnjpKk6J7iJUd3Znl2SzO+lncZGfcDoGd7r8VKZcgg
debug1: Host '192.168.1.12' is known and matches the ECDSA host key.
debug1: Found key in /home/pdupre/.ssh/known_hosts:9
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /home/pdupre/.ssh/id_rsa
debug1: Will attempt key: /home/pdupre/.ssh/id_dsa
debug1: Will attempt key: /home/pdupre/.ssh/id_ecdsa
debug1: Will attempt key: /home/pdupre/.ssh/id_ed25519
debug1: Will attempt key: /home/pdupre/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info:
server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Unspecified GSS failure. Minor code may provide more information
No Kerberos credentials available (default cache: KEYRING:persistent:1000)
debug1: Next authentication method: publickey
debug1: Trying private key: /home/pdupre/.ssh/id_rsa
debug1: Trying private key: /home/pdupre/.ssh/id_dsa
debug1: Trying private key: /home/pdupre/.ssh/id_ecdsa
debug1: Trying private key: /home/pdupre/.ssh/id_ed25519
debug1: Trying private key: /home/pdupre/.ssh/id_xmss
debug1: Next authentication method: password
(almost the same on both machines)
In addition:
- you have once to setup a vnc passwd on euripide by using the
vncpasswd command.
Sure
- since you have chosen the 5901 port on euripide, you should tell
that to vncviewer:
vncviewer -via euripide :1
vncviewer -via pdupre@192.168.1.12:9
TigerVNC Viewer 64-bit v1.10.1
Built on: 2020-01-13 09:16
Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst)
See
https://www.tigervnc.org for information on TigerVNC.
ssh: Could not resolve hostname 192.168.1.12:9: Name or service not known
Sun Feb 16 16:29:49 2020
DecodeManager: Detected 4 CPU core(s)
DecodeManager: Creating 4 decoder thread(s)
CConn: unable connect to socket: Connection refused (111)
Why ssh: Could not resolve hostname 192.168.1.12:9: Name or service not known ?
The port 9 is that that I use for remmina
- remmina is not needed for that purpose. You have to edit the
file
~/.vnc/xstartup to change the session you want.
Start simple, for example with an xterm
the ~/.vnc/xstartup file is the same on both machine
> Restart afterwards the vncserver@:1.service
>
> --
> francis (currently using a "vncviewer -via" session: it works :-) )
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
>