ran nc -l 9922 on the server

had to run netcat from the testing server, didn't have nc command

netcat -zvw 3 XXX.XX.XXX.XXX 9922
XYZ.XYZ.XXYYZZ.edu [XXX.XX.XXX.XXX] 9922 (?) : Connection timed out

it resolved the name correctly (the XYZ.XYZ.XXYYZZ.edu) but connection timed out.

Also, I did stop the iptables with # service iptables stop

side note question why do people put # then a command is it just to signify that its a command? and why did you put a $ instead of # ? did you just use a different version of linux or unix? [sorry I know so little about linux]

$ == user shell prompt
# == root shell prompt

Something is filtering traffic to your host. (And that is easily demonstrated with the nc commands I mentioned.) Bottom line: if you can't establish a tcp connection to the service port, you're not going to be able to use ssh, period.

Earlier in this thread you were connecting to sshd just fine. So we're making backward progress.

Think hard about what you changed between then and now.

-------

edit: Upon closer inspection, I think those messages were from your internal network connections. If so, never mind.

The earlier SSH's with that user were from my internal connection. So, to you it seems like I need to speak to the Network people again? Maybe I spoke with someone that was misinformed? I don't think it matters but I can view the html files on the server from anywhere (which is a tcp connection over port 80 right?)

Yes, http is tcp port 80. (https is tcp port 443.)

Before you talk to your network staff, put together and document a test case which clearly shows:

1. that your host-level firewall is off
2. that sshd is listening on tcp 22 (use the netstat command output)
3. that connections to sshd from external hosts are being filtered (use nc or nmap)

Include that (concise, neat) documentation in your next request to them.

Sounds like the voice of someone who has had to read requests like this submitted to them daily

I really appreciate the help. I will try to remember to let everyone know what I find out when I hear from the Network staff again. I really appreciate everything.

If you can ssh access the server from your local network and you can not access from outside, there might be a possibility that the ssh traffic is getting blocked in local system firewall.

You can do a ping/traceroute test from outside (hope they are allowed by the network admins)to check the connectivity. However, I believe that that will go through as you are able to access the website hosted on the same server.

Do you have any rule in your /etc/hosts.deny file for sshd?

@avijitp
#
# hosts.deny This file describes the names of the hosts which are
# *not* allowed to use the local INET services, as decided
# by the '/usr/sbin/tcpd' server.
#
# The portmap line is redundant, but it is left to remind you that
# the new secure portmap uses hosts.deny and hosts.allow. In particular
# you should know that NFS uses portmap!

Nope, above is the contents of hosts.deny. And its all commented out.

And yes I can ping from the outside, and I'm not sure about traceroute because the test box I'm logged into remotely needs su privileges and I don't have them for the remote machine I'm using to test my server with.

So I just wanted to let everyone know, that the problem is not fixed yet, but the Network people have said they are going to fix it. So, apparently I spoke with someone who was misinformed the first time. Thank you all for the help and hopefully this is resolved now.