SSH from outside my network.

NotAComputerGuy · 08-05-2013, 06:00 AM

For some reason I cannot connect to my SSH box from outside my network. I've got tun0 and eth0 as my interfaces. 192.168.0.184 is the SSH box. I have port forwarding from 22 to go to 192.168.0.184. Also attached is my sshd. I don't use passwords to log in, only keys, but I don't think it's even getting that far. I can log in fine inside my network.

Code:

ssh: connect to host <IP> port 22: Connection timed out

My router log:

Code:

Aug  5 11:40:43 syslog: always->SSHIN=eth3 OUT=br0 SRC=46.21.99.25 DST=192.168.0.184 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=15561 DF PROTO=TCP SPT=43427 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 MARK=0x8000000

My sshd file.

Code:

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile	%h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

I'm grateful for any ideas.

joe_2000 · 08-05-2013, 06:07 AM

Did you confirm you are using the right IP? (I am typically using e.g. http://www.whatismyip.com/) Can you ping it?

Are you using a non-default iptables configuration? If so you may want to post it here.

Edit: Are you using DHCP? If so, maybe turn it off and set static IPs manually. Some routers I came across were picky with this.

NotAComputerGuy · 08-05-2013, 06:16 AM

Definitely the right IP address.

I don't think any of my iptables stuff has been made permanent. Not sure how I check that.

I am using static IP addresses.

joe_2000 · 08-05-2013, 06:23 AM

Quote:

Originally Posted by NotAComputerGuy

I don't think any of my iptables stuff has been made permanent. Not sure how I check that.

Code:

iptables -L

NotAComputerGuy · 08-05-2013, 06:24 AM

Code:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

joe_2000 · 08-05-2013, 06:41 AM

Hmm, ok, that's not it. Sorry I am running out of ideas. If it was me who had the problem I'd probably try and see if I can make another service visible from outside the network, such as e.g. a webserver over port 80. But I am sure there are smarter ways to proceed...

One thing that might be helpful to others for diagnosing the problem is the spec of the router and the configuration of it you are using...

haertig · 08-05-2013, 06:45 AM

Test #1: Add the -v option to your ssh attempt and determine where the timeout is happening. Before or after you connect to the target box?

Test #2: Try killing your sshd daemon on the box you're trying to login to, and see if your message changes to "Connection refused" rather than "Connection timed out". Of course, you should only kill sshd if no other user is using SSH and you have another method (physical access?) to get to the box to restart sshd after the test.

haertig · 08-05-2013, 06:47 AM

Look at your target servers logfile to see if a connection attempt was noted. My logfile is in /var/log/auth.log but yours may be in a different place. You will need to be root to view this logfile.

NotAComputerGuy · 08-05-2013, 06:59 AM

Code:

ssh -vv user@ip
OpenSSH_6.0p1 Debian-3, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to IP port 22.
debug1: connect to address IP port 22: Connection timed out
ssh: connect to host IP port 22: Connection timed out

There's nothing in any logs that I can see that relate to this. It looks like it gets to the route and the information is 'lost' between the router and the box. It's a Sky SR101 Router.

Tried several reboots without success.

joe_2000 · 08-05-2013, 08:31 AM

Quote:

Originally Posted by NotAComputerGuy

It's a Sky SR101 Router.

I've googled portforwarding for this router and found this:

http://www.skyuser.co.uk/forum/sky-r...ding-help.html

It seems that your router has all incoming ports closed by default. There are some further links in the thread (which I haven't reviewed) but you may want to take a look at that...

Edit: On second view it seems this is applying to another sky router, I would still check it out for yours as well.

NotAComputerGuy · 08-05-2013, 08:39 AM

I have port forwarding set up on it and set it to always log, and I believe that it is working as you can see in my router logs it sees when I try and connect it gives:

Code:

Aug  5 11:40:43 syslog: always->SSHIN=eth3 OUT=br0 SRC=46.21.99.25 DST=192.168.0.184 LEN=60 TOS=0x00 PREC=0x00 TTL=54 ID=15561 DF PROTO=TCP SPT=43427 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 MARK=0x8000000

Edit: Just tried shields up which says the port is stealth. However, my router does log the scan:

Code:

Aug  5 14:40:43 syslog: always->SSHIN=eth3 OUT=br0 SRC=4.79.142.206 DST=192.168.0.184 LEN=44 TOS=0x00 PREC=0x00 TTL=226 ID=61440 PROTO=TCP SPT=32891 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x8000000 
Aug  5 14:40:44 syslog: always->SSHIN=eth3 OUT=br0 SRC=4.79.142.206 DST=192.168.0.184 LEN=44 TOS=0x00 PREC=0x00 TTL=226 ID=61440 PROTO=TCP SPT=32891 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x8000000 
Aug  5 14:40:44 syslog: always->SSHIN=eth3 OUT=br0 SRC=4.79.142.206 DST=192.168.0.184 LEN=44 TOS=0x00 PREC=0x00 TTL=226 ID=61440 PROTO=TCP SPT=32891 DPT=22 WINDOW=8192 RES=0x00 SYN URGP=0 MARK=0x8000000

That is all that is logged from the scan, despite it being the 'Full service scan'.

joe_2000 · 08-05-2013, 08:48 AM

Sorry, I think this was a wrong trace. Obviously all incoming ports are closed by default on every router, it just looked to me as if this particular router had another layer of security / firewall on top, which needed to be customised. But I think that was a misinterpretation on my side.

NotAComputerGuy · 08-05-2013, 09:01 AM

Rebooted the box, everything works fine, start the VPN and now it stops responding.

Looks like it is to do with the VPN.

NotAComputerGuy · 08-05-2013, 10:06 AM

Current idea: SSH into 1 box, then jump across the network into the other.

Bit of an awkward way of doing it.

joe_2000 · 08-05-2013, 03:16 PM

Quote:

Originally Posted by NotAComputerGuy

Rebooted the box, everything works fine, start the VPN and now it stops responding.

Looks like it is to do with the VPN.

Huh? VPN? This is something you haven't mentioned before. You may want to provide some more information on your network setup/layout to get useful help...