[SOLVED] SSH remote login will not work

Eahil · 09-10-2013, 03:37 PM

Hi, this has been a problem for me for some time now. I have a clearwire modem, and I've followed a youtube tutorial to open up my ports for my minecraft server, however it doesn't seem to work when I simply want to focus on one specific port rather than every port on my router. (EX: Begin 1, End 65535). My OS is Archlinux, and here is my nmap output.

Code:

 - ~ - sudo nmap -sS -O 127.0.0.1
[sudo] password for ehl: 

Starting Nmap 6.40 ( http://nmap.org ) at 2013-09-10 15:31 EDT
Nmap scan report for localhost.localdomain (127.0.0.1)
Host is up (0.000048s latency).
Not shown: 998 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
5298/tcp open  presence
Device type: general purpose
Running: Linux 3.X
OS CPE: cpe:/o:linux:linux_kernel:3
OS details: Linux 3.7 - 3.9
Network Distance: 0 hops

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 2.10 seconds
 - ~ -

Here is my sshd_config:

Code:

#	$OpenBSD: sshd_config,v 1.89 2013/02/06 00:20:42 dtucker 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 ::

# The default requires explicit activation of protocol 1
Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
#HostKeys for protocol version 2
#HostKey /home/ehl/.ssh/id_rsa.pub
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

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

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

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#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
#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

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

# 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 yes
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
PrintMotd no # pam does that
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation sandbox		# Default for new installations.
#PermitUserEnvironment no
#Compression delayed
ClientAliveInterval 120
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
PermitTunnel yes
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
#Subsystem	sftp	/usr/lib/ssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
	AllowTcpForwarding yes
#	ForceCommand cvs server

As I said, there is sucess when logging into the localhost.

Code:

 - ~ - ssh localhost
ehl@localhost's password: 
Last login: Tue Sep 10 15:27:15 2013 from localhost.localdomain
 - ~ -

But trying to log in from the external IP address (port 22).

Code:

 - ~ - ssh **.**.***.***
ssh: connect to host **.**.***.*** port 22: Connection refused

It doesn't make any sense to me.

akiuni · 09-11-2013, 03:51 AM

Hi

Can you precise what you mean by "external IP" ? is it an ip from outside the LAN ?

Have you checked that ssh is not listening only on the loopback ?
# netstat -an | grep LISTEN | grep 22
should return that 0.0.0.0:22 is opened

Eahil · 09-11-2013, 07:19 PM

Thanks for the response first of all.

To clarify, yes, I mean to connect to the machine from the external ip address, as in by not on the LAN. I'm having a bit of trouble, despite specifying the listening port begin and end as 22 in the router configuration settings.

Archlinux doesn't have netstat, it has netstat-nat, but that didn't have the "-a" option so it failed to run.

Instead I have output from ss.

Code:

- ~ - ss --listening | grep ssh
Netid  State      Recv-Q Send-Q   Local Address:Port       Peer Address:Port   
...
tcp    LISTEN     0      128                  *:ssh                   *:*       
tcp    LISTEN     0      128                 :::ssh                  :::*
...

It says that it's listening but oddly enough, it doesn't seem to have a local address port or a peer address port. Then, I realized after attempting to use journalctl -xn without root, and being apart of the systemd-journal group, that I am currently unable to monitor which ports SSHD was listening on. (sudo groupmems -a ehl --group systemd-journal solved that for me at the time of this writing.)

So, now I have some output to display.

Code:

 - ~ - systemctl status sshd
sshd.service - OpenSSH Daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled)
   Active: active (running) since Wed 2013-09-11 18:52:50 EDT; 21min ago
 Main PID: 7834 (sshd)
   CGroup: name=systemd:/system/sshd.service
           └─7834 /usr/bin/sshd -D

Sep 11 18:52:50 ehlbox sshd[7834]: Server listening on 0.0.0.0 port 22.
Sep 11 18:52:50 ehlbox sshd[7834]: Server listening on :: port 22.
Sep 11 18:52:50 ehlbox systemd[1]: Starting OpenSSH Daemon...
Sep 11 18:52:50 ehlbox systemd[1]: Started OpenSSH Daemon.

I was not seeing this before, but here is the change in the response:

Code:

 - ~ - sudo ssh **.**.***.*** -p 22
ssh: connect to host **.**.***.*** port 22: Connection refused

The ss --listening | grep ssh bit hasn't changed either. It's the same as above.

SAbhi · 09-12-2013, 12:57 AM

what about IP forwarding is it enabled on your system?

Code:

echo 1 >/proc/sys/net/ipv4/ip_forward

To set it permanently go to sysctl.conf and make ip_forward =1.

Code:

sysctl -p

whytigr · 10-10-2013, 05:21 AM

iptables -t filter -L
iptables -t nat -L
iptables -t mangle -L

try disabling
iptables -t filter -F
iptables -t filter -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t nat -F
iptables -t nat -X

try ssh again.. if it works, check the fw rules to find the one blocking your "external address" or add one to allow the host or network you want to allow access.

Hope that helps!

~~Tigr~

lleb · 10-10-2013, 09:46 AM

are you inside your LAN when trying to connect via the WAN port? a lot of routers will not allow this and you will fail.

for LAN access either use your local FQDN of the server or the servers LAN side IP, not localhost as that is the physical box.

