It used to be the case that I could run:

ssh -v -q -g -R 3353:localhost:22 -n -o BatchMode=yes \
-o StrictHostKeyChecking=no <<my-home-machine>>

and from my home machine, I could simply:

ssh -X -p 3353 bkorb@localhost

and presto, I'm logged into my machine at work.
It worked until I upgraded my SuSE Linux 10.3 to 11.0.
I get the remote connection just fine:

$ ps -w -f -u <funny-user-name>
UID PID PPID C STIME TTY TIME CMD
1000 24894 24885 0 18:50 pts/1 00:00:00 sshd: remote-bk@notty
1000 24895 24894 97 18:50 ? 00:08:00 hold-open

(where "hold-open" is a special non-shell shell for "funny-user-name")
but trying to get back to the office is not working:

$ ssh -vvv -X -p <port> localhost
OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/bkorb/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [127.0.0.1] port 3353.
debug1: connect to address 127.0.0.1 port 3353: Connection refused
debug1: Connecting to localhost [::1] port 3353.
debug1: connect to address ::1 port 3353: Connection refused
ssh: connect to host localhost port 3353: Connection refused

I have sshd running in debug mode, but it has no output while I do this.
Oh, and in /etc/ssh/sshd_config:

# egrep -v $'^[ \t]*($|#)' /etc/ssh/sshd_config
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication yes
AllowTcpForwarding yes
X11Forwarding yes
PermitTunnel yes
Subsystem sftp /usr/lib64/ssh/sftp-server
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

I've been at this all afternoon. And evening now.
Any help would be most sincerely appreciated!!

Regards, Bruce

GatewayPorts yes required in sshd_config ?

No, not required. My home machine is not acting as a gateway.

Well the major change between previous versions of OpenSSH and the one you're using now is that it will refuse to allow X forwarding unless it can bind to the specified port for all address families, i.e. it needs to be able to bind to both IPv4 and IPv6. If one of them fails, it won't listen at all.

Have you checked to make sure you can actually bind to your given port for both versions of IP?

Have you tried lsof -i to see what ports are opened by what programs?

"lsof -i" yielded these two descriptors of interest:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 3546 root 3r IPv4 10816 0t0 TCP 192.168.1.102:spr-itunes->{workmach}:spr-itunes (ESTABLISHED)
sshd 3548 remote-bk 3u IPv4 10816 0t0 TCP 192.168.1.102:spr-itunes->{workmach}:spr-itunes (ESTABLISHED)

(I removed firefox, ntpd, cupsd, portmap, master and avahi-daemon opens.)
I don't know anything about ipv4/6 needs. I just did a plain developer
install of openSuSE 11.0. I tried a more extensive install, but it choked and
died. Probably because /dev/null was a regular file. I didn't discover _that_
problem until after the re-re-install of 11.0. Really Tiresome.
Maybe I had better drop back to 10.3 and live with _its_ problems.

So this is with the tunnel running, yes?

Seems like nothing has grabbed the port on an IPv6 address, so it should be OK...

If you telnet localhost 3353, what do you get?

Also, since that port is used by iTunes for sharing, have you tried using a different port? It's possible SuSE might have a special firewall rule to redirect that port...

Nothing helpful

$ telnet localhost 3353
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Trying ::1...
telnet: connect to address ::1: Connection refused

RE: port 3353 SuSE had better not be doing that. Leastwise,
they are surely not supposed to. Anyway, the same result
using 4353 anyway...

So, I've downloaded and built the sources for the latest ssh release.
Same result with that, too.

Do you get anything in the logs on the remote server? Can you do a tcpdump on the remote server and see if there's even incoming traffic when you try to connect to the tunnel (or actually just tcpdump on your home machine and see if traffic goes out at all). If you don't see any traffic going to the IP address of your server at work, then it's the local connection that's being blocked, not the one on the other end.

Have you tried momentarily stopping iptables on your home machine to see if you can connect?

meaning /var/log/messages?

Jun 30 14:31:08 linux-rq7w sshd[17825]: Invalid user gt05 from 201.22.124.4
Jun 30 14:31:22 linux-rq7w sshd[17827]: reverse mapping checking getaddrinfo forlibraterminal4.static.gvt.net.br [201.22.124.4] failed - POSSIBLE BREAK-IN ATTEMPT!
Jun 30 14:31:22 linux-rq7w sshd[17827]: Invalid user william from 201.22.124.4
Jun 30 14:36:10 linux-rq7w syslog-ng[1812]: STATS: dropped 0
Jun 30 15:04:08 linux-rq7w sshd[18005]: Accepted publickey for remote-bk from 66.126.187.197 port 60606 ssh2
Jun 30 15:10:41 linux-rq7w sshd[18016]: Accepted publickey for remote-bk from 66.126.187.197 port 2347 ssh2
Jun 30 15:18:40 linux-rq7w sshd[18049]: Accepted publickey for remote-bk from 66.126.187.197 port 9704 ssh2
Jun 30 15:24:53 linux-rq7w kernel: device eth0 entered promiscuous mode
Jun 30 15:25:06 linux-rq7w kernel: device eth0 left promiscuous mode
Jun 30 15:26:28 linux-rq7w sshd[18266]: Accepted publickey for remote-bk from 66.126.187.197 port 15753 ssh2
Jun 30 15:26:39 linux-rq7w kernel: device eth0 entered promiscuous mode
Jun 30 15:26:46 linux-rq7w kernel: device eth0 left promiscuous mode

The first attempt with tcpdump got gmail traffic, the second showed no
IP packets at all. Anyway, I was sure before and certain now that either
the traffic is blocked or my local (home) sshd is not setting up the
socket for port 3353.

You asked, ``Have you tried momentarily stopping iptables on your home
machine to see if you can connect?'' Perhaps I've oversold my skills.
I don't know what that means.

Thanks - Bruce

P.S. if you want to contact me directly: bruce.korb at the google mail domain.
If we ever figure this out, I'll post a summary here.

-o ExitOnForwardFailure=yes does not work as advertised.
I am no longer sure exactly what it does, but when I re-installed,
the host key changed. When the host key changes, -o StrictHostKeyChecking=no
will allow the connection to go through, but port forwarding is disabled.
Since the connection went through, I was fooled into believing that
the port ought to have been forwarded.

Short moral of the story: "ssh" sessions should be started by hand, not
in cron jobs.

Longer moral: If IT has procedures in place to occasionally shoot down processes
holding connections open "for too long", then you have to have an automated
restart. Don't use -o StrictHostKeyChecking=no or it fails in mysterious ways.
Avoid re-installing. If you re-install, save your keys for the new installation.

Thank you to all who helped think about the issues.

Regards, Bruce

Glad you got it sorted

Good wrap-up, too!

One more teeny addendum for prosterity: The ssh maintainer
is fixing the bug wherein -o ExitOnForwardFailure=yes failed
to work. So OpenSSL something-after-0.9.8g will be fixed.

It just got committed.

BTW, that's OpenSSH, not OpenSSL. It will likely be something like 5.1p1.