Re: how to test local ssh server without asking external help
- To: email@example.com
- Subject: Re: how to test local ssh server without asking external help
- From: Joe <firstname.lastname@example.org>
- Date: Wed, 01 Apr 2009 14:23:10 +0100
- Message-id: <3VJAl.180825$Ii4.email@example.com>
- In-reply-to: <clL6R-1Y1firstname.lastname@example.org>
- References: <20090331134834.37a1b383@mio> <email@example.com>
Javier Payno Pallarés wrote:
Some routers do allow it, it depends on whether the firewall is
specifically set to allow connections to the external IP address on its
internal port. NAT in itself does not prevent it happening.
On Tuesday 31 March 2009 13:48:34 Pablo López Martín wrote:
Any ideas why: ssh 192.168.1.10 would work, but ssh external.ip.here
doesn't? I can't test if my ssh server works (or web server, or
ddbb server) except if I ask for external help?
Thats a nat feature, you cant access the external address from an internal
address in the same network where the redirected IP is.
If u wanna test the server from the internet try to buy a shell account in a
remote machine an telnet your IP
I'd agree with you that it's quite useful to have an external host under
your control, for many diagnostic purposes. It's possible to get a
little more information from sites like http://grc.com, which will tell
you if there's a machine listening on 22 on your site and that router
forwarding is working, but there's really no substitute for a proper
test. It is also reassuring to be able to use nmap on your external IP
address. It's surprising how many undocumented holes some routers have.
The thing is that a test to the router's internal port, even using the
external address, isn't a completely valid test of how the router will
treat connections on its external port. Many routers use iptables or the
*BSD equivalent, and it is trivial to base behaviour on the physical
port used, as well as the IP address.
To the OP, you might look at your server /etc/ssh/sshd_config, as there
may be restrictions on the client address, and your client's ssh_config
might be trying different connection methods based on the IP address or
hostname. From what you posted, it appears that your connection is being
actively refused rather than never reaching the server. iptables and
various other means could prevent connection based on IP address, but
you'd probably get some kind of 'no response' error message. It may be
useful to add iptables logging rules to the server, to see whether ssh
traffic is getting in and out.