ssh problem - Permission denied (publickey)
 

I am setting an automatic backup up from my OpenSuse 13.2 linux desktop to my Raspberry Pi2 (with a large external drive) running raspbian (updated). I use static IP addresses. My desktop is 192.169.1.1 and the Pi is 192.168.1.20 .

Part of the configuration is to enable automatic ssh login to the pi for the backup user (named "bu"). I followed the directions, and it worked.
Then, I remembered that I had never changed the Pi's root password from the default value. So, I changed the root password. Now when I try to ssh to the Pi like this:
$ssh bu@192.168.1.20
Permission denied (publickey)
$

I also have my web server at 192.168.1.1 and I can ssh into that server just fine with:
$ssh mark@192.168.1.1
mark@web:~$
(no errors)

2 things:
#1: Why am I now getting this error? What does the root login have to do with ssh as a user?

#2: What do I have to do in order to get the ssh login to work?

Many thanks,

Mark

what happens on
?

One way is to create a rsa key for the bu user and use that.
You will need to get the key's pub contents into /home/bu/.ssh/authorized_keys on 192.168.1.20

I tried:
In other words, same error. I did have this working before I changed the root password on "192.168 1.20".

Thanks,
Mark

Remember that permissions on the .ssh and some of its contents must be "just so," or they will be ignored.

Also be certain that you have an SSH-agent running.

We might need some additional information as to what you actually changed.

There isn't a default root password. The default user (pi) has sudo privileges and you can add a root password via sudo. How did you add the bu user? Did you make any changes to the sshd_conf file? What other changes did you make to the Pi?

As suggested check .ssh directory and private file permissions on the client. Check the .ssh directory and public key file permissions on the Pi.

try:
ssh -vvv bu@192.168.1.20

This will add some debug messages that might provide a clue.

Here is the very verbose output of:
$ssh -vvv bu@192.168.1.20

You'll need to explicitly use an ssh key, eg:
but without the bu_key.pub contents in /home/bu/.ssh/authorized_keys on 192.168.1.20 it will never work.

And now boys and girls, we now know why we never disco from a server until ssh is thoroughly vetted
for use with ssh keys.

Not necessary to explicitly specify a key with the -i option. The default key files are ~/.ssh/id.rsa, ~/.ssh/id.dsa. The SuSE box appears to be sending the id.rsa key but the pi is not responding.

As suggested did you copy the public key to the authorized_keys file on the pi and does it have the correct permissions?

OK. So, I want to start over with this configuration.

I see .ssh directories in user home directories on each PC. I also see ssh and ssl directories in /etc on each PC. If I delete the .ssh directories in each user's home, and (leaving the config files) clean out the ssh and ssl directories on each PC, will that be a good point to start this over from?

Thanks,
Mark

No!
You see .ssh directories on the server?

I agree with Habitual. Except for posting the debug messages you really have not answered our questions.

Do not delete anything in /etc/ssh or /etc/ssl on any PC. I assume you turned off password authentication in the pi's sshd_config but what else did you change?

How did you create the keys? I assume you created the keys on the desktop. Did you create separate keys or are you using the same? Did you copy the correct public key to the Pi. What are the authorized_key file permissions on the pi? Both keys should be 600.

Let me clarify my configuration. I see your confusion...

I am currently working with 3 computers.
1. My desktop PC, running OpenSuse 13.2 (ip: 192.168.1.1)
2. My mail/web server running debian lenny (yes, I know it is a very old version) (ip: 192.168.1.6)
3. The Pi, running raspbian from the NOOBS. The Pi will be a server for backups. (ip: 192.168.1.20)

I mention my mail/web server in this discussion because I upload the spam e-mail that I receive (into spamassassin) onto the mail/web server and the no password ssh into this server works.

I followed the steps on this page: http://www.linuxproblem.org/art_9.html to configure the no password ssh into the mail/web server. It works.

I then repeated the steps for ssh from my desktop to the Pi. It worked. Then I realized that I had never changed the root user password from the default (which was a really silly omission on my part.) So, I changed the password of root. I don't remember how I did that, probably through sudo, but it is changed. Once I changed the root password, I tried to ssh into the Pi and I get the errors that I have mentioned before. This stopped the show on the Pi, so I haven't changed anything else.

I checked the permissions on the ~/.ssh directory on my desktop.
From what you told me, they seem right to me.

On the Pi, there is no .ssh directory on either the pi or the bu (backup) user's home directory.

Thanks for your help,
Mark

Mark:
Are you able to ssh into the RaspPI from any host?
If so, please copy contents of /home/mark/id_rsa.pub to /home/bu_user/.ssh/authorized_keys
using the system that can connect as an intermediate access point to the PI.

If /home/bu_user/.ssh does not exist on PI, create it and set the perms using

then copy /home/mark/id_rsa.pub contents into a new file at /home/bu_user/.ssh/authorized_keys
Fix the perms on /home/bu_user/.ssh/authorized_keys with
I've seen possible issues from ssh user@host if "user" doesn't have a passwd set.
If not, get to the PI and use
as root, then

Then try ssh bu_user@pi.ip
If there is no password on the /home/mark/id_rsa key you should get right in.

Hope that helps.

By repeating the same steps you would of overwritten the original keys. If you created the web server keys first then new keys for the Pi I would of expected that you would fail trying to log back into the web server. Since you can not log into the Pi then it appears you recreated the keys a few times or created the keys first for the Pi then the web server.

You can use the same key pairs on multiple computers if desired or create the key with a different name. You can specify different keys in a ssh config file or use a ssh key agent to store them.