2

I have Raspberry PI 3 which has 4G modem dongle attached to it. It works autonomously and every one in a while has to connect to my server via ssh. This is done by service script either with password or with key authentication which both require password/passphrase to be present in a script or in a file. The problem is that anyone can take out RPi SD card and take that password/passphrase or id_rsa key itself. Are there any secure solutions for this?

4 Answers4

1

The most secure solution is to have SSH keys encrypted with a passphrase and managed with a key agent (e.g. ssh-agent). However,

if your system reboots, it requires human intervention to reload the keys, making it inappropriate for some uses where automatic system recovery is needed. If you find yourself trying to think of ways to automatically load the keys into the agent, then you don't really want to use the agent.

(from the O'Reilly definitive guide to SSH at http://www.snailbook.com/faq/no-passphrase.auto.html)

If you must use a key without a passphrase, the guide says to be sure the key resides on a local disk (the SD card in this case), and you should also use restrictions on the public key such as "from=" and "command=" so that theft of the key (or the SD card on which it resides) can be mitigated.

Mike McManus
  • 1,415
  • 10
  • 17
0

If you want the Pi to be able to turn on and start working automatically then no, you can't secure the key. If it's able to use the key without your input, then the attacker will be able to as well (barring some sort of tamper proof hardware).

I think your best bet is to create an account on your server for the Pi and then restrict it as much as you can, that way if someone gets the key they won't be able to do as much damage before you revoke it.

Better yet, don't use ssh at all. You don't go into much detail, but maybe this is an XY problem. Perhaps you could keep a script with the commands you want to run on the server, and trigger it somehow from the Pi without letting the Pi actually run any commands itself. I've seen, for instance, a cron job using curl to post a secret value to a url to cause the server to run a script. If someone gets this secret value then they can run the script whenever they want, but they won't be able to do anything else with it.

AndrolGenhald
  • 15,436
  • 5
  • 45
  • 50
-1
  1. Encrypt the OS. and
  2. Setup your server to use Public Key Authentication with SSH. I.e. the server has a public key authorized_keys that will only accept connection from matching private key ssh-client. In fact, you should not store the id_rsa that pair with authorized_keys in the server.

AND Lock your RPI3 in a sturdy case.

mootmoot
  • 2,387
  • 10
  • 16
-1

You can setup Full Disk Encryption on the SD card, or at least encrypt your home folder.

With any of those, even if someone takes the SD, the contents will be encrypted.

ThoriumBR
  • 50,648
  • 13
  • 127
  • 142
  • And where do you put the encryption key? – Gilles 'SO- stop being evil' Jul 28 '17 at 14:33
  • 2
    You won't put the encryption anywhere. You type it when you boot. – ThoriumBR Jul 28 '17 at 14:51
  • @ThoriumBR "type it when you boot": what may be solution if device is powered autonomously? – Karolis Milieška Jul 31 '17 at 06:35
  • Yeah, I'm gonna -1 this because of the "It works autonomously" requirement in the question. Sorry. – Mike Ounsworth Sep 26 '17 at 19:36
  • @MikeOunsworth To be fair, there isn't any mention of booting autonomously in the original question. I have a server that requires a password on boot for decryption, but after booting I'd still say it does things autonomously. – AndrolGenhald Sep 26 '17 at 19:40
  • @AndrolGenhald eeeehhhhhh, ok. On a technicality that's true, but the reason most people use a Raspberry Pi is because they want to stick it somewhere that's not easily accessible by a keyboard&monitor. – Mike Ounsworth Sep 26 '17 at 19:47
  • I still think I'd consider it autonomous for the most part. You can use initramfs with dropbear to enter the passphrase over ssh, so it can still be headless. This might not be acceptable to the OP, but I think the question should be edited to rule it out. – AndrolGenhald Sep 26 '17 at 20:06
  • Granted, the answer doesn't go into any of this either, so I'm not really objecting to your downvote, I just think it's incomplete rather than incorrect. – AndrolGenhald Sep 26 '17 at 20:25