Sponsored Content
Top Forums UNIX for Dummies Questions & Answers Is it possible that X11 can be forwarded through a SSH tunnel Post 302962388 by sleepy_11 on Sunday 13th of December 2015 10:13:24 PM
Old 12-13-2015
Is it possible that X11 can be forwarded through a SSH tunnel

I communicate with the server via a ssh tunnel, configured via Putty.

Recently, I'm trying to forward the X11 through it, but it doesn't work.

Is there any one work this way?

Searched with google, but didn't find anything.

Thx in adv.
 

10 More Discussions You Might Find Interesting

1. Programming

using a ssh tunnel with nx compression

hi everybody and thank you for this wondefrul forum this is my first thread posted here and i hope that i could find some help from your part (i am even sure) :D here is the situation: i am to develop an application of remote desktop access such as vnc, vpn and especially nx i want to develop... (0 Replies)
Discussion started by: bolboln01
0 Replies

2. UNIX for Advanced & Expert Users

ssh decipher a tunnel

Two question here, but it's only one on the protocol point of view. If two persons use the same key to connect to a SSH server is there a risk they can decipher the other tunnel. In other terms is that less safe than if they have two separate keys. Same question if two persons use the same user... (2 Replies)
Discussion started by: moi
2 Replies

3. UNIX for Advanced & Expert Users

Stopping SSH tunnel

I have initiated a tunnel for vncserver. now i want to stop it. is there any way except sleep option? (2 Replies)
Discussion started by: majid.merkava
2 Replies

4. UNIX for Dummies Questions & Answers

SSH tunnel working for ssh but not for sshfs

I'm trying to setup a link between my home pc (work-machine) and a server at work (tar-machine) that is behind a gateway (hop-machine) and not directly accessible. my actions: work-machine$ ssh -L 1234:tar-machine:22 hop-machine work-machine$ ssh -p 1234 user@127.0.0.1 - shh access on... (1 Reply)
Discussion started by: Vathau
1 Replies

5. IP Networking

Help with SSH tunnel?

I have a Java web app on machine (X) that needs to talk to an LDAP server (Y) on :636, but the LDAP server is only accessible on a particular network. I can login to a machine (Z) on that network from X, and this machine can talk to the LDAP server on :636. How can I tunnel so that X can... (2 Replies)
Discussion started by: spacegoose
2 Replies

6. UNIX for Advanced & Expert Users

Ssh tunnel question

Hi all I have a suite of scripts that ssh to remote servers within a cluster and run some tests. This is done from a central server so that all of the test results can be captured in one location. Problem is I now have 509 tests and the number is growing. The scripts work by establishing a... (2 Replies)
Discussion started by: steadyonabix
2 Replies

7. Red Hat

X11 forwarding through a tunnel

Is it possible to launch an X11 application and have it use an X11 server on the other side of a bastion host? Specifically, here's my setup: my laptop ------------- bastion -------------- remote host I have putty installed on my laptop. The bastion is rhel 6.5 and the remote host is... (1 Reply)
Discussion started by: tsreyb
1 Replies

8. Proxy Server

WebSocket over SSH tunnel - is it possible?

Hello, I have a video streaming application that utilizes a WebSocket for the server <-> client communication. My goal is to make the video streaming service available over the internet in the cases where neither the server nor client have public IPs. One way to do this is over a VPN... (8 Replies)
Discussion started by: Vladislav
8 Replies

9. Solaris

Tunnel X over ssh for 11.3

Hello Solaris experts: Trying to bring the 11.3 gdm screen over ssh to a Linux Box: I did the following: 1. made chanes to /etc/ssh/sshd_config & bounced ssh daemon: # X11 tunneling options X11Forwarding yes X11DisplayOffset 10 X11UseLocalhost yes 2. From the remote Linux box: ... (6 Replies)
Discussion started by: delphys
6 Replies

10. UNIX for Advanced & Expert Users

Tunnel using SSH

I am not clear with the part of concept of Tunneling using ssh. ssh -f -N -L 1029 192.168.1.47:25 james@192.168.1.47 I found out that above code works for me . but didn't quite well understood how ti works and need to ask you guys some questions. since we are using tunnel through ssh ... (2 Replies)
Discussion started by: lobsang
2 Replies
SSLH(8) 																   SSLH(8)

