Safe SSH access to Pi over internet


24 posts
by precious_pony » Sat Jun 23, 2012 12:47 pm
Hi,

I set up SSH access as per instructions in the boot partition readme files, and I can gain SSH access successfully to my PI from other computers on my LAN.

I am quite familiar with routers and forwarding rules, so this is not a question regarding port forwarding.

I would like to ask what is the correct way to allow my Pi to be accessed via SSH on the internet without opening up security holes (such as weak password) or without allowing snooping of passwords via a man in the middle attack.

Is a strong password sufficient protection enough to prevent unauthorized access or must I use some kind of public/private key pair? I prefer the strong password approach actually, as I have no idea how to set up ssh keys, and I can happily store strong passwords using the PasswordSafe application which I use for all my online passwords.

In addition, if exposing my Pi to the internet, are there any services that run on the Debian Squeeze distro that I should shut down (such as ftp)?

Thanks,

PP
Posts: 28
Joined: Tue May 22, 2012 11:09 pm
by bob_binz » Sat Jun 23, 2012 5:59 pm
There's some useful info on this thread: viewtopic.php?f=36&t=7122 Have a look and see if it helps you any
User avatar
Posts: 367
Joined: Thu Feb 02, 2012 7:58 pm
Location: Stockport, UK
by ksangeelee » Sat Jun 23, 2012 6:55 pm
precious_pony wrote:I would like to ask what is the correct way to allow my Pi to be accessed via SSH on the internet without opening up security holes (such as weak password) or without allowing snooping of passwords via a man in the middle attack.

Is a strong password sufficient protection enough to prevent unauthorized access or must I use some kind of public/private key pair? I prefer the strong password approach actually, as I have no idea how to set up ssh keys, and I can happily store strong passwords using the PasswordSafe application which I use for all my online passwords.

In addition, if exposing my Pi to the internet, are there any services that run on the Debian Squeeze distro that I should shut down (such as ftp)?
PP


I'd almost always recommend the exclusive use of keys over passwords, if only to prevent a possible deluge of brute force attacks (with a strong password, there's little chance of success, but that won't stop a bot from winding up your network resources and bandwidth). If the server's configured to deny password logins, the bot will just give up and move on.

To prevent passwords, edit /etc/ssh/sshd_config and ensure the directive 'PasswordAuthentication no' is present (it defaults to yes).

If you're using a Linux client to connect from, then just use (from your client machine) 'ssh-keygen' then 'ssh-copy-id myserver.wherever.co.uk' (or ssh-copy-id myuser@myserver.wherever.co.uk if your userids differ between machines). This will create an entry in .ssh/authorized_keys (on your Pi) containing the public part of the key that you just created.

