Take the 2-minute tour ×
Raspberry Pi Stack Exchange is a question and answer site for users and developers of hardware and software for Raspberry Pi. It's 100% free, no registration required.

I'm rather new at Debian so please forgive me if this is a stupid question. I have 2 raspberry pis and I'm trying to get them to work together as a proof of concept. I would like to get them to work together and share computing power. Simon Cox has published some instructions from University of Southampton that I have been following, but I've hit a wall.

When I attempt to run a simple C program to test I get the following message.

Permission denied, please try again.
Permission denied, please try again.
Permission denied (publickey,password) .

Now I'm sure the answer to this is just something I've overlooked or just plain don't understand.

Thank you for your time and I'm sure you'll need more information to help but I don't know what.

Below are the commands I used to generate the key and copy it over to the 2nd Pi.

ssh-keygen -t rsa -C "raspberrypi@raspberrypi"
cat ~/.ssh/id_rsa.pub | ssh pi@192.168.1.2 "mkdir .ssh;cat >> .ssh/authorized_keys"

I attempted to use the below command to authenticate the first time.

ssh-copy-id pi@192.168.1.2

This asked for the passphrase like expected but when I go back to the original C Program I get the Permission denied messages again.

From there I ran the command to generate the key again but this time left it blank, with no security it worked. Thinking it was resolved I recreated the key again with a passphrase. Now when I attempt to run a Python program it asks for the passphrase and then runs as expected. C Programs give permission denied.

share|improve this question
    
There are no stupid questions, but there are more and less stupid ways of asking a question. I recommend you at least look at and think about: catb.org/esr/faqs/smart-questions.html Then consider the difference between relevent and irrelevent details, and read your own question over, thinking about what someone who might potentially be willing and able to answer sees. It sounds like a simple sshd config issue, but it is not clear...perhaps Simon Cox can tell us? ;| –  goldilocks Feb 20 '13 at 20:35
    
I have sent an email to Simon Cox but do not know him personally nor his availability. I will attempt to add more detail to my original post. –  Mark Feb 20 '13 at 20:44
    
I'm sorry, I was being a bit flippant with the Mr. Cox bit (don't email him for this question, btw). My point was, the only part of that which describes your actual problem is "When I attempt to run a simple command I get the following message", + the copy paste error. So do you mean, this happens after you have successfully logged in via ssh? Or when you try? If it is the latter (my guess), exactly how are you trying to log in? If it is the former, who are you logged in as? Does this happen with any command? Details! –  goldilocks Feb 20 '13 at 20:51
add comment

1 Answer 1

up vote 1 down vote accepted

Okay, I had a look at the instructions you are following. First, an observation: the assertion that not using a passphrase for an ssh-key is "not such good security" is generally false, as long as the private part of the key is safe (note the private half is never transmitted anywhere, due to the magic of public/private key pairs; it is just used by the local ssh process). Using a passphrase does not increase the security of the exchange at all, a key-pair with a passphrase is 100% exactly the same as one without, in terms of the ssh connection. The passphrase just makes the private key harder to use, should someone acquire it (eg, if they have physical access to your box, or have hacked into it somehow).

In the context of a number of pi's physically linked together, anyone who gains access to one will gain access to the others, so IMO in this context using a passphrase for keys used to log from one to the other is a tad silly. Nuff said. My point is don't be too concerned at this point about whether or not you are using a passphrase, you can change this later.

Also (this may simplify your life at some point), if you are using a passphrase, you can use something called ssh-agent such that you do not have to enter it all the time locally if you keep logging in and out of somewhere with the same key.

Anywho, stepping thru the superpi instructions: you've added your key to the other one as per #33. Then, as per #34 you have verified the key is there. There might be a complication here since you said you re-generated the key multiple times, and cat >> .ssh/authorized_keys will add to authorized_keys everytime. This is sort of ok, except it makes it hard to tell if the last key you added, actually got added (which once you've added one it will be prompting you for a passphrase from an existing key if you use that method to add another -- which make it sort of not ok). If at all possible, I recommend you:

  1. Get rid of all the keys you've generated so far. As in remove everything in ~/.ssh on both pi's.
  2. Create a new key-pair (with or w/o passphrase) on the first pi.
  3. Copy the id_rsa.pub half and rename the copy "authorized_keys" (no suffix), and move that into ~/.ssh/ on the other pi using a means that you are certain of, eg, by putting it right on the SD card. You could use the superpi instructions recommended method, but do not do keep doing it over and over. Which is probably why it is just easier to copy it onto the card or use some other such direct method, since you don't have 63 more pi's to do anyway ;).

That's it for the ssh keys. You can test this by trying to ssh in to the other pi:

ssh pi@192.168.1.162

Nothing else. There should be a little blurb including "Your last login was...". You are now at a login prompt on the other pi. It will look the same otherwise since the filesystem images are identical. Type exit to log out.

WRT step #36, which I presume is where you are having a problem, make sure you aren't still logged into the other one and try it. If you still have the same problem -- well, ditch the passphrase if it helps. It should not make any difference, although it could be that the python program you are referring to is actually not using the second pi at all (do you have a way to tell?) -- that would be confusing...

share|improve this answer
    
thank you for your patience, the program is running on the local pi. I am logged into is and execute it there. Here is the website address of the instructions I am following. The problems I am experiencing started about step 33. southampton.ac.uk/~sjc/raspberrypi/… –  Mark Feb 20 '13 at 21:25
    
@Mark: okay! hopefully this helps, and good luck. –  goldilocks Feb 20 '13 at 22:32
    
WOW, thank you. I hadn't thought about the passphrase that way and I see you're point. More trouble then it's worth. So I'll redo them as blank. As a side note when I was regenerating and copying them back over I was deleting them before so I could verify they had been copied. I've changed the hostname of the 2nd Pi just to avoid that confusion so I can see they are both responding. Thanks again for your patience and help. My first pi is currently tied up so I will try it first thing in the morning and let you know how it worked. –  Mark Feb 20 '13 at 22:42
    
Also thank you for the above suggested reading. :-) –  Mark Feb 20 '13 at 22:42
    
Cool. Beware, authorized_keys, not authorized-keys. And that file needs to be chmod 600 authorized_keys (ie, rw owner only; ssh doesn't like it any other way) –  goldilocks Feb 21 '13 at 0:08
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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