Hello,
On a server nmap -v -n -Pn -p5900-5910 localhost provides:
Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-15 15:07 EST Initiating SYN Stealth Scan at 15:07 Scanning localhost (127.0.0.1) [11 ports] Completed SYN Stealth Scan at 15:07, 0.42s elapsed (11 total ports) Nmap scan report for localhost (127.0.0.1) Host is up (0.000015s latency). Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp closed vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown 5907/tcp closed unknown 5908/tcp closed unknown 5909/tcp closed unknown 5910/tcp closed cm
How can I open the port vnc?
I also have iptables -L |grep 5901 ACCEPT tcp -- anywhere anywhere tcp dpt:5901
netstat -napt | grep -i vnc tcp 0 0 0.0.0.0:5901 0.0.0.0:* LISTEN 6309/Xvnc tcp6 0 0 :::5901 :::* LISTEN 6309/Xvnc
systemctl status firewalld.service ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-02-10 17:09:16 EST; 4 days ago Docs: man:firewalld(1) Main PID: 928 (firewalld) Tasks: 2 (limit: 4915) Memory: 39.1M CGroup: /system.slice/firewalld.service └─928 /usr/bin/python3 /usr/sbin/firewalld --nofork --nopid
Feb 10 17:09:14 euripide systemd[1]: Starting firewalld - dynamic firewall daemon... Feb 10 17:09:16 euripide systemd[1]: Started firewalld - dynamic firewall daemon.
Thanks
=========================================================================== Patrick DUPRÉ | | email: pdupre@gmx.com Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33 (0)380395988 ===========================================================================
On 2020-02-16 04:19, Patrick Dupre wrote:
How can I open the port vnc?
You have been on this list for some time. So, not sure if you need pointers or exact instructions. For now, pointers.
For firewalld admin use
firewall-cmd for command line firewall-config for gui
On 2020-02-16 04:19, Patrick Dupre wrote:
Hello,
On a server nmap -v -n -Pn -p5900-5910 localhost provides:
Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-15 15:07 EST Initiating SYN Stealth Scan at 15:07 Scanning localhost (127.0.0.1) [11 ports] Completed SYN Stealth Scan at 15:07, 0.42s elapsed (11 total ports) Nmap scan report for localhost (127.0.0.1) Host is up (0.000015s latency). Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp closed vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown 5907/tcp closed unknown 5908/tcp closed unknown 5909/tcp closed unknown 5910/tcp closed cm
Oh, BTW, that nmap command is operating on the localhost and won't be a good indication of a port's status to the outside world.
Example, using the host f31k.
If I am connected to f31k and issue the command I get
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp closed vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown 5907/tcp closed unknown 5908/tcp closed unknown 5909/tcp closed unknown 5910/tcp closed cm
Which ONLY means no service is running and listening on those ports.
Running from a remote host I get
PORT STATE SERVICE 5900/tcp filtered vnc 5901/tcp filtered vnc-1 5902/tcp filtered vnc-2 5903/tcp filtered vnc-3 5904/tcp filtered unknown 5905/tcp filtered unknown 5906/tcp filtered unknown 5907/tcp filtered unknown 5908/tcp filtered unknown 5909/tcp filtered unknown 5910/tcp filtered cm
And "filtered" means there is a firewall rule in effect.
If you were to open the port, the remote system will report "closed" if there is no service running on the port.
I am a bit confuse.
I tried to follow https://docs.fedoraproject.org/en-US/Fedora/21/html/System_Administrators_Gu... On the remote I set: I edited /etc/systemd/system/vncserver@.service ExecStart=/usr/bin/vncserver_wrapper pdupre %i run systemctl start vncserver@:1.service in user: vncserver :1 systemctl start vncserver@:1.service
From Client: nmap -v -n -P0 -p5900-5906 euripide Warning: The -P0 option is deprecated. Please use -Pn Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-16 10:09 CET Initiating Connect Scan at 10:09 Scanning euripide.u-bourgogne.fr (193.52.235.60) [7 ports] Completed Connect Scan at 10:09, 0.05s elapsed (7 total ports) Nmap scan report for euripide.u-bourgogne.fr (193.52.235.60) Host is up (0.047s latency).
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp closed vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.08 seconds
From the remote:
nmap -v -n -Pn -p5900-5906 localhost Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-16 10:11 CET Initiating Connect Scan at 10:11 Scanning localhost (127.0.0.1) [7 ports] Discovered open port 5901/tcp on 127.0.0.1 Completed Connect Scan at 10:11, 0.00s elapsed (7 total ports) Nmap scan report for localhost (127.0.0.1) Host is up (0.00019s latency). Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp open vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds
From client: vncviewer -via pdupre@euripide
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. Sun Feb 16 10:15:07 2020 DecodeManager: Detected 4 CPU core(s) DecodeManager: Creating 4 decoder thread(s) CConn: Connected to host localhost port 48821 channel 3: open failed: connect failed: Name or service not known CConn: End of stream
On a server nmap -v -n -Pn -p5900-5910 localhost provides:
Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-15 15:07 EST Initiating SYN Stealth Scan at 15:07 Scanning localhost (127.0.0.1) [11 ports] Completed SYN Stealth Scan at 15:07, 0.42s elapsed (11 total ports) Nmap scan report for localhost (127.0.0.1) Host is up (0.000015s latency). Other addresses for localhost (not scanned): ::1
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp closed vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown 5907/tcp closed unknown 5908/tcp closed unknown 5909/tcp closed unknown 5910/tcp closed cm
Oh, BTW, that nmap command is operating on the localhost and won't be a good indication of a port's status to the outside world.
Example, using the host f31k.
If I am connected to f31k and issue the command I get
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp closed vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown 5907/tcp closed unknown 5908/tcp closed unknown 5909/tcp closed unknown 5910/tcp closed cm
Which ONLY means no service is running and listening on those ports.
Running from a remote host I get
PORT STATE SERVICE 5900/tcp filtered vnc 5901/tcp filtered vnc-1 5902/tcp filtered vnc-2 5903/tcp filtered vnc-3 5904/tcp filtered unknown 5905/tcp filtered unknown 5906/tcp filtered unknown 5907/tcp filtered unknown 5908/tcp filtered unknown 5909/tcp filtered unknown 5910/tcp filtered cm
And "filtered" means there is a firewall rule in effect.
If you were to open the port, the remote system will report "closed" if there is no service running on the port.
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 2/16/20 1:20 AM, Patrick Dupre wrote:
nmap -v -n -Pn -p5900-5906 localhost PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp open vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
Now you have it running, so the next step is to figure out how to ask firewalld to allow connections to that port. I recommend the graphical interface. In any case be aware of the difference between the running config and the saved config.
Hi
On Sun, 16 Feb 2020 01:33:56 -0800 Samuel Sieb wrote:
On 2/16/20 1:20 AM, Patrick Dupre wrote:
nmap -v -n -Pn -p5900-5906 localhost PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp open vnc-1
...
Now you have it running, so the next step is to figure out how to ask firewalld to allow connections to that port.
I would first verify that Xvnc is not only listening on localhost.
Two ways, From euripide (the "remote", ie: the server)
1. nmap
nmap -v -n -Pn -p5900-5906 euripide
2. or lsof
lsof -p $(pidof Xvnc) | grep LISTEN
Should give something like
Xvnc <snip> TCP *:5901 (LISTEN)
and not:
Xvnc <snip> TCP localhost:5901 (LISTEN)
You can also check the arguments given to Xvnc by vncserver:
ps -wp $(pidof Xvnc)
PS: If you have SSH access, I suggest to restrict Xvnc to localhost and use:
vncviewer -via euripide :1
See the comments in vncserver@.service
On 2020-02-16 17:33, Samuel Sieb wrote:
On 2/16/20 1:20 AM, Patrick Dupre wrote:
nmap -v -n -Pn -p5900-5906 localhost PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp open vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
Now you have it running, so the next step is to figure out how to ask firewalld to allow connections to that port. I recommend the graphical interface. In any case be aware of the difference between the running config and the saved config.
He does seem to have it running on the "localhost". But the status of "closed" makes me suspicious That there is another device/firewall between the client and server. Notice his client is connecting to 193.52.235.60.
I say this since it has been my experience if a firewalld rule is blocking a connection it will show up as "filtered".
For example, f32k is the server and meimei the client. Using ssh as the example server.
With sshd running on the server and firewall open.
PORT STATE SERVICE 22/tcp open ssh
With sshd stopped
PORT STATE SERVICE 22/tcp closed ssh
And with sshd stopped and firewalld configured to disallow the sshd server
PORT STATE SERVICE 22/tcp filtered ssh
And, for completeness, with sshd running and firewalld configured to disallow the sshd server
PORT STATE SERVICE 22/tcp filtered ssh
I am wondering if he needs to add a "port forward" rule on 193.52.235.60 to connect to the "real" vnc-server behind a router's firewall.
...
Now you have it running, so the next step is to figure out how to ask firewalld to allow connections to that port.
I would first verify that Xvnc is not only listening on localhost.
Two ways, From euripide (the "remote", ie: the server)
nmap
nmap -v -n -Pn -p5900-5906 euripide
Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-16 11:46 CET Initiating Connect Scan at 11:46 Scanning euripide (193.52.235.60) [7 ports] Discovered open port 5901/tcp on 193.52.235.60 Completed Connect Scan at 11:46, 0.00s elapsed (7 total ports) Nmap scan report for euripide (193.52.235.60) Host is up (0.00037s latency). Other addresses for euripide (not scanned): fe80::de89:7b2c:9cf1:d1c9
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp open vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds
or lsof
lsof -p $(pidof Xvnc) | grep LISTEN
Xvnc 5308 pdupre 6u IPv4 145831 0t0 TCP *:5901 (LISTEN) Xvnc 5308 pdupre 7u IPv6 145832 0t0 TCP *:5901 (LISTEN)
Should give something like Xvnc <snip> TCP *:5901 (LISTEN) and not: Xvnc <snip> TCP localhost:5901 (LISTEN)You can also check the arguments given to Xvnc by vncserver:
ps -wp $(pidof Xvnc)
PID TTY TIME CMD 5308 ? 00:00:00 Xvnc
PS: If you have SSH access, I suggest to restrict Xvnc to localhost and use:
vncviewer -via euripide :1
vncviewer -via euripide :1 vncviewer -via euripide :0
donne le meme resultat: ssh: Could not resolve hostname euripide.u-bourgogne.fr:1: Name or service not known ssh: Could not resolve hostname euripide.u-bourgogne.fr:0: Name or service not known
See the comments in vncserver@.service
Comment ?
-- francis _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
Yes, there is probably it another device/firewall between the client and server. But the ssh works fine
Sent: Sunday, February 16, 2020 at 11:08 AM From: "Ed Greshko" ed.greshko@greshko.com To: users@lists.fedoraproject.org Subject: Re: open port
On 2020-02-16 17:33, Samuel Sieb wrote:
On 2/16/20 1:20 AM, Patrick Dupre wrote:
nmap -v -n -Pn -p5900-5906 localhost PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp open vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
Now you have it running, so the next step is to figure out how to ask firewalld to allow connections to that port. I recommend the graphical interface. In any case be aware of the difference between the running config and the saved config.
He does seem to have it running on the "localhost". But the status of "closed" makes me suspicious That there is another device/firewall between the client and server. Notice his client is connecting to 193.52.235.60.
I say this since it has been my experience if a firewalld rule is blocking a connection it will show up as "filtered".
For example, f32k is the server and meimei the client. Using ssh as the example server.
With sshd running on the server and firewall open.
PORT STATE SERVICE 22/tcp open ssh
With sshd stopped
PORT STATE SERVICE 22/tcp closed ssh
And with sshd stopped and firewalld configured to disallow the sshd server
PORT STATE SERVICE 22/tcp filtered ssh
And, for completeness, with sshd running and firewalld configured to disallow the sshd server
PORT STATE SERVICE 22/tcp filtered ssh
I am wondering if he needs to add a "port forward" rule on 193.52.235.60 to connect to the "real" vnc-server behind a router's firewall.
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 2020-02-16 19:12, Patrick Dupre wrote:
Yes, there is probably it another device/firewall between the client and server. But the ssh works fine
Well, sure.
But ssh is on port 22. If that port is open/configured but not the port needed for VNC you won't be able to connect.
However, since port 22 is open you can run VNC over SSH. This is actually recommended if your client is on communicating from the Internet.
On 2020-02-16 19:12, Patrick Dupre wrote:
Yes, there is probably it another device/firewall between the client and server. But the ssh works fine
Well, sure.
But ssh is on port 22. If that port is open/configured but not the port needed for VNC you won't be able to connect.
However, since port 22 is open you can run VNC over SSH. This is actually recommended if your client is on communicating from the Internet.
OK, very good.
vncviewer -via pdupre@euripide
Should do it? But I do not see a tunneling ssh option
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
I tried: ssh -L 5900:localhost:5900 -N -f -l pdupre euripide (and ssh -L 5901:localhost:5901 -N -f -l pdupre euripide)
It works, and then vncviewer -via pdupre@euripide (A passwd is required) I try to connect (again a passwd is required). but again: Sun Feb 16 13:08:08 2020 DecodeManager: Detected 4 CPU core(s) DecodeManager: Creating 4 decoder thread(s) CConn: Connected to host localhost port 39007 channel 3: open failed: connect failed: Name or service not known CConn: End of stream
On 2020-02-16 19:12, Patrick Dupre wrote:
Yes, there is probably it another device/firewall between the client and server. But the ssh works fine
Well, sure.
But ssh is on port 22. If that port is open/configured but not the port needed for VNC you won't be able to connect.
However, since port 22 is open you can run VNC over SSH. This is actually recommended if your client is on communicating from the Internet.
OK, very good.
vncviewer -via pdupre@euripide
Should do it? But I do not see a tunneling ssh option
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 2020-02-16 20:04, Patrick Dupre wrote:
On 2020-02-16 19:12, Patrick Dupre wrote:
Yes, there is probably it another device/firewall between the client and server. But the ssh works fine
Well, sure.
But ssh is on port 22. If that port is open/configured but not the port needed for VNC you won't be able to connect.
However, since port 22 is open you can run VNC over SSH. This is actually recommended if your client is on communicating from the Internet.
OK, very good.
vncviewer -via pdupre@euripide
Should do it? But I do not see a tunneling ssh option
I've not used the -via option.
Use this as your guide to ssh tunneling manually.
http://www.allgoodbits.org/articles/view/58
to see if your results are better.
Of course you can skip the part about starting the vncserver.
Thanks. I followed both options:
TightVNC vncviewer -via euripide
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: connect to host euripide.u-bourgogne.fr port 3022: Connection refused
Sun Feb 16 13:27:37 2020 DecodeManager: Detected 4 CPU core(s) DecodeManager: Creating 4 decoder thread(s) CConn: unable connect to socket: Connection refused (111)
I also tried: ssh -f -L 5901:localhost.fr:5901 euripide sleep 10
bind [127.0.0.1]:5901: Address already in use channel_setup_fwd_listener_tcpip: cannot listen to port: 5901 Could not request local forwarding.
=========================================================================== Patrick DUPRÉ | | email: pdupre@gmx.com Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33 (0)380395988 ===========================================================================
vncviewer -via pdupre@euripide
Should do it? But I do not see a tunneling ssh option
I've not used the -via option.
Use this as your guide to ssh tunneling manually.
http://www.allgoodbits.org/articles/view/58
to see if your results are better.
Of course you can skip the part about starting the vncserver.
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 2020-02-16 20:44, Patrick Dupre wrote:
Thanks. I followed both options:
TightVNC vncviewer -via euripide
Shouldn't the format of the command be something like...
vncviewer SERVERNAME:1 -via localhost
Assuming you have sshd running on the localhost.
Hello,
The bizarre thing is that I can connect with remmina (ssh), but not with vncserver. However, connecting with remmina, I get a blue screen, It looks like that it does not start a gnome session. Do I need to startx ? start a gnome daemon?
=========================================================================== Patrick DUPRÉ | | email: pdupre@gmx.com Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33 (0)380395988 ===========================================================================
Sent: Sunday, February 16, 2020 at 1:59 PM From: "Ed Greshko" ed.greshko@greshko.com To: users@lists.fedoraproject.org Subject: Re: open port
On 2020-02-16 20:44, Patrick Dupre wrote:
Thanks. I followed both options:
TightVNC vncviewer -via euripide
Shouldn't the format of the command be something like...
vncviewer SERVERNAME:1 -via localhost
Assuming you have sshd running on the localhost.
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On Sun, 16 Feb 2020 20:59:19 +0800 Ed Greshko wrote:
On 2020-02-16 20:44, Patrick Dupre wrote:
I followed both options: 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.
Can you verify (and undo) that?
Before retrying vncviewer simply test an ssh connection:
Example; ssh -v euripide id
In addition:
- you have once to setup a vnc passwd on euripide by using the vncpasswd command.
- since you have chosen the 5901 port on euripide, you should tell that to vncviewer:
vncviewer -via euripide :1
- 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
Restart afterwards the vncserver@:1.service
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@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: aes256-gcm@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@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On Sun, 16 Feb 2020 16:33:34 +0100 "Patrick Dupre" wrote:
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.
I do have an issue with vncserver: I can run remmina (ssh) on 2 machines, but never vncserver
We should focus on runing vncviewer from the client machine to euripide (running vncserver vith vncserver@:1.service)
Can you verify (and undo) that?
No answer to that point :-(
Before retrying vncviewer simply test an ssh connection:
Example; ssh -v euripide id
<snip>
debug1: Next authentication method: password
You omitted the end. Does the ssh connection succeeded after having given your password?
In addition:
- 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
Why suddently are you using IP numbers? ...
ssh: Could not resolve hostname 192.168.1.12:9: Name or service not known
Why ssh: Could not resolve hostname 192.168.1.12:9: Name or service not known ?
Because it is not the syntax of ssh.
The port 9 is that that I use for remmina
Does this means that you change the way of starting vncserver and that you start it now with:
systemctl start vncserver@:9.service
?
the ~/.vnc/xstartup file is the same on both machine
What do you start in it?
I suspect that you have specified the 3022 port fo connect to euripide in your ~/.ssh/config file.
I do have an issue with vncserver: I can run remmina (ssh) on 2 machines, but never vncserver
We should focus on runing vncviewer from the client machine to euripide (running vncserver vith vncserver@:1.service)
Of course, I opened port 1 on euripide and port 9 on the other one (no name, it is why I use the ip address)
Can you verify (and undo) that?
No answer to that point :-(
yes, because I no not have a .ssh/config file
Before retrying vncviewer simply test an ssh connection:
Example; ssh -v euripide id
<snip> > debug1: Next authentication method: password
You omitted the end. Does the ssh connection succeeded after having given your password?
Of course, I can login ssh The end if the log is: Authenticated to euripide.u-bourgogne.fr ([193.52.235.60]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: network debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: Sending environment. debug1: Sending env XMODIFIERS = @im=none debug1: Sending env LANG = en_US.UTF-8 Web console: https://euripide:9090/ or https://193.52.235.60:9090/
Last failed login: Sun Feb 16 10:08:20 EST 2020 from 86.235.29.229 on ssh:notty There were 2 failed login attempts since the last successful login. Last login: Sun Feb 16 09:14:39 2020 from 86.235.29.229
In addition:
- since you have chosen the 5901 port on euripide, you should tell that to vncviewer:
vncviewer -via euripide :1vncviewer -via pdupre@192.168.1.12:9
Why suddently are you using IP numbers?
Why not?
ssh: Could not resolve hostname 192.168.1.12:9: Name or service not known
Why ssh: Could not resolve hostname 192.168.1.12:9: Name or service not known ?
Because it is not the syntax of ssh.
Sure
The port 9 is that that I use for remmina
Does this means that you change the way of starting vncserver and that you start it now with:
No,
systemctl start vncserver@:9.service
Here, I do not understand. This is what I get on both machines
systemctl status vncserver@:9.service ● vncserver@:9.service - Remote desktop service (VNC) Loaded: loaded (/usr/lib/systemd/system/vncserver@.service; disabled; vendor preset: disabled) Active: inactive (dead)
?
systemctl start vncserver@:1.service ==== AUTHENTICATION COMPLETE ====
systemctl status vncserver@:1.service ● vncserver@:1.service - Remote desktop service (VNC) Loaded: loaded (/etc/systemd/system/vncserver@.service; disabled; vendor preset: disabl> Active: failed (Result: exit-code) since Sun 2020-02-16 17:18:39 CET; 3min 27s ago Process: 11175 ExecStartPre=/bin/sh -c /usr/bin/vncserver -kill :1 > /dev/null 2>&1 || :> Process: 11177 ExecStart=/usr/bin/vncserver_wrapper pdupre :1 (code=exited, status=2) Main PID: 11177 (code=exited, status=2)
Feb 16 17:18:39 euripide systemd[1]: Starting Remote desktop service (VNC)... Feb 16 17:18:39 euripide systemd[1]: Started Remote desktop service (VNC). Feb 16 17:18:39 euripide vncserver_wrapper[11177]: A VNC server is already running as :1 Feb 16 17:18:39 euripide vncserver_wrapper[11177]: FATAL: 'runuser -l pdupre' failed! Feb 16 17:18:39 euripide systemd[1]: vncserver@:1.service: Main process exited, code=exite> Feb 16 17:18:39 euripide systemd[1]: vncserver@:1.service: Failed with result 'exit-code'.
the ~/.vnc/xstartup file is the same on both machine
What do you start in it?
I check because on one of the machine, remmina gives me a blue screen only, while the other one provides me the expected screen (gnome).
-- francis _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 2020-02-16 23:05, Francis.Montagnac@inria.fr wrote:
On Sun, 16 Feb 2020 20:59:19 +0800 Ed Greshko wrote:
On 2020-02-16 20:44, Patrick Dupre wrote:
I followed both options: 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).
Well, if I do as you say it fails for me in the same way as it fails for Patrick.
If I use the format I show, it works just fine.
FWIW, my server is on a KDE based system.
On 2020-02-16 23:05, Francis.Montagnac@inria.fr wrote:
On Sun, 16 Feb 2020 20:59:19 +0800 Ed Greshko wrote:
On 2020-02-16 20:44, Patrick Dupre wrote:
I followed both options: 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).
Well, if I do as you say it fails for me in the same way as it fails for Patrick.
If I use the format I show, it works just fine.
FWIW, my server is on a KDE based system.
vncviewer euripide:1 -via localhost works as badly as vncviewer -via pdupre@euripide:1
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. pdupre@localhost's password:
Sun Feb 16 19:25:33 2020 DecodeManager: Detected 4 CPU core(s) DecodeManager: Creating 4 decoder thread(s) CConn: Connected to host localhost port 41935 .bashrc channel 3: open failed: connect failed: Connection refused CConn: End of stream
-- The key to getting good answers is to ask good questions. _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On Mon, 17 Feb 2020 01:55:01 +0800 Ed Greshko wrote:
On 2020-02-16 23:05, Francis.Montagnac@inria.fr wrote:
On Sun, 16 Feb 2020 20:59:19 +0800 Ed Greshko wrote:
On 2020-02-16 20:44, Patrick Dupre wrote:
I followed both options: 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).
Well, if I do as you say it fails for me in the same way as it fails for Patrick.
Weird. Do you have also:
ssh: connect to host ... port 3022: Connection refused
If I use the format I show, it works just fine.
With "vncviewer SERVERNAME:1 -via localhost" you are first opening an ssh tunnel to localhost. This is useless. I guess you can connect directly with: vncviewer SERVERNAME:1
A way to see how vncviewer setup the ssh tunnel:
strace -s 1000 -f -e execve vncviewer SERVERNAM:1 -via localhost \ |& grep 'execve("/usr/bin/ssh"'
On Sun, 16 Feb 2020 19:27:56 +0100 "Patrick Dupre" wrote:
vncviewer euripide:1 -via localhost
Needs direct access to port 5901 on euripide
works as badly as
vncviewer -via pdupre@euripide:1
You missed a space before the :1 here: It should be:
vncviewer -via pdupre@euripide :1
On 2020-02-16 20:44, Patrick Dupre wrote:
I followed both options: 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).
Well, if I do as you say it fails for me in the same way as it fails for Patrick.
Weird. Do you have also:
ssh: connect to host ... port 3022: Connection refused
ssh euripide.u-bourgogne.fr:3022 ssh: Could not resolve hostname euripide.u-bourgogne.fr:3022: Name or service not known
If I use the format I show, it works just fine.
With "vncviewer SERVERNAME:1 -via localhost" you are first opening an ssh tunnel to localhost. This is useless. I guess you can connect directly with: vncviewer SERVERNAME:1
A way to see how vncviewer setup the ssh tunnel:
strace -s 1000 -f -e execve vncviewer SERVERNAM:1 -via localhost \ |& grep 'execve("/usr/bin/ssh"'
strace -s 1000 -f -e execve vncviewer euripide.u-bourgogne.fr:1 -via localhost |& grep 'execve("/usr/bin/ssh"' [pid 17812] execve("/usr/bin/ssh", ["/usr/bin/ssh", "-f", "-L", "42485:euripide.u-bourgogne.fr:5901", "localhost", "sleep", "20"], 0x55bf48f49930 /* 96 vars */) = 0 pdupre@localhost's password:
After I give the passwd, nothing happens after a timeout, I guess. (I recover the hand).
-- francis _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
vncviewer euripide:1 -via localhost
Needs direct access to port 5901 on euripide
works as badly as
vncviewer -via pdupre@euripide:1
You missed a space before the :1 here: It should be:
vncviewer -via pdupre@euripide :1
Very good, I get
DecodeManager: Detected 4 CPU core(s) DecodeManager: Creating 4 decoder thread(s) CConn: Connected to host localhost port 58191 CConnection: Server supports RFB protocol version 3.8 CConnection: Using RFB protocol version 3.8 CConnection: Choosing security type VeNCrypt(19) CVeNCrypt: Choosing security type TLSVnc (258)
Sun Feb 16 20:08:02 2020 CConn: Using pixel format depth 24 (32bpp) little-endian rgb888 CConnection: Enabling continuous updates
I can connect, but I just get a xclock. (This connection is not secure).
Any gnome session is started (like with remmina). It seems that something is missing, but the .bashrc are identical on both machines which are running the same version of fedora.
-- francis.montagnac@inria.fr, DSI-SP, Tel: (33) 04 92 38 79 11, Bur: C111 INRIA Sophia, 2004, route des Lucioles - BP 93 06902 Sophia Antipolis Cedex _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On Sun, 16 Feb 2020 20:12:55 +0100 "Patrick Dupre" wrote:
vncviewer -via pdupre@euripide :1
Very good, I get
...
I can connect, but I just get a xclock.
Probably due to half brojen VNC session:
lsof -i tcp:5901 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Xvnc 10283 pdupre 6u IPv4 203381 0t0 TCP *:5901 (LISTEN) Xvnc 10283 pdupre 7u IPv6 203382 0t0 TCP *:5901 (LISTEN)
This is probably the vncserver@:1.service that failed to stop properly.
Kill this Xvnc process and start again vncserver@:1.service.
(This connection is not secure).
Wrong message from vncviewer. It's secure bcause goes through the SSH tunnel
Any gnome session is started (like with remmina).
remmina, as vncviewer, only connect to the VNC session.
It seems that something is missing, but the .bashrc are identical on both machines which are running the same version of fedora.
As said before:
- this is the ~/.vnc/xstartup file that determines what session to spawn. - running two gnome-session on the same machine will probably not work.
I always run remmina in VNC viewer mode, in ssh tunnel
That should do the same as "vncviewer -via"
On Sun, 16 Feb 2020 20:12:55 +0100 "Patrick Dupre" wrote:
vncviewer -via pdupre@euripide :1
Very good, I get
...
I can connect, but I just get a xclock.
Probably due to half brojen VNC session:
lsof -i tcp:5901 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Xvnc 10283 pdupre 6u IPv4 203381 0t0 TCP *:5901 (LISTEN) Xvnc 10283 pdupre 7u IPv6 203382 0t0 TCP *:5901 (LISTEN)
This is probably the vncserver@:1.service that failed to stop properly.
Kill this Xvnc process and start again vncserver@:1.service.
I made vncserver -kill :1 and vncserver :1
New 'euripide:1 (pdupre)' desktop is euripide:1
Starting applications specified in /home/dupre/.vnc/xstartup Log file is /home/dupre/.vnc/euripide:1.log
cat .vnc/xstartup unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec /etc/X11/xinit/xinitrc
cat .vnc/euripide:1.log
Xvnc TigerVNC 1.10.0 - built Jan 13 2020 09:18:23 Copyright (C) 1999-2019 TigerVNC Team and many others (see README.rst) See https://www.tigervnc.org for information on TigerVNC. Underlying X server release 12005000, The X.Org Foundation
Sun Feb 16 20:43:35 2020 vncext: VNC extension running! vncext: Listening for VNC connections on all interface(s), port 5901 vncext: created VNC server for screen 0 The XKEYBOARD keymap compiler (xkbcomp) reports:
Internal error: Could not resolve keysym XF86MonBrightnessCycle Internal error: Could not resolve keysym XF86RotationLockToggle
Errors from xkbcomp are not fatal to the X server
Sun Feb 16 20:44:31 2020 Connections: accepted: [::1]::33840 SConnection: Client needs protocol version 3.8 SConnection: Client requests security type VeNCrypt(19) SVeNCrypt: Client requests security type TLSVnc (258)
Sun Feb 16 20:44:42 2020 VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888
Sun Feb 16 20:45:01 2020 ComparingUpdateTracker: 0 pixels in / 0 pixels out ComparingUpdateTracker: (1:-nan ratio)
Sun Feb 16 20:52:31 2020 Connections: accepted: 193.52.235.60::57174
Sun Feb 16 20:52:33 2020 SConnection: Client needs protocol version 3.8 SConnection: Client requests security type VeNCrypt(19)
Sun Feb 16 20:52:35 2020 SVeNCrypt: Client requests security type TLSVnc (258)
Sun Feb 16 20:52:43 2020 VNCSConnST: Server default pixel format depth 24 (32bpp) little-endian rgb888 VNCSConnST: Client pixel format depth 8 (8bpp) bgr233
Sun Feb 16 20:52:44 2020 VNCSConnST: closing [::1]::33840: Clean disconnection EncodeManager: Framebuffer updates: 5 EncodeManager: Tight: EncodeManager: Solid: 4 rects, 3.09043 Mpixels EncodeManager: 64 B (1:193153 ratio) EncodeManager: Total: 4 rects, 3.09043 Mpixels EncodeManager: 64 B (1:193153 ratio) TLS: TLS session wasn't terminated gracefully TcpSocket: unable to get peer name for socket Connections: closed: ::0 ComparingUpdateTracker: 0 pixels in / 0 pixels out ComparingUpdateTracker: (1:-nan ratio)
(This connection is not secure).
Wrong message from vncviewer. It's secure bcause goes through the SSH tunnel
Any gnome session is started (like with remmina).
remmina, as vncviewer, only connect to the VNC session.
It seems that something is missing, but the .bashrc are identical on both machines which are running the same version of fedora.
As said before:
- this is the ~/.vnc/xstartup file that determines what session to spawn.
- running two gnome-session on the same machine will probably not work.
I always run remmina in VNC viewer mode, in ssh tunnel
That should do the same as "vncviewer -via"
-- francis _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On Sun, 16 Feb 2020 20:57:05 +0100 "Patrick Dupre" wrote:
Kill this Xvnc process and start again vncserver@:1.service.
I made vncserver -kill :1 and vncserver :1
You have chosen to start "vncserver ;1" instead of "systemctl start vncserver@:1.service" ... arguable.
You haven't also enabled vncserver@:1.service
New 'euripide:1 (pdupre)' desktop is euripide:1
Starting applications specified in /home/dupre/.vnc/xstartup Log file is /home/dupre/.vnc/euripide:1.log
cat .vnc/xstartup unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec /etc/X11/xinit/xinitrc
Does it work now? Do you have your gnome-session working?
PS1: unsetting SESSION_MANAGER and DBUS_SESSION_BUS_ADDRESS may make two gnome-session work ... may be.
PS2: I forgot to say:
man vncviewer man vncserver
On Sun, 16 Feb 2020 20:57:05 +0100 "Patrick Dupre" wrote:
Kill this Xvnc process and start again vncserver@:1.service.
I made vncserver -kill :1 and vncserver :1
You have chosen to start "vncserver ;1" instead of "systemctl start vncserver@:1.service" ... arguable.
It works the same.
You haven't also enabled vncserver@:1.service
New 'euripide:1 (pdupre)' desktop is euripide:1
Starting applications specified in /home/dupre/.vnc/xstartup Log file is /home/dupre/.vnc/euripide:1.log
cat .vnc/xstartup unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS exec /etc/X11/xinit/xinitrc
Does it work now? Do you have your gnome-session working?
No. Actually I did not change this file. It looks like that it is not executed, How can I check that it is executed? The .bashrc is executed properly.
On the other machine it perfect.
PS1: unsetting SESSION_MANAGER and DBUS_SESSION_BUS_ADDRESS may make two gnome-session work ... may be.
PS2: I forgot to say:
man vncviewer man vncserver-- francis _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On Sun, 16 Feb 2020 21:53:53 +0100 "Patrick Dupre" wrote:
On Sun, 16 Feb 2020 20:57:05 +0100 "Patrick Dupre" wrote:
You have chosen to start "vncserver ;1" instead of "systemctl start vncserver@:1.service" ... arguable.
It works the same.
Almost yes.
Does it work now? Do you have your gnome-session working?
No. Actually I did not change this file. It looks like that it is not executed, How can I check that it is executed?
Modify the .vnc/xstartup for example as follow:
1. only start an xterm
---------------------------------------- set -x unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS xterm ----------------------------------------
restart "vncserver :1"
2. trace xinitrc
---------------------------------------- set -x unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS sh -x /etc/X11/xinit/xinitrc ----------------------------------------
restart "vncserver :1"
Then examine the log: .vnc/euripide:1.log
Look also in the system journal: gnome logs in it (I think).
On 2020-02-17 02:33, Francis.Montagnac@inria.fr wrote:
With "vncviewer SERVERNAME:1 -via localhost" you are first opening an ssh tunnel to localhost. This is useless.
Yes, it is useless.
The reason it worked for me is that the intermediate F/W which I thought had the vnc ports blocked, didn't.
I'd not touch that F/W in a long time and just forgot.
Apologies for the noise.
Thanks Francis,
Now it works. I add to install additional packages for gnome.
=========================================================================== Patrick DUPRÉ | | email: pdupre@gmx.com Laboratoire interdisciplinaire Carnot de Bourgogne 9 Avenue Alain Savary, BP 47870, 21078 DIJON Cedex FRANCE Tel: +33 (0)380395988 ===========================================================================
Sent: Sunday, February 16, 2020 at 10:26 PM From: Francis.Montagnac@inria.fr To: "Community support for Fedora users" users@lists.fedoraproject.org Subject: Re: open port
On Sun, 16 Feb 2020 21:53:53 +0100 "Patrick Dupre" wrote:
On Sun, 16 Feb 2020 20:57:05 +0100 "Patrick Dupre" wrote:
You have chosen to start "vncserver ;1" instead of "systemctl start vncserver@:1.service" ... arguable.
It works the same.
Almost yes.
Does it work now? Do you have your gnome-session working?
No. Actually I did not change this file. It looks like that it is not executed, How can I check that it is executed?
Modify the .vnc/xstartup for example as follow:
- only start an xterm
set -x unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS xterm
restart "vncserver :1"
- trace xinitrc
set -x unset SESSION_MANAGER unset DBUS_SESSION_BUS_ADDRESS sh -x /etc/X11/xinit/xinitrc
restart "vncserver :1"
Then examine the log: .vnc/euripide:1.log
Look also in the system journal: gnome logs in it (I think).
-- francis _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@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
On 16Feb2020 13:44, Patrick Dupre pdupre@gmx.com wrote:
I also tried: ssh -f -L 5901:localhost.fr:5901 euripide sleep 10
bind [127.0.0.1]:5901: Address already in use channel_setup_fwd_listener_tcpip: cannot listen to port: 5901 Could not request local forwarding.
Just to this part:
For things to which I connect regularly I allocate extra 127.0.0.n addresses to my local interface. This lets you bind to a specific address without conflict. Here's part of my local machine's ifconfig:
% ifconfig -a lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 options=3<RXCSUM,TXCSUM> inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.31 netmask 0xff000000 inet 127.0.0.25 netmask 0xff000000 inet 127.0.0.23 netmask 0xff000000 inet 127.0.0.2 netmask 0xff000000 inet 127.0.0.3 netmask 0xff000000 ... etc ...
I also make entries in /etc/hosts:
127.0.0.28 solar.l ... etc ...
which lets you do things like this:
ssh -f -L solar.l:5900:localhost.fr:5900 euripide sleep 10
i.e. bind the local port to a distinct 127.0.0.n address allocated for that ssh tunnel target. I've got over 30 such addresses and names on my personal machine, to support several tunnels.
Our home server does similar (on a lesser scale) and has this line in /etc/rc.local:
addif -i lo 127.0.0.2..9
Note the "2..9" indicating I want 127.0.0.2 through 127.0.0.9. You can get addif here:
https://bitbucket.org/cameron_simpson/css/src/tip/bin/addif
It is just a script to make the right "ifconfig" calls to add addresses, with the right OS-specific variants.
With this I have ssh clauses with preprepared port forward configurations using these. For example, my standard tunnel to the home server has (amongst other forwards):
Host homeserver LocalForward homeserver.l:5905 localhost:5905 LocalForward solar.l:5900 solar:5900
which forwards to the server's local vnc:5 desktop and also to the VNC on the solar monitoring box (which is on the home LAN).
Cheers, Cameron Simpson cs@cskk.id.au
On 2/16/20 2:53 AM, Patrick Dupre wrote:
Two ways, From euripide (the "remote", ie: the server)
nmap
nmap -v -n -Pn -p5900-5906 euripide
Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-16 11:46 CET Initiating Connect Scan at 11:46 Scanning euripide (193.52.235.60) [7 ports] Discovered open port 5901/tcp on 193.52.235.60 Completed Connect Scan at 11:46, 0.00s elapsed (7 total ports) Nmap scan report for euripide (193.52.235.60) Host is up (0.00037s latency). Other addresses for euripide (not scanned): fe80::de89:7b2c:9cf1:d1c9
PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp open vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
If you run this on the server, it's the same system. Even if you specify an IP address, the connection is still going to go over localhost. So this is the same result you had before.
lsof -p $(pidof Xvnc) | grep LISTENXvnc 5308 pdupre 6u IPv4 145831 0t0 TCP *:5901 (LISTEN) Xvnc 5308 pdupre 7u IPv6 145832 0t0 TCP *:5901 (LISTEN)
That is useful. That tells you that it's listening on all interfaces, so you still only need to adjust the firewall to let connections through to that port.
On 2/16/20 2:08 AM, Ed Greshko wrote:
On 2020-02-16 17:33, Samuel Sieb wrote:
On 2/16/20 1:20 AM, Patrick Dupre wrote:
nmap -v -n -Pn -p5900-5906 localhost PORT STATE SERVICE 5900/tcp closed vnc 5901/tcp open vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
Now you have it running, so the next step is to figure out how to ask firewalld to allow connections to that port. I recommend the graphical interface. In any case be aware of the difference between the running config and the saved config.
He does seem to have it running on the "localhost". But the status of "closed" makes me suspicious That there is another device/firewall between the client and server. Notice his client is connecting to 193.52.235.60.
I say this since it has been my experience if a firewalld rule is blocking a connection it will show up as "filtered".
I've never seen someone firewall localhost, not sure if that's even possible. So any port that isn't open will be closed, not filtered.
On 2020-02-17 07:27, Samuel Sieb wrote:
I've never seen someone firewall localhost, not sure if that's even possible. So any port that isn't open will be closed, not filtered.
Yes, but I was actually referring to when he stated that...
From Client: nmap -v -n -P0 -p5900-5906 euripide Warning: The -P0 option is deprecated. Please use -Pn Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-16 10:09 CET Initiating Connect Scan at 10:09 Scanning euripide.u-bourgogne.fr (193.52.235.60) [7 ports]
So, my assumption was that he was testing from a host on the internet.
If I probe his system "euripide " I get
PORT STATE SERVICE 22/tcp open ssh 5900/tcp closed vnc 5901/tcp closed vnc-1 5902/tcp closed vnc-2 5903/tcp closed vnc-3 5904/tcp closed unknown 5905/tcp closed unknown 5906/tcp closed unknown
But if I probe another Linux system directly connected to the Internet I get
PORT STATE SERVICE 22/tcp open ssh 5900/tcp filtered vnc 5901/tcp filtered vnc-1 5902/tcp filtered vnc-2 5903/tcp filtered vnc-3 5904/tcp filtered unknown 5905/tcp filtered unknown 5906/tcp filtered unknown
This lead me to the conclusion that the VNC ports weren't opened at the Internet access point. And that something needed doing to fix/circumvent it.
Anyway, he seems to have it working now running vncviewer over an ssh tunnel.
FWIW, nmap can't accurately detect the what euripide is and reports...
Device type: general purpose|PBX Running (JUST GUESSING): Linux 3.X|4.X|2.6.X (88%), Vodavi embedded (86%) OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 cpe:/h:vodavi:xts-ip cpe:/o:linux:linux_kernel:2.6
So, it sounds like an ISP supplied device. Whereas the Linux system probed above shows as
Device type: general purpose Running: Linux 3.X|4.X OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4 OS details: Linux 3.10 - 4.11, Linux 3.2 - 4.9
Hi.
On Sun, 16 Feb 2020 23:07:28 +0100 "Patrick Dupre" wrote:
Now it works. I add to install additional packages for gnome.
Good.
If you encounter conflicts between components of the (eventual) native gnome session and the VNC one, choose another session (ex: MATE xfce openbox ...) for VNC. Replace thus the call to /etc/X11/xinit/xinitrc by this other session launcher in .vnc/xstartup.
IMO, using a different port for VNC on the two machines is useless and error prone.
On Mon, 17 Feb 2020 09:24:54 +1100 Cameron Simpson wrote:
Just to this part:
For things to which I connect regularly I allocate extra 127.0.0.n addresses to my local interface. This lets you bind to a specific address without conflict.
...
Our home server does similar (on a lesser scale) and has this line in /etc/rc.local:
addif -i lo 127.0.0.2..9
I do something similar on our VNC servers. Mostly like that:
- associate an IP in the 127.0.0.0/8 subnet for each user - polute /etc/hosts with "127.a.b.c vnc-LOGIN" entries - spawn an Xvnc session listening to 127.a.b.c:5900 for each user without using the VNC passwd: Xvnc -SecurityTypes None - protect each session by the firewall with (for each UID/a.b.c):
iptables -I OUTPUT 1 -j REJECT -p tcp -m state --state NEW -m tcp \ -d 127.a.b.c/32 -m owner ! --uid-owner UID
Each user of login LOGIN connect then with
vncviewer -via SERVER vnc-LOGIN
-
Cameron Simpson -
Ed Greshko -
Francis.Montagnac＠inria.fr -
Patrick Dupre -
Samuel Sieb