from the WWW you can access the server, if and only if, your router is properly configured to forward port 22 (or an alternative port if the router can forward port A on WWW to port B on LAN) to the correct LAN side IP of your server.

as you are running Arch I take it you are NOT running SELinux so that is not an issue. verify that your IPTables has a line allowing port 22, or as a test you can disable IPTables to see if the firewall is an issue at all on the server.

this sounds more like you are in your LAN attempting to connect via the WWW IP or that your router is not properly configured then a firewall issue though to me.

suicidaleggroll · 10-10-2013, 11:35 AM

I'm not really following what has and has not been tried here, so please clarify a few things.

Is the box in question behind a router - in other words are the LAN and WAN IPs the same or different (is the IP reported by ifconfig the same or different than the IP reported if you go to www.whatismyip.com)?

If the box is behind a router, have you set up the necessary port forwarding to forward incoming connections on port 22 to your box's LAN IP address (eg: 192.168.1.2)?

Have you tried SSHing from the box in question to itself using the address 127.0.0.1?

Have you tried SSHing from the box in question to itself using its LAN IP address (eg: 192.168.1.2)?

Have you tried SSHing from another box on your LAN to the box in question using the LAN IP address (eg: 192.168.1.2)?

Have you tried SSHing from another box on your LAN to the box in question using the WAN IP address (your public IP, what gets returned if you go to www.whatismyip.com)?

Have you tried SSHing from another box OUTSIDE your LAN to the box in question using the WAN IP address (your public IP, what gets returned if you go to www.whatismyip.com)?

If you can answer these few questions with a simple yes/no and whether it was successful or failed, I think it will make narrowing down the problem much easier.

Eahil · 10-13-2013, 12:28 PM

Quote:

Is the box in question behind a router - in other words are the LAN and WAN IPs the same or different (is the IP reported by ifconfig the same or different than the IP reported if you go to www.whatismyip.com)?

Yes.

Quote:

If the box is behind a router, have you set up the necessary port forwarding to forward incoming connections on port 22 to your box's LAN IP address (eg: 192.168.1.2)?

Yes.

Quote:

Have you tried SSHing from the box in question to itself using the address 127.0.0.1?

Yes. That failed with:

Code:

 ssh: connect to host 127.0.0.1 port 22: Connection refused

Quote:

Have you tried SSHing from the box in question to itself using its LAN IP address (eg: 192.168.1.2)?

Yes, that also failed weth Connection refused.

Quote:

Have you tried SSHing from another box on your LAN to the box in question using the LAN IP address (eg: 192.168.1.2)?

Connection Refused all the way down.

Quote:

Have you tried SSHing from another box on your LAN to the box in question using the WAN IP address (your public IP, what gets returned if you go to www.whatismyip.com)?

Yes, also the same.

Quote:

Have you tried SSHing from another box OUTSIDE your LAN to the box in question using the WAN IP address (your public IP, what gets returned if you go to www.whatismyip.com)?

All the same.

suicidaleggroll · 10-13-2013, 04:16 PM

Then it sounds like either sshd isn't running or your server's firewall is blocking access on port 22. Focus on being able to ssh from the box in question to itself using the address 127.0.0.1 or its LAN IP, that'll have the fewest variables. Ignore trying to access the box from outside your network until you are able to access it from inside.

Eahil · 10-13-2013, 05:10 PM

So, here's what happened. I altered the port in /etc/ssh/sshd_config and now I can locally connect after restarting sshd.

Now, my issue persists when I attempt to connect outside of the router.

pburwell · 10-21-2013, 02:00 PM

Quote:

Originally Posted by Eahil

So, here's what happened. I altered the port in /etc/ssh/sshd_config and now I can locally connect after restarting sshd.

Now, my issue persists when I attempt to connect outside of the router.

Well now it appears you need to set NAT on your router to allow access for your IPAddr internally from the global IPAddrs to your 22 or 2022 port.

Depends on which one you are using for ssh.

Check...

cat /etc/ssh/sshd_config*|grep -i port

lleb · 10-21-2013, 04:14 PM

Quote:

Originally Posted by Eahil

So, here's what happened. I altered the port in /etc/ssh/sshd_config and now I can locally connect after restarting sshd.

Now, my issue persists when I attempt to connect outside of the router.

well if you modified your port on the server, did you also modify the port in the router?

Eahil · 10-21-2013, 07:59 PM

I did modify the ports on my router, but according to the guide on YouTube from the manufacturers, it should have opened all ports on the router.

lleb · 10-22-2013, 09:28 PM

Quote:

Originally Posted by Eahil

I did modify the ports on my router, but according to the guide on YouTube from the manufacturers, it should have opened all ports on the router.

thats dangerous. dont open ALL ports, but more important you need to be specific with port mapping.

keep in mind your LAN side IPs are NOT visible to the WWW. that is the reason for port mapping. your WAN side IP is visible to the world, but your LAN side IP is NOT.

so for example if your WAN IP = 100.100.100.100 then when you map port 22 to the LAN side IP of 192.168.1.150 any connection via port 22 to the WWW IP of 100.100.100.100 will forward to the LAN side IP of 192.168.1.150.

if you just open the ports, that does NOTHING other then fully expose your LAN to the world for exploits.

Eahil · 12-07-2013, 06:27 PM

I just recently changed ISP's. The new router actually works and allows me to portforward in a much more secure fashion, thanks for your answers!