Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I edited my SSH configuration to accept connections on Port 213, as it was one of the few ports that my work firewall allows through.

I then restarted sshd and everything was going well.

I tested the ssh server locally, and checked the sshd service was listening on port 213; however, I still cannot get it to work outside of localhost.

PuTTY gives a connection refused message, and some of the sites that allow check of ports I tried said the port was closed.

To me, this is either firewall or port forwarding. But I've already added inbound and outbound exceptions for it.

Is this a problem with my server host, or is there something I've missed?

My full SSH config file, as requested:

#   $OpenBSD: sshd_config,v 1.73 2005/12/06 22:38:28 reyk Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

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

# 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 change a
# default value.

Port 22
Port 213
#Protocol 2,1
Protocol 2
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key

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

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
SyslogFacility AUTHPRIV
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6

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

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and 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 yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

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

# GSSAPI options
#GSSAPIAuthentication no
GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
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 mechanism. 
# Depending on your PAM configuration, this may bypass the setting of 
# PasswordAuthentication, PermitEmptyPasswords, and 
# "PermitRootLogin without-password". If you just want the PAM account and 
# session checks to run without PAM authentication, then enable this but set 
# ChallengeResponseAuthentication=no
#UsePAM no
UsePAM yes

# Accept locale-related environment variables
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES 
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT 
AcceptEnv LC_IDENTIFICATION LC_ALL
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem   sftp    /usr/libexec/openssh/sftp-server
share|improve this question

closed as not a real question by Michael Hampton, Ward, Scott Pack, Iain Sep 29 '12 at 20:04

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

    
How could we possibly know? It's your server; go take a look. –  Michael Hampton Sep 20 '12 at 20:40
    
(1) Why aren't you having your admin open standard SSH ports for you, or port-forward something from an external IP to your machine's SSH port? -- This question smells of "I don't like my work policy on network connectivity so I'm trying to get around it." -- that's not kosher around these parts. (2) Have you verified that sshd is listening on an IP that's accessible from outside your firewall? –  voretaq7 Sep 20 '12 at 20:40
    
Sounds to me like you bound ssh to listen to the local interface instead of all interfaces... or your company's network systems killed you dead. –  Jeff Ferland Sep 20 '12 at 20:41
    
I've asked. They won't. –  Kian Sep 20 '12 at 20:41
    
@JeffFerland I can still connect via Port 22 though? –  Kian Sep 20 '12 at 20:41

1 Answer 1

You could verify if it is listening on those ports on a public interface with a simple command.

netstat -tunelp | grep -i ssh

Obviously, you'd also need to make sure that the remote machine has the outbound port 213 open and that the server in question has inbound 213 open. Nmap from a remote machine would show this

nmap -v -sT myremotehost.com -p 213

This isn't going to be an exact science considering the remote host could be blocked outbound and that the server could be blocking inbound. So disabling the firewall and using process of elimination would be easy enough.

Save the existing iptables rules

iptables-save > /root/iptables.rules

Flush the existing rules

iptables -F 
iptables -X 
iptables -t nat -F 
iptables -t nat -X 
iptables -t mangle -F 
iptables -t mangle -X 
iptables -P INPUT ACCEPT 
iptables -P FORWARD ACCEPT 
iptables -P OUTPUT ACCEPT

Then run your tests.

Then to restore the old rules ...

iptables-restore < /root/iptables.rules

Just note. I'm not condoning disabling a firewall on a production machine.

share|improve this answer
    
Well it's definitely listening on a public interface. It's annoying, because my home computer is Windows, and I don't have any of the cables for my raspberry pi so I keep having to download Windows ports of tools. –  Kian Sep 20 '12 at 22:07
    
OK, so I think it crashed when I disabled the firewall. I can't SSH, or FTP, HTTP –  Kian Sep 20 '12 at 22:12
    

Not the answer you're looking for? Browse other questions tagged or ask your own question.