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.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).īy running this command on your SSH server while attempting to connect via a remote machine, it quickly becomes clear where precisely the problem lies. For example, the command: tcpdump -i wlan1 port 22 -n -Q inout Plus, he's got some super filtering features that allow you to narrow down exactly what you want to look at/for. This lean little guy sniffs traffic for you, offering valuable insight into what's actually going on. Evidently, it can take 6 hours - possibly more - for the router settings to take effect.Ī nifty tool I came across during this escapade is tcpdump. I spent all day trying to figure out what was wrong - and didn't ever find it because there wasn't anything wrong. 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. It's fairly safe to say it was the router not handling the incoming traffic properly, in spite of proper settings. No settings were changed or adjusted - not on the router, not on the SSH server, and not on the SSH client's machine. 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. what the heck else is there?ĮDIT: Connection Request from Internal Network Error ssh connect to host 192.168.1.90 port 22: No route to host So, then: What else could it be? It certainly appears to be a firewall-y sort of thing to just ignore traffic, but if it's not the router, it's not iptables, and it's not another firewall on the SSH server. And I don't have any other firewalls in place - it's a relatively fresh Debian netinst. It's Not IPTables (I think) sudo iptables -Lįail2ban-ssh tcp - anywhere anywhere multiport dports sshĪCCEPT tcp - anywhere anywhere tcp dpt:sshĪCCEPT tcp - anywhere anywhere tcp dpt:http Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds NMap Says It's Filtered nmap -p 22 99.3.26.94 Interestingly, port 80 worked without a hitch - goes straight to the Apache web directory. I've got my home router set up to forward ports 80 and 22 to my SSH server. Where robots is my remote host, and 99.3.26.94 is my local SSH server.
Ssh: connect to host 99.3.26.94 port 22: Connection timed out Here's what happens when I try to SSH in from a remote host: ssh -vv Debian-5, OpenSSL 1.0.1k ĭebug1: Reading configuration data /etc/ssh/ssh_configĭebug1: /etc/ssh/ssh_config line 19: Applying options for *ĭebug1: Connecting to 99.3.26.94 port 22.ĭebug1: connect to address 99.3.26.94 port 22: Connection timed out I'm pretty sure there's a really obvious fix for this that I'm simply overlooking.
When I try to SSH from a remote host into my local SSH server, the SSH server doesn't respond and the request times out. I'm attempting to set up an SSH server on my local machine using OpenSSH.
0 kommentar(er)
