Originally posted on Ask Ubuntu
If you have ruled out any "external" factors, the following set of steps usually helps to narrow it down. So while this doesn't directly answer your question, it may help tracking down the error cause.
Troubleshooting sshd
What I find generally very useful in any such cases is to start sshd
without letting it daemonize. The problem in my case was that neither syslog
nor auth.log
showed anything meaningful.
When I started it from the terminal I got:
# $(which sshd) -Ddp 10222
/etc/ssh/sshd_config line 8: address family must be specified before ListenAddress.
Much better! This error message allowed me to see what's wrong and fix it. Neither of the log files contained this output.
NB: at least on Ubuntu the $(which sshd)
is the best method to satisfy sshd
requirement of an absolute path. Otherwise you'll get the following error: sshd re-exec requires execution with an absolute path
. The -p 10222
makes sshd
listen on that alternative port, overriding the configuration file - this is so that it doesn't clash with potentially running sshd
instances. Make sure to choose a free port here.
Finally: connect to the alternative port (ssh -p 10222 user@server
).
This method has helped me many many times in finding issues, be it authentication issues or other types. To get really verbose output to stdout
, use $(which sshd) -Ddddp 10222
(note the added dd
to increase verbosity). For more debugging goodness check man sshd
.
The main advantage of this method is that it allows you to check the sshd
configuration without having to restart the sshd
on the default port. Normally this should not interfere with existing SSH-connections, but I've seen it. So this allows one to validate the configuration file prior to - potentially - cutting off ones access to a remote server (for example I have that for some VPS and even for physical servers where I need to pay extra to get out-of-band access to the machine).
Performing SSH tunneling can get a bit confusing with all the terminology, but there is a complementary feature to -L
, which provides you the ability to "dynamically" assign ports by allocating a socket locally, instead of a single port.
From the man page:
-D [bind_address:]port
Specifies a local ``dynamic'' application-level port forwarding. This works by
allocating a socket to listen to port on the local side, optionally bound to the
specified bind_address. Whenever a connection is made to this port, the connection
is forwarded over the secure channel, and the application protocol is then used to
determine where to connect to from the remote machine. Currently the SOCKS4 and
SOCKS5 protocols are supported, and ssh will act as a SOCKS server. Only root
can forward privileged ports. Dynamic port forwardings can also be specified in
the configuration file.
By allocating a socket, all the traffic can be funneled through to the remote site, including DNS queries.
How to use it
For starters you'll need to open up a connection to your LAN (through its public IP address on the internet) like so:
$ ssh -D 1234 myserver
NOTE: This assumes that you have the ability to SSH into a server that's accessible through your public internet IP address.
Once that's setup, in another terminal, you'll want to configure your web browser to make use of this tunnel. NOTE: This type of tunnel is providing you a socket, so to connect to it, you need to tell your web browser to proxy all of its traffic via this socket. This is typically shown as a SOCKS or SOCKS v5 type of connection for your proxy.
An example
In this example I'll show how you can do it using Chromium, via the CLI:
$ ./Chromium --proxy-server="socks5://localhost:1234"
Here I'm launching Chromium and pointing it to the SSH tunnel which we earlier configured on our localhost's port 1234. And with this, if I then attempt to visit a URL for a server that's configured on my LAN, I'm directed to it:
Proxying with other browsers
All the major browsers provide this feature and it's covered pretty extensively on other SE sites such as SuperUser:
You can even make use of extensions to the various browsers which allow you to selectively proxy only certain traffic, while allowing you to route everything else out over your normal connection to the internet.
For example, you can use ProxySwitchy! with Chrome to do exactly that:
Best Answer
If the server you're
ssh
'ing into has a GUI running you forgo using the-X
switch tossh
and set the$DISPLAY
variable on the server prior to running thewine
application like so:If on the other hand you do want to see the GUI via
ssh
then you could try changing the compression used to hopefully speed things up via SSH tunnel.Using these ciphers should significantly speed up your connection.
References
SSH - How to make X applications run on client?