Passwordless SCP file transfers between RaspberryPi and MacBook Pro.

Take the .pub file from the scp source system and put it in the .ssh/authorized_keys file of the destination account on the destination system.

The permissions on the source and destination account's home directory and .ssh files MUST be set correctly

Home directory drwxr-xr-x (or more restrictive)

.ssh directory drwx------

.ssh/id_rsa (or .ssh/id_des) -rw-------

.ssh/authorized_keys -rw-r--r-- (or more restrictive)

See "man ssh" for more details on permissions

If you are having connection problems look at destination system's sshd log information. On the Mac it would be in /var/log/system.log. I do NOT know what the log file would be on the Raspberry PI

Also on the source system us ssh -v -v -v destination.system.address

Between the sshd log and the ssh -v -v -v output you should be able to identify where ssh was having problems.

And yes, ssh is the foundation up which scp and sftp are built.

Use:

ssh -v -v -v 2>testtext1

That is to say, 2> filename so that you are redirecting standard error (file descriptor 2), not standard out (file descriptor 1).

The ssh -v -v -v output goes to standard error

And look at the sshd (destination systems ssh daemon's log file output). If going from the Raspberry Pi to the Mac, then look at the Mac's /var/log/system.log file.

If going from the Mac to the Raspberry Pi, then ASSUMING you are running a flavor of Linux, I would start with /var/log/secure, but if not in there, look at /var/log/messages. If that does not turn up anything, then "sudo grep sshd /var/log/* "

Anyway, the sshd log entries can often times tell you why the destination system refused your connection request.

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /home/mick_f/.ssh/id_rsa

debug3: send_pubkey_test

debug2: we sent a publickey packet, wait for reply

debug1: Authentications that can continue: publickey,keyboard-interactive

debug1: Trying private key: /home/mick_f/.ssh/id_dsa

debug3: no such identity: /home/mick_f/.ssh/id_dsa

debug1: Trying private key: /home/mick_f/.ssh/id_ecdsa

debug3: no such identity: /home/mick_f/.ssh/id_ecdsa

debug2: we did not send a packet, disable method

debug3: authmethod_lookup keyboard-interactive

debug3: remaining preferred: password

This is basically saying, it tried your .ssh/id_rsa and the server did not accept it.

Why the server did not accept it is something that should be in the server's logs. When ssh fails to connect to my Mac, my Mac's /var/log/system.log file contains the sshd errors

From your server logs, this is most likely what the Mac does not like

2015-06-13 12:22:36 +0100 sshd[803]: error: PAM: unknown user for illegal user home/michaelfarmer/.ssh from 10.0.1.11 via 10.0.1.13

1st, is your Mac short username 'michaelfarmer' ??

2nd, on the Mac your home directory should be /Users/YourUserName, NOT /home/... I'm assuming that /home/username is the default home directory path when username cannot be found in whatever file Mac OS X uses to keep the user account information. Since it could not find 'michaelfarmer' it defaulted to /home/... (and after all ssh is a Unix utility and /home/... if frequently used on other Unix systems, so I can see sshd defaulting to /home when it cannot find a user record).

NOTE: If 'michaelfarmer' is your Mac username, exact spelling counts.

echo $USER

should tell you the exact spelling with exact upper/lowercase for your Mac account.

Anyway, it appears your problem has something to do with your username send from the Pi to your Mac and what your Mac thinks is your username.