If you're using a GUI client, then you'll need to check the docs to see how this is done (e.g. PuTTYGen for the PuTTY client). You'll likely have to create the text file .ssh/authorized_keys on your Pi's account and paste the public key into it. Watch a) that the permissions of authorized_keys is 600, and b) that you spell authorized the wrong way(! - e.g. it's not British spelling).

And, of course, don't disable password logins until you have success with the client connecting using its key-pair.

It can get a bit confusing at first, but remember that they key belongs to your client and it's only the presence of the public key portion in the server's authorized_keys that grants you your login. However, it's all fairly standard stuff, so I expect there'll be lots of guides on the net that will give you more details.
Posts: 193
Joined: Sun Dec 25, 2011 5:25 pm
Location: Edinburgh, UK
by nidO » Sat Jun 23, 2012 7:50 pm
precious_pony wrote:I would like to ask what is the correct way to allow my Pi to be accessed via SSH on the internet without opening up security holes (such as weak password) or without allowing snooping of passwords via a man in the middle attack.


Just to clarify on this particular point (ksangeelee's response above covers switching to key pairs which is recommended as said purely to stop your pi constantly being hammered by brute-forces, even though a strong enough password will keep your pi safe) you dont have to worry about man in the middle attacks or similar password snooping, SSH is by its nature encrypted from end to end so your login details are not snoopable.
Posts: 22
Joined: Sun Jun 03, 2012 3:58 pm
by precious_pony » Sun Jun 24, 2012 12:17 am
I've followed the instructions in this thread and I've managed to get a private/public key pair running, disabled password authentication (after testing the generated keys), and have set up forwarding rules on my router (changed to a high port up from port 22 to reduce noise from port scanners).

Seems to be working fine. Now I just need to get a dynamic dns service running.

Any tips?
Posts: 28
Joined: Tue May 22, 2012 11:09 pm
by HansH » Sun Jun 24, 2012 9:58 am
You should do:

PasswordAuthentication no
KbdInteractive no

both should be disabled in the sshd_config
This way you will never get a prompt if the sshkey fails

To further protect your system, use port knocking.
for instance use knockd see: http://www.zeroflux.org/projects/knock
Posts: 212
Joined: Mon Sep 05, 2011 7:49 am
by AndrewS » Sun Jun 24, 2012 11:36 am
User avatar
Posts: 2193
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by penguintutor » Mon Jun 25, 2012 2:29 pm
It depends upon your level of paranoia and the added inconvenience.

Keys are more secure, but password over ssh is probably secure enough, particularly if you ever want to login from a different computer eg. perhaps from a mobile phone or tablet that doesn't have the key installed.

Communication over ssh is encrypted, so it's not possible to snoop on the network and get the password that way. The most important thing is to choose a secure password.

If you want to reduce the number of login attempts from opportunist script kiddies then you could change the ssh port. This won't make it any more secure from a determined attack against your machine, but it will mean that many script kiddy scripts won't bother you.
User avatar
Posts: 325
Joined: Tue May 08, 2012 9:11 am
Location: UK
by AndrewS » Mon Jun 25, 2012 2:43 pm
Okay, here's a stupid question ;)
Is it possible to setup sshd to allow password or key login from the local LAN, but only allow key login from the internet? Or could you run two instances of sshd, each listening on a different port?
User avatar
Posts: 2193
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by hayesey » Mon Jun 25, 2012 3:10 pm
you want to disable root logins from sshd_config too. Users should login using their normal usernames and then use "sudo" to get root access if they require it and it's been authorised for them.

ssh uses system keys too so you get a warning message if you try to login to a machine you've logged into before and it's key has changed (which can be a sign on man-in-the-middle attack).

I would also recommend learning how to use keys and turning off password authentication altogether. You can also generate keys that require a password to use which is useful on portable devices such as laptops or tablets where someone physically stealing the device is a risk and then that gives them your private key.

It depends on how important the contents of the server are against how much convenience you are will to sacrifice. If you want to leave password auth turned on then I'd strongly recommend using some kind of log monitoring script to block the IPs of potential attackers. If you leave an ssh server on the public Internet, sometimes even just for hours, it'll start getting brute-force attackers attempting to guess username/password combinations. At best this is an inconvenience and will use up your bandwidth, at worst they'll break in! I like to use denyhosts which I notice is packaged on Raspbian (and will be in the normal armel Debian port too).
User avatar
Posts: 76
Joined: Mon Nov 28, 2011 12:46 pm
Location: Manchester, England
by penguintutor » Tue Jun 26, 2012 10:25 am
Without wanting to tempt fate I have had a server on the Internet for several years with password authentication. It has in the past being cracked, but that was due to an unpatched vulnerability in Wordpress (which no longer runs on that computer anyway), nobody has ever guessed the password or got in via ssh. It does get a number of failed login attempts fairly regularly, but they are trying default username / password combinations.

The number of possible permutations for a 7 character password which has a mix of upper case, lower case digits and special character is huge. If you change to a non standard username (eg. don't use pi and disable root) then the number of permutations to get the username correct and the password correct is even bigger. Increase the number of digits in the password and it gets even bigger.

Connecting over the network is not the same being able to run a cracking tool against an encrypted password. The number of attempts are logging in is restricted by the time taken to attempt authentication so it would take many years (thousands perhaps?) to go through that number of permutations.

Of course if you use a well known username and a trivial password (eg. dictionary word) then the odds are much, much lower, which is why a complex password is a must.


I don't believe you can change the ssh server to require different authentication depending upon the address but there are other ways of achieving a similar or better amount of additional security.

One option is to run multiple instances of sshd using a different configuration file. The -f option allows you to select a different config file and this can be configured within an additional /etc/init.d/ file.

Another alternative may be to do it using PAM, or use PAM to add two-stage authentication (although PAM is an entire subject in it's own right and can be complex to configure).


Other ways of making it more secure is to run an Intrusion Detection System, or you could create your own simple version using temporary login block based on IP address of failed attempts. eg. expanding on hayesey suggestion of logging failed logins, but then using those to temporarily block that IP address for some time. I did something similar to protect a web application I wrote when it was suffering from a DOS attack. Once an IP address had connected so many times in a specific time frame they were blocked from accessing the site for a few minutes.

Or another option is to require two stage authentication using two different methods. Eg. One system I login to requires me to first login through a secure web based application, which then opens up the firewall to allow me to login using ssh.

These would need some additional software or scripts to put it all together.

Each option (including using key based authentication) adds additional setup, inconvenience and/or cost, but in return adds additional security.


Key based authentication is a good way of applying additional security, but it isn't for everyone. It requires you to copy the key(s) eg. if adding an additional client after disabling password login then you need to transfer that clients public key (perhaps by USB memory stick), or to temporarily turn password logins back on. I have used it in the past and in particularly it was useful to provide single-sign on when I was administering lots of different Unix (not all were Linux) computers. But because of the number of different computers I access with (including Raspberry Pi that I have reimaged several times whilst trying different things) it would add additional inconvenience for my home server.
User avatar
Posts: 325
Joined: Tue May 08, 2012 9:11 am
Location: UK
by zardoz99 » Tue Jun 26, 2012 10:36 am
If you are truly paranoid, I would recommend the use of a Yubikey and the pam_yubico authentication module.
These are based on an authenticated "one time password" function that will prevent any possibility of a password replay.

Details from http://www.yubico.com/yubikey

I am using this method on most of my external facing servers.

Z.
User avatar
Posts: 137
Joined: Fri Jan 13, 2012 2:25 pm
by rurwin » Tue Jun 26, 2012 11:03 am
Any time you are considering strong passwords, you should read and understand this: XKCD "correct horse battery staple"

A strong password is a random collection of letters and digits with maybe a few punctuation characters (many web sites don't like punctuation in passwords). A word with digits swapped out or added in is not the same thing, and although the web page may say it is strong (because the web page's script is dumb,) it is in fact weak.

Any time you have a strong password, unless you are some kind of super-human, you will have to write it down. The place you write it is the weak point, but sometimes you don't mind. -- I don't care if anyone in the house knows my password, and if someone breaks in, my RaspPi password will be the least of my worries. On the other hand, a weak password is actually better if you don't trust your house-mates, so long as they are not going to create a bot to crack it, because you don't need to write it down.

A public-private key is more trouble again, and you have to write it down on some sort of storage device, but it is extremely secure.
User avatar
Moderator
Moderator
Posts: 2890
Joined: Mon Jan 09, 2012 3:16 pm
by AndrewS » Tue Jun 26, 2012 12:36 pm
Starting to go a bit OffTopic... on the subject of remembering passwords, I use KeePass (the 1.x version which is compatible with KeePassX on Linux), so that I still have different strong passwords for each service/site that I use, but I only have one strong password that I need to remember. :D
And I obviously make regular backups of the KeePass database! (as well as keeping a copy in Dropbox)
User avatar
Posts: 2193
Joined: Sun Apr 22, 2012 4:50 pm
Location: Cambridge, UK
by wh1p » Thu Jul 05, 2012 12:55 am
I only started playing with Linux a few months ago and recently received my Pi but i ws very interested in securing the SSH on my Pi and i found a set of videos by the HAK5 group on youtube, this video goes in-depth into how to setup and secure your ssh server:

http://www.youtube.com/watch?v=yP0asZEIwN8&feature=plcp

I hope this helps, i am only advising this video as i found it very useful.
Posts: 29
Joined: Tue Jul 03, 2012 11:00 pm
Location: South East UK
by SirLagz » Thu Jul 05, 2012 2:39 am
If you know where you'll be accessing the Pi from, i.e. always from work, then firewall off anything except your work IP address. Then have a nice strong password.
That's what I have setup at home for my ssh server.
My Blog - http://www.sirlagz.net
Visit my blog for Tips, Tricks, Guides and More !
WiFi Issues ? Have a look at this post ! http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=44044
Posts: 1704
Joined: Mon Feb 20, 2012 8:53 am
Location: Perth, Australia
by wheresmypi » Fri Jul 06, 2012 7:15 pm
If you want stop the brute force attacks I found out that by adding a banner before login you also seem to drive them away :)

Simple add

banner /etc/ssh/textfilewithbannertext


to the sshd_config file
Posts: 5
Joined: Fri Jul 06, 2012 7:07 am
by terrycarlin » Tue Jul 10, 2012 3:31 am
I use Comcast as my internet provider. When I opened up ssh to my RPi, it started getting hammered by scanners within minutes. Nothing above will stop this. It will help keep brut force attacks from succeeding, but it won't stop them from trying. After a day or so my RPi would give up the ghost and die from being hit so much. Closed that port in my firewall and my RPi has been up for a couple of weeks with no worries. Using a different port for ssh would take the scanners more than a couple of minutes to figure that one out. If anyone has any ideas about how to stop those scanners, please share.
If it ain't broke, take it apart and see how it works.
User avatar
Posts: 70
Joined: Thu Jun 14, 2012 10:42 pm
by purg » Wed Jul 11, 2012 11:26 am
try adding the following iptable rules to help reduce scripted scan replies. This was taken from a different host so might need tweaking for PI

Code: Select all
# attemp (being the best word for it) to block stealth scans
IPTABLES -A INPUT -p tcp --tcp-flags SYN,ACK SYN,ACK -m state --state NEW -j DROP
IPTABLES -A INPUT -p tcp --tcp-flags ALL NONE -j DROP

IPTABLES -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
IPTABLES -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
IPTABLES -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP

IPTABLES -A INPUT -p tcp --tcp-flags FIN,RST FIN,RST -j DROP
IPTABLES -A INPUT -p tcp --tcp-flags ACK,FIN FIN -j DROP
IPTABLES -A INPUT -p tcp --tcp-flags ACK,PSH PSH -j DROP
IPTABLES -A INPUT -p tcp --tcp-flags ACK,URG URG -j DROP

# drop fast connects most likely bot
IPTABLES -A INPUT -p tcp -i eth0 -m state --state NEW -m recent --set
IPTABLES -A INPUT -p tcp -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 10 -j DROP
IPTABLES -A FORWARD -p tcp -i eth0 -m state --state NEW -m recent --set
IPTABLES -A FORWARD -p tcp -i eth0 -m state --state NEW -m recent --update --seconds 30 --hitcount 10 -j DROP



might be worth readiing too http://www.debian-administration.org/articles/187
Posts: 21
Joined: Fri Jun 08, 2012 8:07 pm
by hilaryyy » Fri Jul 13, 2012 10:31 pm
Software firewall. If you're using the fedora image, iptables is wonderful. i'm not sure what firewall debian uses currently (ipfw, i believe) or if it's been built for ARM architectures yet, but it should have something comparable.

Stop every service you don't need, set the firewall's default policy to drop incoming connections by port, and accept only on the ports you expect to be using. You could also filter connections by IP address if you have a static connection or know the range from your office, etc.

As far as securing SSH itself, I strongly recommend getting familiar with keys and implementing them. Change the listening port to a higher non-standard number. Create a wheel user account/group, and disable root logins.
Posts: 7
Joined: Fri Jul 13, 2012 1:48 am
by alexeames » Mon Jul 30, 2012 8:29 pm
ksangeelee wrote:If you're using a GUI client, then you'll need to check the docs to see how this is done (e.g. PuTTYGen for the PuTTY client). You'll likely have to create the text file .ssh/authorized_keys on your Pi's account and paste the public key into it. Watch a) that the permissions of authorized_keys is 600, and b) that you spell authorized the wrong way(! - e.g. it's not British spelling).


Also worth noting that the file ownership seems to matter as well. I created and exported a public key (in tunnelier in windows), then created /home/pi/.ssh/authorized keys with sudo nano, and cut and paste by ssh but that gave ownership of the file to root. :cry: Took me quite a long time to work out why it didn't work. It seems that pi needs to be the owner of that file, which I guess makes sense. :lol:
Well hopefully I'll remember that one.
My Pi uses 2 watts - what what? ---- HiRes early production Pi photos RS Front Back | Farnell Front Back
User avatar
Posts: 2018
Joined: Sat Mar 03, 2012 11:57 am
Location: UK
by thomasamberg » Thu May 02, 2013 10:05 am
Hi, I'm probably a bit late to the party, but an alternative way to safely access your Raspi with SSH from anywhere is Yaler, our relay infrastructure. Please see https://yaler.net/raspi for details. Kind regards, Thomas
Posts: 4
Joined: Thu May 02, 2013 10:01 am
by smartpatrol » Tue May 07, 2013 8:16 pm
What i have done is limit root access to private network and only allow my username login from outside my network in the sshd_config. I also extensively use iptables to block all ip addresses from countries that have no business accessing my system created from https://www.countryipblocks.net for good measure i have also added a python script that parses the output of lastb -id for repeated login attempts and adds the ip address to a drop rule fail2ban just wasn't cutting the mustard.
Posts: 23
Joined: Thu Oct 18, 2012 2:28 am
by edwinsage » Sat May 11, 2013 1:13 am
precious_pony wrote:I've followed the instructions in this thread and I've managed to get a private/public key pair running, disabled password authentication (after testing the generated keys), and have set up forwarding rules on my router (changed to a high port up from port 22 to reduce noise from port scanners).

Seems to be working fine. Now I just need to get a dynamic dns service running.

Any tips?


Did no one really answer this?

I use dyndns, though I can't seem to find where they offer the free service that I use anymore. I've been using it for some years mostly for personal webhosting.
http://dyn.com/dns/
Otherwise if you're looking for free, this seems authentic enough: http://freedns.afraid.org/
The Art of Unix Programming: http://faqs.org/docs/artu/
User avatar
Posts: 11
Joined: Thu Dec 06, 2012 2:03 am
Location: Kalamazoo