SSH on Raspberry Pi Permission denied (publickey)

Channels DVR Server
#1

Trying to setup a Pi4 as a Channels DVR server. Following these instructions results in "Permission denied (publickey)" error when connecting via ssh:

SSH access

SSH root access to the OS is possible on port 22222. To enable this feature:

  1. Format any small USB thumbdrive (using FAT/NTFS/exFAT/HFS) with the label CONFIG
  2. Prepare an authorized_keys file and copy it to the drive
  3. Plug the drive into the Pi
  4. SSH access will be setup automatically for the SSH key provided, via ssh -p 22222 root@dvr-server

I followed the directions literally and the authorized_keys file is blank per the instructions. I saw on a linked page that you can generate an ssh key and included it in the file. But I did not do this since the channels dvr instructions don't say to. Is that the problem or is it something else?

Any help would be appreciated.

1 Like
#2

The file shouldn't be blank. It should consist of the public part of your personal keypair. If you don't have keys yet, ssh-keygen will create them for you. Then, you can cp ~/.ssh/id_rsa.pub authorized_keys, assuming you accepted the defaults.

1 Like
#3

You can also add the key via the web UI now.

1 Like
#4

Thank you so much for your help! It works now!

1 Like
#5

I spoke too soon. The next time I tried to ssh in, I got the same denial message.
Why does channels use such a strange method to enable ssh?? I've not seen this in Debian, Ubuntu, Raspbian, or any of the many distros I've used in the last 20 years.

It runs counter to the goal of providing a system that is reliable and easy to use. It's maddening.

2 Likes
#6

As I mentioned earlier, with the latest builds you don't need a USB stick to enable SSH anymore. You can do it directly from the management web UI

1 Like
#7
  1. This is silly. Modern Linux systems just work out the ssh keys on their own.
  2. Nowhere in the documentation is any reasonable guidance given on how this odd process works.
  3. It isn't working when I paste the key into the WebUI. But it is also silly to have to locate, copy and then paste a key into the WebUI everytime I want to SSH into the server. Seriously, you should change this to a more standard ssh implementation.
1 Like
#8

The SSH key is used instead of a password. You have to upload it only once, and then you can SSH as much as you want.

1 Like
#9

Why would anyone think that keys would be better than a password? At the very least you should adequately document this atypical process.

#10

I use SSH keys on all of my servers. It is more secure and login is instant.

you need to generate keys for each system you will use to access the server. But after that, you never have to remember any passwords, and have an instant secure login.

1 Like
#11

I'm not sure how it's more secure. All SSH systems use keys. Most systems generate the keys on connection and use passwords for additional security. With the Channels method, someone who gains access to your system now can get access to all your servers without needing a password.

Again, if Channels wants to use a method that's different than what 99% of Linux distros use, they should at least document it adequately.

#12

I'm not sure you understand are how keypairs work with SSH. There are 2 different sets of keys: the server itself has keys; and if using public keys for access there is the second set of keys, a public key installed at the server and its complementary private key that is kept in your personal computer. I don't know any SSH implementation that does not support public key authentication.

(In fact, many systems do not even allow for root passwords for access, instead solely allow for logging in with keys. This is very common when deploying cloud servers.)

#13

This is not true. SSH Key-Based auth is something that power users set up.
I have not used the Channels RPi build, but the described Key-Based Auth is something that can be set up in all Linux distros. I am surprised you have been using Linux for 20+ years and have never heard of key-based authentication.

It is significantly harder to brute-force an SSH key than it is to do the same with your typed password. Using key-based logins is more secure than using plain passwords.

#14

You may be right about commonality for cloud based servers, but what does this have to do with Channels? In any event, as a user, I did not need to do anything other than install ssh and then connect/choose a password. This is true for Debian, Ubuntu, SUSE, Red Hat, ArchLinux and a few others that I've used. Brute force maybe harder but if someone gains access to your systems, the servers that use key only are compromised.

Let's put the technical question aside. You believe the key system is better and that's fine. Let's assume you're right. The other issue I raised is with documentation. You mention 'the described' system. Perhaps you were independently familiar with this key-based and you never needed 'the described' system to learn how to do it. 'The described' system documentation is woefully inadequate to instruct someone who hasn't used it before. Isn't that what documentation is for?

#15

Considering this is for a DVR whose functionality is exposed through a web server, the need for SSH is questionable in the first place. Furthermore, the ability to enable and upload your public key is exposed in the web UI. For the confused user who doesn't understand this, an online search of ssh key returns many relevant results at the top of the list.

Your confusion is understandable, and yes the documentation could be better. But in this particular case, SSH access isn't really necessary, is it? Your confusion also seemed to stem from the fact that you tried to enable shell access, and said you followed the steps, but that fell down because you didn't understand what an authorized_keys file was. A simple search for that term would have cleared things up, too. Also, you never did say why you needed shell access.

#16

Really? So you can't imagine a need to do something like add storage and specify how it's mounted via fstab? How about copying files from one storage location to another?

"you didn't understand what an authorized_keys file was"

Correct, because the instructions are inadequate. Hence the need for doing a better job with that documentation. Of course, I eventually did search, but that's not a reason to live with inadequate documentation.

In any event, as hinted above, I wanted ssh access because I was adding storage and wanted to add it to fstab. I guess won't even go into the choice of vi as the editor.

#17

Editing fstab is not something that's supported. The image should auto mount any attached drive, and uses systemd to manage mounts.

The channels image is an appliance built for people who don't know what SSH is. If you're comfortable with Linux, then just install your favorite distro and install channels on top.

1 Like
#18

Anyway your feedback was received. Clearly the docs need work. I may just add an SSH password option as well.

1 Like
#19

It's impressive how quickly you respond. Thank you!

#20

I am not very up on how SSH works, everything i have been able to access via SSH, like my DietPi systems, it just works via password.

I Checked the box in the server, it had a pop up to enter key, i typed in a word, it enabled.
I use a bat file to open the ssh connection same as i do my other systems, and it asks to accept the key to known hosts, type yes, then get permission denied.

I think my assumption that your pop up dialog would take my word input, convert it to a SSH key for it to use, was wrong.

I used ssh-keygen and pasted the key fingerprint code it put out into that dialog, but still am getting permission denied, and it displays a different fingerprint key.
Am i missing something?
Edit, there is a .pub file save by that key gen, i pasted its contents into the server dialog, still gettin permission denied.

EDIT2: Ah. u have to include the whole contents of the file, i thought the key was just the parts after the ssh-rsa and before the user @xxx was need to be pasted in.
working now.