Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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.
ssh: connect to host <IP> port 22: Connection timed out
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
# Use these options to restrict which interfaces/protocols sshd will bind to
# HostKeys for protocol version 2
#Privilege Separation is turned on for security
# Lifetime and size of ephemeral version 1 server key
# Don't read the user's ~/.rhosts and ~/.shosts files
# For this to work you will also need host keys in /etc/ssh_known_hosts
# similar for protocol version 2
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
# To enable empty passwords, change to yes (NOT RECOMMENDED)
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
# Change to no to disable tunnelled clear text passwords
# Kerberos options
# GSSAPI options
# 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'.
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...
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.
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.
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.