A Very Disappointing Self-Answer
Having set this problem aside for a day and come back to it, I was both relieved and perturbed (more perturbed than relieved) to find that everything was, mysteriously, working properly.
So, What Was the Issue?
No settings were changed or adjusted -- not on the router, not on the SSH server, and not on the SSH client's machine. It's fairly safe to say it was the router not handling the incoming traffic properly, in spite of proper settings. Given that dinky home router software isn't really designed to deal with port forwarding, it took the poor guy a while to implement the necessary changes.
But It's Been Like 6 Hours!!
Yeah dude, I know. I spent all day trying to figure out what was wrong -- and didn't ever find it because there wasn't anything wrong. Evidently, it can take 6 hours -- possibly more -- for the router settings to take effect.
So How Do I Know If This Is My Issue?
A nifty tool I came across during this escapade is tcpdump
. This lean little guy sniffs traffic for you, offering valuable insight into what's actually going on. Plus, he's got some super filtering features that allow you to narrow down exactly what you want to look at/for. For example, the command:
tcpdump -i wlan1 port 22 -n -Q inout
Tells tcpdump
to look for traffic via the wlan1 interface (-i
= 'interface'), only through port 22, ignore DNS name resolution (-n
= 'no name resolution'), and we want to see both incoming and outgoing traffic (-Q
accepts in
, out
, or inout
; inout
is the default).
By running this command on your SSH server while attempting to connect via a remote machine, it quickly becomes clear where precisely the problem lies. There are, essentially, 3 possibilities:
- If you're seeing incoming traffic from the remote machine, but no outgoing traffic from your local server, the problem lies with the server: there's probably a firewall rule that needs to be changed, etc.
- If you're seeing both incoming and outgoing, but your remote machine isn't receiving the response, it's most likely the router: it's allowing the incoming traffic, but dropping your outgoing packets.
- If there's no traffic at all, that's probably a router issue as well: the remote machine's
SYN
packets are being ignored and dropped by the router before they even reach your server.
And once you've discovered where the problem lies, a fix is (usually) trivial.
Best Answer
For the sake of this conversation lets say there are 2 machines named
lappy
andremotey
. Thelappy
system is where you'd be running yourssh
commands from. The system you're connecting to isremotey
.1. Display GUIs from remotey on lappy
Your shell's configuration files are likely setting the environment variable
DISPLAY=:0
. You can grep for this like so:If that doesn't return anything back then the system you're logging into is probably the culprit. Take a peek in this directory as well.
If you'd rather just leave this be you can override this behavior by instructing
ssh
to redirect X traffic back to your client system, like so:Example
Here I have a remote server that has
$DISPLAY
getting set to:0
similar to yours.But no matter, I can still invoke X applications and have them remote displayed to my system that's doing the
ssh
commands. I don't even have to login, I can simply run GUI's directly like so:As a bonus tip you'll probably want to change which ciphers are being used, to help improve the performance of your X11 traffic as it passes over your SSH tunnel.
2. Displaying GUIs on remotey
If you're SSH'ing into
remotey
fromlappy
but would like to keep the GUIs from being displayed onlappy
, then simply drop the-X
switch from yourssh
invoke.3. Eliminating $HOME/.ssh/config
Often times a user's
$HOME/.ssh
directory can introduce unknowns as to what's going on. You can temporarily silence the use of theconfig
file in this directory like so when performing tests.4. Eliminating remote shell's configs
You can use the following test to temporarily disable the shell's configuration files on
remotey
like so:With the above, none of the setup should be getting sourced into this Bash shell, so you should be able to either set
DISPLAY=:0
and then display GUIs to remotey's desktop.You can use the following trick to help isolate the issue, by first removing
--noprofile
and trying this command:Then followed by this command:
The first version will tell you if the problem lies in your
/etc/bashrc
&$HOME/.bashrc
chain of configuration files, while the second version will tell you if the problem lies in the$HOME/.bash_profile
configuration file.