NAME
sslh - ssl/ssh multiplexer SYNOPSIS
sslh [-F config file] [ -t num ] [-p listening address [-p listening address ...] [--ssl target address for SSL] [--ssh target address for SSH] [--openvpn target address for OpenVPN] [--http target address for HTTP] [-u username] [-P pidfile] [-v] [-i] [-V] [-f] [-n] DESCRIPTION
sslh accepts connections in HTTP, HTTPS, SSH, OpenVPN, tinc, XMPP, or any other protocol that can be tested using a regular expression, on the same port. This makes it possible to connect to any of these servers on port 443 (e.g. from inside a corporate firewall, which almost never block port 443) while still serving HTTPS on that port. The idea is to have sslh listen to the external 443 port, accept the incoming connections, work out what type of connection it is, and then fordward to the appropriate server. Protocol detection The protocol detection is made based on the first bytes sent by the client: SSH connections start by identifying each other's versions using clear text "SSH-2.0" strings (or equivalent version strings). This is defined in RFC4253, 4.2. Meanwhile, OpenVPN clients start with 0x00 0x0D 0x38, tinc clients start with "0 ", and XMPP client start with a packet containing "jabber". Additionally, two kind of SSH clients exist: the client waits for the server to send its version string ("Shy" client, which is the case of OpenSSH and Putty), or the client sends its version first ("Bold" client, which is the case of Bitvise Tunnelier and ConnectBot). If the client stays quiet after the timeout period, sslh will connect to the first protocol defined (in the configuration file, or on the command line), so SSH should be defined first in sslh configuration to accommodate for shy SSH clients. Libwrap support One drawback of sslh is that the ssh and httpd servers do not see the original IP address of the client anymore, as the connection is forwarded through sslh. sslh provides enough logging to circumvent that problem. However it is common to limit access to ssh using libwrap or tcpd. For this reason, sslh can be compiled to check SSH accesses against SSH access lists as defined in /etc/hosts.allow and /etc/hosts.deny. Configuration file A configuration file can be supplied to sslh. Command line arguments override file settings. sslh uses libconfig to parse the configuration file, so the general file format is indicated in <http://www.hyperrealm.com/libconfig/libconfig_manual.html>. Please refer to the example configuration file provided with sslh for the specific format (Options have the same names as on the command line, except for the list of listen ports and the list of protocols). The configuration file makes it possible to specify protocols using regular expressions: a list of regular expressions is given as the probe parameter, and if the first packet received from the client matches any of these expressions, sslh connects to that protocol. Alternatively, the probe parameter can be set to "builtin", to use the compiled probes which are much faster than regular expressions. OPTIONS
-t num, --timeout num Timeout before forwarding the connection to the first configured protocol (which should usually be SSH). Default is 2s. -p listening address, --listen listening address Interface and port on which to listen, e.g. foobar:443, where foobar is the name of an interface (typically the IP address on which the Internet connection ends up). This can be specified several times to bind sslh to several addresses. --ssl target address Interface and port on which to forward SSL connection, typically localhost:443. Note that you can set sslh to listen on ext_ip:443 and httpd to listen on localhost:443: this allows clients inside your network to just connect directly to httpd. --ssh target address Interface and port on which to forward SSH connections, typically localhost:22. --openvpn target address Interface and port on which to forward OpenVPN connections, typically localhost:1194. --xmpp target address Interface and port on which to forward XMPP connections, typically localhost:5222. --tinc target address Interface and port on which to forward tinc connections, typically localhost:655. This is experimental. If you use this feature, please report the results (even if it works!) -v, --verbose Increase verboseness. -n, --numeric Do not attempt to resolve hostnames: logs will contain IP addresses. This is mostly useful if the system's DNS is slow and running the sslh-select variant, as DNS requests will hang all connections. -V Prints sslh version. -u username, --user username Requires to run under the specified username. -P pidfile, --pidfile pidfile Specifies a file in which to write the PID of the main server. -i, --inetd Runs as an inetd server. Options -P (PID file), -p (listen address), -u (user) are ignored. -f, --foreground Runs in foreground. The server will not fork and will remain connected to the terminal. Messages normally sent to syslog will also be sent to stderr. --background Runs in background. This overrides foreground if set in the configuration file (or on the command line, but there is no point setting both on the command line unless you have a personality disorder). FILES
/etc/init.d/sslh Start-up script. The standard actions start, stop and restart are supported. /etc/default/sslh Server configuration. These are environment variables loaded by the start-up script and passed to sslh as command-line arguments. Refer to the OPTIONS section for a detailed explanation of the variables used by sslh. SEE ALSO
Last version available from <http://www.rutschle.net/tech/sslh>, and can be tracked from <http://freecode.com/projects/sslh>. AUTHOR
Written by Yves Rutschle v1.13b 2012-08-26 SSLH(8)
All times are GMT -4. The time now is 08:10 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy