1

SSH is enabled on my Pi. I'm trying to use my Pi as a remote control, where I hit a keyboard hotkey on my Pi, and my Pi sends a command to my Mac. For example: if I enter the following in terminal on my Pi, it launches an applescript on my Mac, and my Mac starts playing a New Music playlist in iTunes (I've even set up an ssh key so I don't need to enter my password):

/usr/bin/ssh Me@192.168.1.5 osascript Applescripts/iTunes/NEW_MUSIC.scpt

It works perfectly if I enter the above manually, but I can't figure out how to get it to work with the TriggerHappy daemon. /usr/bin/curl commands work like a charm for me with TriggerHappy. /usr/bin/ssh doesn't work and I can't figure out why.

Example: The following item in TriggerHappy turns on my Philips Hue lights when I type CTRL+1 on my Pi:

KEY_1+KEY_LEFTCTRL  1   /usr/bin/curl --request PUT --data "{\"scene\":\"Zq-7IOofWYEVAx6\"}" http://192.168.1.5/api/myhuelights/groups/0/action/

The above works, so why doesn't this?

KEY_1+KEY_LEFTCTRL  1   /usr/bin/ssh Me@192.168.1.5 osascript Applescripts/iTunes/NEW_MUSIC.scpt

Any idea what I'm doing wrong here?

EDIT: to be clear, I'm trying to figure out why this works on my Pi in terminal:

/usr/bin/ssh Me@192.168.1.5 osascript Applescripts/iTunes/NEW_MUSIC.scpt

...and this works on my Pi using TriggerHappy:

KEY_1+KEY_LEFTCTRL  1   /usr/bin/curl --request PUT --data "{\"scene\":\"Zq-7IOofWYEVAx6\"}" http://192.168.1.5/api/myhuelights/groups/0/action/

...but this doesn't work on my Pi using TriggerHappy:

KEY_1+KEY_LEFTCTRL  1   /usr/bin/ssh Me@192.168.1.5 osascript Applescripts/iTunes/NEW_MUSIC.scpt

I'm working with a new install of Raspbian on a new Raspberry Pi. Like I said, my curl commands work with TriggerHappy, but ssh commands don't. I feel like I'm probably overlooking something simple here. I hope?

  • When you run from the terminal you are logged in as"me". What user runs TriggerHappy? – PaulF8080 Apr 19 '17 at 8:09
  • In the end, this turned out to be the problem. I didn't realize triggerhappy ran as user Nobody. I switched triggerhappy's user to root & relaunched it, and the problem was instantly solved. – 2oh1 Apr 19 '17 at 17:34
  • I had the same setup. Same user on both computers and SSH lets you send to yourself without an SSH password. It trusts you login password. – PaulF8080 Apr 19 '17 at 18:54
1

You type ssh Me@192.168.1.5 and successfully log in to your Mac, but you didn't say how ssh gets access to the private key you need to log in. Typically it will either prompt you for the passphrase for your keyfile (which file it will then decrypt and load) or it will use a key that you've previously loaded into an agent.

The problem you're running into is that the TriggerHappy daemon, thd, is not running as you but is running as user nobody. Thus it doesn't have your environment (for example, $HOME is different) and, even if it could find the file with your key in it, it can't type a passphrase.

Fixing this without breaking SSH security isn't trivial. To do it properly you need to do the following:

1. Generate a new SSH private key that will be used only by user nobody on this particular host (your Raspberry Pi) and store it in a file without a passphrase:

ssh-keygen -b 2048 -C thd-pi-170416 -f thd-pi-170416.priv </dev/null

