Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have a vnc server running with a certain user configured.
I have created the same vnc user name in the local machine to simplify everything.
Now I am trying to connect with this command:
Code:
ssh -L 59000:localhost:5901 -p 8922 -C -N -l user 188.177.166.155
(fake IP, of course)
Nothing happens. It just waits forever.
I don't remember if there is an active firewall. If there is, it's iptables. So I ran this on the remote machine:
Code:
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 5901 -j ACCEPT
And nothing happens. Connecting just waits forever.
Of course, I can SSH to that remote machine.
The output of ps aux on the remote machine tells me that the vnc server is running.
ssh can be used with -v (or -vvv) to make it verbose. Otherwise I don't really know how is this setup configured, where are those port numbers coming from (and how did you configure/start the client).
ssh can be used with -v (or -vvv) to make it verbose. Otherwise I don't really know how is this setup configured, where are those port numbers coming from (and how did you configure/start the client).
Code:
# ssh -vvv -L 59000:localhost:5901 -p 8922 -C -N -l root 188.177.166.155
OpenSSH_7.4p1 Debian-9
debug1: Reading configuration data /root/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "188.177.166.155" port 8922
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 188.177.166.155 [188.177.166.155] port 8922.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: identity file /root/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_rsa-cert type -1
debug1: identity file /root/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /root/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-9
debug1: match: OpenSSH_7.9p1 Debian-9 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 188.177.166.155:8922 as 'root'
debug3: put_host_port: [188.177.166.155]:8922
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:65
debug3: load_hostkeys: loaded 1 keys from [188.177.166.155]:8922
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,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
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
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: zlib@openssh.com,zlib,none
debug2: compression stoc: zlib@openssh.com,zlib,none
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,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
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: zlib@openssh.com
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: [elided: [Server host key]]
debug3: put_host_port: [188.177.166.155]:8922
debug3: put_host_port: [188.177.166.155]:8922
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:65
debug3: load_hostkeys: loaded 1 keys from [188.177.166.155]:8922
debug3: hostkeys_foreach: reading file "/root/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /root/.ssh/known_hosts:65
debug3: load_hostkeys: loaded 1 keys from [188.177.166.155]:8922
debug1: Host '[188.177.166.155]:8922' is known and matches the ECDSA host key.
debug1: Found key in /root/.ssh/known_hosts:65
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug2: key: /root/.ssh/id_rsa (key)
debug2: key: /root/.ssh/id_dsa (key)
debug2: key: /root/.ssh/id_ecdsa ((nil))
debug2: key: /root/.ssh/id_ed25519 ((nil))
debug3: send packet: type 5
debug3: receive packet: type 7
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>
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /root/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 60
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
debug2: input_userauth_pk_ok: fp SHA256:[elided]
debug3: sign_and_send_pubkey: RSA SHA256:[elided]
debug3: send packet: type 50
debug3: receive packet: type 52
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to 188.177.166.155 ([188.177.166.155]:8922).
debug1: Local connections to LOCALHOST:59000 forwarded to remote address localhost:5901
debug3: channel_setup_fwd_listener_tcpip: type 2 wildcard 0 addr NULL
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Local forwarding listening on ::1 port 59000.
debug2: fd 4 setting O_NONBLOCK
debug3: fd 4 is O_NONBLOCK
debug1: channel 0: new [port listener]
debug1: Local forwarding listening on 127.0.0.1 port 59000.
debug2: fd 5 setting O_NONBLOCK
debug3: fd 5 is O_NONBLOCK
debug1: channel 1: new [port listener]
debug2: fd 3 setting TCP_NODELAY
debug3: ssh_packet_set_tos: set IP_TOS 0x10
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: exec
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 4
debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: receive packet: type 4
debug1: Remote: /root/.ssh/authorized_keys:1: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding
debug3: send packet: type 1
debug1: channel 0: free: port listener, nchannels 2
debug3: channel 0: status: The following connections are open:
debug1: channel 1: free: port listener, nchannels 1
debug3: channel 1: status: The following connections are open:
debug1: Killed by signal 2.
It is ok
You terminated it.
ssh itself is not a vnc client, just a tunnel. You will need to run your client too.
Thanks. Now I understand better what is going on, and I've connected successfully. It works.
However, the screen I get is too small to be useful to my interests. So I clicked Monitor Settings on Openbox (I don't know what that icon launches) and it says
"Unable to get monitor information!"
So I tried arandr and it says:
Code:
Xlib: extension "RANDR" missing on display ":1.0".
Traceback (most recent call last):
File "/usr/bin/arandr", line 42, in <module>
main()
File "/usr/lib/python2.7/dist-packages/screenlayout/gui.py", line 319, in main
force_version=options.force_version
File "/usr/lib/python2.7/dist-packages/screenlayout/gui.py", line 157, in __init__
self.widget = widget.ARandRWidget(display=randr_display, force_version=force_version)
File "/usr/lib/python2.7/dist-packages/screenlayout/widget.py", line 48, in __init__
self._xrandr = XRandR(display=display, force_version=force_version)
File "/usr/lib/python2.7/dist-packages/screenlayout/xrandr.py", line 43, in __init__
version_output = self._output("--version")
File "/usr/lib/python2.7/dist-packages/screenlayout/xrandr.py", line 64, in _output
raise Exception("XRandR returned error code %d: %s"%(status,err))
Exception: XRandR returned error code 1: RandR extension missing
Any idea on how to fix this? I really need a larger view.
most probably you need to adjust your vnc server and/or viewer. From the other hand what you posted is not enough to help you. You need to give us more details. Posting an error message without context is useless.
(and if you really want to say thanks just click on yes)
Yes, more information is needed regarding how you are launching VNC on the remote system.
However, VNC might not be the best choice if you wish to run just a single application. If just one graphical program is needed, you can do X11 forwarding:
Compression might or might slow things down. Root should never (or almost never) be accessed directly remotely. In the very few cases where it is accessed remotely, using a key and turning off passwords is de rigueur. Then even in those cases with password authentication turned off and keys in use, graphical programs must not be run as root. So perhaps would be relevant to ask what problem you are really trying to solve?
most probably you need to adjust your vnc server and/or viewer. From the other hand what you posted is not enough to help you. You need to give us more details. Posting an error message without context is useless.
(and if you really want to say thanks just click on yes)
Sorry, but I really have no idea what other context or more details you think are necessary.
Yes, more information is needed regarding how you are launching VNC on the remote system.
However, VNC might not be the best choice if you wish to run just a single application. If just one graphical program is needed, you can do X11 forwarding:
Compression might or might slow things down. Root should never (or almost never) be accessed directly remotely. In the very few cases where it is accessed remotely, using a key and turning off passwords is de rigueur. Then even in those cases with password authentication turned off and keys in use, graphical programs must not be run as root. So perhaps would be relevant to ask what problem you are really trying to solve?
I'm launching VNC on the remote system this way:
Code:
# /usr/bin/vncserver -localhost
I am told (googling) that the -localhost option causes vncserver to outright refuse connections from outside. Only local conections are accepted. That is good and seems to be true by my tests. I can't connect remotely without the SSH tunnel. I want it that way.
Then I access the vnc session from my local machine:
Code:
xtightvncviewer localhost:59000
Running a single application is a nice idea, but I actually need at least two windows, possibly three. Maybe I will be able to simplify things in the future and run only one thing, but alas it doesn't really work:
You approach works, except that I get that all grey reticulate X screen instead of the desktop manager. Not useful.
Quote:
Originally Posted by Turbocapitalist
Though I am curious as to why there are graphical programs being run as root, and why remote root access via SSH has been turned on.
I always begin by doing everything as root, will change later. If it works as root, it has to work as non-root later or I know that permissions are getting in the way as they so often do. And root access via SSH is disabled with a password. I use a key. If even that is not secure enough, what the hey, let's just stop using passwords altogether or throw all computers in the garbage heap.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
