1

So, I've been using SSH from an Ubuntu desktop to access my Raspberry Pi over the LAN using the command:

ssh 192.168.1.185

or occasionally

ssh -YC 192.168.1.185

I'll be moving in a few days, and the Pi isn't going with me, so I need to be able to access the Pi from a remote network, over the internet. I've tried forwarding port 22 on my router, but when trying:

ssh <external ip>

I get:

ssh: connect to host <external ip> port 22: Connection refused

I don't know what information might be helpful to provide, but looking around some similar questions "netstat -tlpn" is usually useful:

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2733/lighttpd   
tcp        0      0 0.0.0.0:21              0.0.0.0:*               LISTEN      15009/pure-ftpd (SE
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      20234/sshd      
tcp        0      0 0.0.0.0:19048           0.0.0.0:*               LISTEN      3433/python     
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      2993/mysqld

My ssh_config may also be useful, so here is that, in full:

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

# 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

Many thanks to anyone who can help!

5
  • Did you test your port forwarding from within your network, or from outside? Some routers will not apply the port forwarding if packets are coming from inside the network itself. Also try using a none-reserved port on the router as incoming port (also slightly more secure)
    – Gerben
    Jul 10, 2013 at 13:59
  • Is your public (external) IP address static, or dynamic? If it is dynamic, it will change every once in awhile and cause you issues. Typically your ISP will charge a little extra for a static address.
    – Butters
    Jul 10, 2013 at 14:52
  • Also verify that iptables is not blocking the traffic. Stop the service with service iptables stop and try again if it works, you will want to modify your iptables config to allow SSH from anywhere (Or your remote address if it is static) rather than not running the service.
    – Butters
    Jul 10, 2013 at 14:55
  • If you have access to a server on the internet, you could always have the Pi reverse ssh to that server, and then ssh from the server to the Pi with ease.
    – demure
    Jul 10, 2013 at 20:41
  • Thanks for the comments everyone. I didn't get any email notifications so I assumed there were no responses... Will try out these suggestions now I know they're here! Sep 12, 2013 at 23:46

3 Answers 3

3

One thing to check is to make sure that you test connecting via SSH from another computer on a different internet connection. I found with some routers that they reject internal users from connecting via the external IP but allow you to actually connect via the external IP to SSH in.

You can likely try this via a mobile phone (I know androids allow you to access SSH with an application).

Hope this helps ;)

4
  • This hasn't worked for me I'm afraid. The Pi is up, but I can't connect across the internet from another network. Thanks for the suggestion though! Sep 12, 2013 at 23:50
  • Have you port forwarded your router? Sep 13, 2013 at 6:26
  • Yes, port 22 is forwarded for the Pi. Sep 14, 2013 at 11:59
  • your ISP's router might still be in between you 'll need to forward that aswell. Also: some ISP's block port 22
    – Havnar
    Mar 3, 2016 at 12:47
0

Another workaround is to use a simple vpn like Logmein-Hamachi or NeoRouter.

You would need to install the same software on the machine you are connecting from. This would give you a virtual network with the Pi.

NeoRouter can be installed through the RaspberryPi store.

Hamachi requires a free Logmein account. You can connect up to 5 devices to the same virtual network without having to pay for it.

Really quick instructions for installing Hamachi:

$ sudo apt-get install lsb-core
$ sudo wget https://secure.logmein.com/labs/logmein-hamachi_2.1.0.130-1_armhf.deb
$ sudo dpkg -i logmein-hamachi_2.1.0.130-1_armhf.deb
$ sudo hamachi login
$ sudo hamachi attach [email protected]
$ sudo hamachi set-nick "ZZZ"

[email protected] is your logmein email address ZZZ can be almost anything

Install Hamachi on the computer you wish to connect with.

From there, you can create a network and connect the two machines right on Logmein's webpage.

-1

I understand that you want to access your RPi while you are out of your home or office(where the RPi is located).

My question to you is would leave your door open when you go out of our office or home so that anyone can gain access to your home or office ? If the answer is no, then why would you leave the door in your home/office router alone open to anyone in the internet to sneak in ?

Opening up ports in your router/firewall for all inbound traffic is similar to leaving your home or office door unsecured. Though this is easy, cheap and a quick hack solution, it is not a secure approach to solve your remote connectivity problem.

So you might ask, what is the right approach then?

A better alternative and secure solution to port-forwarding is to use a Secure Reverse Proxy tunnel service (that creates SSL/TLS tunnels, preferably) that encrypts the data sent over the internet.

Secondly, any such reverse proxy tunneling service shouldn't create an open-ended public IP and public TCP port for you to access your device from remote locations. If they do so, it is almost similar to the port-forwarding problem. Anyone could still access your RPi from the internet.

So an all-round secure solution for remote device access should have the following:

  1. Reverse proxy tunnels with encryption technology - SSL/TLS
  2. No open public Ports/IP in the internet to access your remote device
  3. Private methods to access your remote devices using authentication tokens/passwords.

There are many such solutions in the market today - AWS IoT, MS Azure IoT, and many others for large scale industries and enterprises. One such solution is SocketXP. SocketXP IoT and RPi Remote SSH solution caters to individual developers, DIY kind of people, small biz. Moreover, it is free for connecting upto 4 RPi devices.

[Disclaimer: I'm the founder of SocketXP and I'm proud of its secure solution.]

Also you can remote SSH into all your RPi devices from the comfort of your web browser from any device - Laptop/Desktop/Tablet/Phone.

I don't want to talk too much about the SocketXP solution here. I just want to give you a direction and guidance on what other secure options and alternatives are available in the market today, than just port forwarding.

Conclusion:

In summary, you don't have to hack your router for port-forwarding every time you step out of your office or home for travel. Port-forwarding was something that was used 10 or 15 years ago when economical and secure reverse proxy solutions weren't available then. But now you have a plenty of options in the market today, just google for secure reverse proxy tunnels.

If you are interested in knowing more about the SocketXP solution read more here:

IoT Remote SSH Access using SocketXP Secure Tunnel

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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