SSH connection refused on local network
 

After looking online and searching the forums, I only find vague suggestions that haven't helped with this problem:

I have Fedora 16 on VMWare player, in Windows 7 and when trying to ssh to a Linux 15 server on the local network, I get "connection refused."

I have:
--verified ssh is installed and running on both machines
--verified that "ssh localhost" works on both machines
--tried disabling Windows Firewall, no effect
--tried adding port 22 to the router configuration to allow traffic, no effect
--telnet also fails

I see that using ssh -vv flag tells me nothing new, other than connection refused and the IP (my router's internet-facing IP, interestingly enough).

Any suggestions on what else to try?

Hi mbvpixies78, You say you "tried adding port 22 to the router configuration to allow traffic". Did you forward the port to the internal IP of the machine you're trying to connect to?

Good luck. ;-)

Yes, I have a Linksys router and have "port range forward" for port 22 to the private IP of the linux server to which I'm trying to ssh, applying to both TCP and UDP protocols ("Both".) (At least on the page I looked at, the network portion of the IP is non-negotiable, meaning I couldn't set it to the internet-facing IP even if I wanted to do so.)

I really can't think of anything else to try here. I understand networking much better than I used to (halfway through CCNA) and still, no luck with something so simple.

I was thinking, once the semester is over, about replacing the router's firmware with OpenWRT, but I don't think that would necessarily make any difference. My hunch is that this is some screwy Windows bug. I want to wipe the laptop and use Linux instead of Linux VM on Windows... will be interesting to see if problem goes away, but I can't do that for another month. Meanwhile, I'd really like to get ssh working sooner than that.

keeping traffic "in the family"
 

If your external IP is denying entry, some aspect of your connection attempt is sending your traffic outside the router and then back in. If you're connecting LAN to LAN, you shouldn't need to even touch your router (looks like you already know that, but I just wanted to make sure).

I haven't used VMWare in awhile, but something about virtualizing a NIC creates networking complex enough to require minds greater than mine to fully grasp. I remember deciding (read: trial and many errors) between giving the VM its own address and using the host machine's IP with NAT. I can't recall now which worked better; try switching from wherever you are now.

Sorry I can't offer more specifics, but take care to ensure your traffic stays in-house. Is DNS taking you outside?

Sorry, I overlapped you. One more idea: The gateway! If your VM is using your host OS as a gateway (which in turn uses the router), the only way your traffic can go anywhere is through the router first.

Also possible^H^H^H probable. I'm always eager to blame Windows. Though we sound like cynix, always bet on Linix.
I made that up just now. Feel free to use it GPL.
:-)

Other random thoughts:
Unless you can't specify TCP/UDP on your router, ssh will never use UDP.

Good job on that CCNA--I need to get back to mine. That TCP stack is incredible the first time you peel it apart. Rusty now, but I got pretty good at calculating netmasks. My friend said I was odd for enjoying that part, and he's probably right.

Any NDIS filters on the host, McAfee, Symantec?

Good luck. ;-)

I'm using NAT and I will look into changing that since I've never done so before. I'll post results when I have the time to try this.

I'll have to look into NDIS before I can respond.

Thanks!

bridged, still not working
 

I switched VM from NAT to bridged and now instead of "Connection refused," I get "Connection timed out."

With ssh -vv user@dom.ain I see that it's still trying to connect to the internet-facing interface IP.

If I try ssh user@<privateIPaddress> I get the same "Connection timed out."

"Refused" is generally a box not running ssh--or at least not accepting clients. The timeout means your auth never reaches its destination--unless it drops unwanted packets with a firewall.

Public DNS only knows you by your public IP, so connecting to host.dom.ain will will always route out through the interwebs--and consequently back into your router--unless you're serving internal DNS.

Somehow the routing is broken, and I'm fuzzy on when a virtual bit on a virtual NIC becomes a real bit on a real NIC (see previous reference to networking voodoo in a VM). Does a traceroute show anything useful? Try running nmap from a Linux box to your Windows box running the VM. Does it find ssh running on a nonstandard port?

wtf...
 

I replied to this post once I fixed the problem but apparently the post disappeared into the ether fuzz.

Essentially, I switched from NAT to a bridged connection, if I recall correctly, and then I made sure to add exceptions to my Windows Firewall for both outgoing and incoming communications over ssh port 22. That fixed it. Now I have a new ssh question pertaining to encrypted system log-in that I'll post elsewhere.

Thanks for your help!

Excellent! Glad to hear it. I was wondering.

...dang either fuzz.
;-)