# SSH times out when attempting connection?

## finalturismo

When try to SSH over a public ip i get a timeout. If the port is closed on my router i get a connection refused message. So i know the opening of the port has been done correctly and i can SSH in my other Debian web-server correctly.

I correctly opened the port on my Cisco router like i have a million times before,  I am sure i am missing something simple?

```
Here is my SSHD config

#   $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $

# This is the sshd server system-wide configuration file.  See

# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with

# OpenSSH is to specify options with their default value where

# possible, but leave them commented.  Uncommented options override the

# default value.

Port 22

AddressFamily any

ListenAddress 0.0.0.0

ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key

#HostKey /etc/ssh/ssh_host_ecdsa_key

#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying

#RekeyLimit default none

# Logging

#SyslogFacility AUTH

#LogLevel INFO

# Authentication:

#LoginGraceTime 2m

PermitRootLogin yes

#StrictModes yes

#MaxAuthTries 6

#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2

# but this is overridden so installations will only check .ssh/authorized_keys

#AuthorizedKeysFile   .ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none

#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts

#HostbasedAuthentication no

# Change to yes if you don't trust ~/.ssh/known_hosts for

# HostbasedAuthentication

#IgnoreUserKnownHosts no

# Don't read the user's ~/.rhosts and ~/.shosts files

#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!

PasswordAuthentication no

#PermitEmptyPasswords no

# Change to no to disable s/key passwords

#ChallengeResponseAuthentication yes

# Kerberos options

#KerberosAuthentication no

#KerberosOrLocalPasswd yes

#KerberosTicketCleanup yes

#KerberosGetAFSToken no

# GSSAPI options

#GSSAPIAuthentication no

#GSSAPICleanupCredentials yes

# 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

#AllowAgentForwarding yes

#AllowTcpForwarding yes

#GatewayPorts no

#X11Forwarding no

#X11DisplayOffset 10

#X11UseLocalhost yes

#PermitTTY yes

PrintMotd no

PrintLastLog no

#TCPKeepAlive yes

#PermitUserEnvironment no

#Compression delayed

#ClientAliveInterval 0

#ClientAliveCountMax 3

#UseDNS no

#PidFile /run/sshd.pid

#MaxStartups 10:30:100

#PermitTunnel no

#ChrootDirectory none

#VersionAddendum none

# no default banner path

#Banner none

# override default of no subsystems

Subsystem   sftp   /usr/lib64/misc/sftp-server

# Example of overriding settings on a per-user basis

#Match User anoncvs

#   X11Forwarding no

#   AllowTcpForwarding no

#   PermitTTY no

#   ForceCommand cvs server

# Allow client to pass locale environment variables. #367017

AcceptEnv LANG LC_ALL LC_COLLATE LC_CTYPE LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME LANGUAGE LC_ADDRESS LC_IDENTIFICATION LC_MEASUREMENT LC_NAME LC_PAPER LC_TELEPHONE

# Allow client to pass COLORTERM to match TERM. #658540

AcceptEnv COLORTERM
```

----------

## szatox

"Timeout" sounds like a firewall to me. This is exactly what happens when your connections hits a DROP target in iptables.

You can try running ssh with -vvv to get more details from the client.

Also, I suggest running a sniffer (e.g. tcpdump) on the server to find out whether or not your incoming traffic reaches the target.

----------

## finalturismo

 *szatox wrote:*   

> "Timeout" sounds like a firewall to me. This is exactly what happens when your connections hits a DROP target in iptables.
> 
> You can try running ssh with -vvv to get more details from the client.
> 
> Also, I suggest running a sniffer (e.g. tcpdump) on the server to find out whether or not your incoming traffic reaches the target.

 

You just reminded me of something, i do have iptables installed with NAT and almost ever networking capability built into the kernel. 

There is a chance a firewall is on the Gentoo side of things, i will let you guys know later what happens. I did do the -vvv command already and i didnt find anything useful to the issue at hand. 

Just a general error message with no useful info that would point to the problem.

----------

## pankaj13

Try adding following line at the end of /etc/ssh/sshd_config

AllowUsers root <add any other user names that might need to ssh>

----------

## Hu

 *pankaj13 wrote:*   

> Try adding following line at the end of /etc/ssh/sshd_config
> 
> AllowUsers root <add any other user names that might need to ssh>

 Could you explain your suggestion?  Allowing root is generally considered a bad idea, and the OP's description of the problem is not consistent with this being an sshd authentication configuration problem, so I would not expect AllowUsers to be relevant.

----------