(Giving /dev/null as stdin avoids asking for a passphrase to encrypt the key, and you'll note I put the date in the comment to make the key easier to identify.) Note that this key isn't tied to any particular user; it's just a key that can be used with the -i option to ssh by any user that can read that file.

You'll also need the public key, which you can get with

ssh-keygen -y -f thd-pi-170416.priv

When you later insert it into authorized_keys files it's helpful to append a space and your key comment (from above) to the line to help identify the key more easily.

Put the private key file somewhere for thd to read; make sure that this file is readable by user nobody but not by anybody else, and ensure that nobody but root can write to any of the directories leading up to that file. You'll pass this key to ssh with the -i command-line option.

2. Edit the $HOME/.ssh/authorized_keys file on your Mac to add this key, but restrict what can be done with the key with a configuration similar to this:

no-port-forwarding,no-X11-forwarding,no-pty,from="192.168.1.4",command="osascript Applescripts/iTunes/NEW_MUSIC.scpt" 

This does the following:

  • Disables port and X11 forwarding for reasons I won't get into here. (You're not using either of these features and aren't likely to in this application.)
  • Disables pty allocation because you're expecting logins only from automated programs that don't need terminal handling.
  • Restricts logins to come from only 192.168.1.4; you should replace this with the address of your Pi.
  • Ignores whatever's specified on the ssh command line and runs only the command given by command=.

All of these things work together to minimize the damage that can be done if someone gets hold of that key. Remember that, because it's an automated program using that key file there's no passphrase on it, so anybody who can somehow manage to read that file then has that key and can attempt to use it for whatever they like.

If you need run two or three different commands you could make two or three different keys, but this would soon become tedious. Better is to write a small program that reads its standard input and very carefuly extracts information about what to run from that. For example, it might take commands such as play foo.mp3, being careful to make sure that there's nothing weird in the filename it's parsing and using. (You certainly don't want to write this in Bash, and you probably want to do things such as use only files from a specific directory and not allow slashes so people can't "sneak out" with a path like ../.ssh/id_rsa, play your (personal) private key over the radio, and then use clever tricks to guess your private key from that.)

  • Let us continue this discussion in chat. – Curt J. Sampson Apr 17 '17 at 2:31
  • Following the above advice, step 1, I generated the new ssh key and stored it at /tmp/sshkeyfornobody since user nobody has access to the /tmp folder. ...if I chown that file for my user, I can enter the ssh command in terminal and it works without a password. Thus, I should be able to chown it to user nobody and it should work for user nobody without a password. But after I chown it to user nobody, in triggerhappy the ssh command fails. The issue here is user nobody. How do I solve it? – 2oh1 Apr 18 '17 at 19:39
  • I'm not convinced the restrictions on user nobody still allow nobody to ssh, and since I can't log in as user nobody, I can't test what nobody can or can't do. – 2oh1 Apr 18 '17 at 19:40
  • For others here, the issue is not user nobody, user nobody can ssh, and you can test what user nobody can do. I just tried it out myself and sshed into my own host from user nobody. For @2oh1, you're incorrect, but it's clear from our chat session that I can't help you with that. I suggest you put up a question about "ssh as nobody" on Server Fault (this is no longer a Pi question) and include error messages (rather than saying "it didn't work") if you wish to continue. – Curt J. Sampson Apr 18 '17 at 23:05
  • But did you ssh using TriggerHappy? Also, the fact that you could log in to Nobody shows there's more going on here than meets the eye, as I can log in to my user, or as root, but not as nobody. Since you obviously understand these things, I'm hoping you will help. – 2oh1 Apr 18 '17 at 23:51
1

I answered my own question. Change the triggerhappy default user to pi or root. On the Pi, it's at:

/etc/default/triggerhappy

Simply uncomment the user option to change it from nobody to root, as explained in the file:

# The Triggerhappy daemon (thd) drops its root privileges after
# startup and becomes "nobody". If you want it to retain its root
# status (e.g. to run commands only accessible to the system user),
# uncomment the following line or specifiy the user option yourself:
#
# DAEMON_OPTS="--user root"

Uncomment that last line & relaunch triggerhappy. It's as simple as that. This may not serve everyone's use, but in my case it's perfect because my Pi has only one purpose: It serves as a control, connecting my IoT stuff to a universal remote using a usb Flirc IR receiver. So, I press a button on my universal remote, and Flirc tells my Pi to do keystroke Control+1, which triggerhappy then turns into a command.

  • Keep in mind that you appear to have unencrypted SSH private keys sitting around on your Pi's filesystem. Anybody gets hold of those and, if you're not careful, they have a lot of access to your Mac. (They could, e.g., install trojans and the like on it.) That's why I was so careful about access in my answer above. – Curt J. Sampson Apr 19 '17 at 7:09
  • Curt, you assured me running triggerhappy under root would NOT solve my problem, but it did. I quote: "that won't fix your problem, but I encourage you to spend the time doing it, observe that it doesn't fix your problem, and then maybe you'll drop the "user nobody" fixation" ...And yet, the moment I switched triggerhappy to root and relaunched it, my problem was solved. I'm going to do security housekeeping next, but I had to get ssh with triggerhappy working first. And I have. My guess is that you're not familiar with Raspbian, so you had no way of knowing its limitations of user Nobody. – 2oh1 Apr 19 '17 at 7:27
  • As I said, I had no problem getting SSH working just fine as user nobody. Changing something to run as root is not the best way to solve file permission issues, nor is it what added the -i option to your command line. – Curt J. Sampson Apr 19 '17 at 8:39
  • "As I said, I had no problem getting SSH working just fine as user nobody" The fact that you could log in as Nobody in the first place showed that your setup has privileges the current build does not. I already pointed this out. You're trying to create issues where there's no need. My Pi has one simple job: a trigger for an entertainment center's universal remote control. Changing the user of triggerhappy instantly solved the problem I came here for help with, though you assured me multiple times (quite rudely, I might add) that it would not. Problem solved. – 2oh1 Apr 19 '17 at 17:32
  • I have checked again on the current build, and sudo -u nobody -s still gets me a shell command line running as user nobody. – Curt J. Sampson Apr 19 '17 at 21:29
0

Not sure if I understand correctly your question, but it seems that you first need to enable SSH on you Raspberry Pi. Raspbian has the SSH server disabled by default.

Raspberry Pi has a great documentation about this specific issue. Follow it here: https://www.raspberrypi.org/documentation/remote-access/ssh/

Cheers,

  • SSH is enabled on the Pi. I'm able to SSH on the Pi using terminal, but I'm not able to have TriggerHappy execute the SSH on its own. – 2oh1 Apr 16 '17 at 17:51
  • sshd does not need to be enabled on the Pi; he's using the ssh client (which is "enabled" merely by running it) to try to log in to the Mac, which does appear to have sshd running on it. – Curt J. Sampson Apr 16 '17 at 19:37
  • "he's using the ssh client (which is "enabled" merely by running it)" Not correct. MagdalenaJadach was right in saying that, on Raspbian, ssh has indeed been disabled by default. It needs to be enabled, either through the raspi-config, or by adding an ssh file (even if it's blank) in the boot directory. But I'd already done that. – 2oh1 Apr 19 '17 at 6:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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