Issues with SSH key login

  • DietPi version |

  • Distro version |

  • Kernel version |
    5.4.199-odroidxu4 #22.05.3 SMP PREEMPT Wed Jun 22 07:29:40 UTC 2022 armv7l GNU/Linux

  • SBC model |
    Odroid XU4

I switched over to OpenSSH instead of Dropbear, as the latter doesn’t work with scp/sshfs.
I tried to set up public key login instead of logging in via password.
Followed this guide to set that up, and everything went as it should. Noticed the client’s public key was amended at the end of ~/.ssh/authorized_keys.
All well and good, but I’m still asked for the password when logging in.
Is there something else that I need to do to enable this feature?

Tried to look into /etc/ssh/sshd_config(.d), uncommented the PubkeyAuthentication yes line, restarted sshd, restarted the SBC, checked the permissions are correct on the .ssh folder, all in vain.

Did you set a passphrase when you generated the key?
If yes: Don’t set one and it will no longer aks for it.
If not: Something else is going on.

1 Like

No passphrase was set, forgot to mention that.

The ~/.ssh folder should be set to 700 (as in chmod -R 700 ~/.ssh), but both ~/.ssh/authorized_keys and the private key file (on the client) need to be set to 600. The guide you linked does not seem to make this very clear.

1 Like

Checked the permissions, adjusted them as per your suggestion, but it still asks for password.

Personally I’m using Dropbear, SCP and SSH keys without issue. For SCP you simply need to install OpenSSH client package (I’d 0) only.

SSH public key I copied into /root/.ssh/ file authorized_keys.

On SSH client side I added the private key.

Have a look if you copied correct keys and format into files.

1 Like

I have OpenSSH v9.0p1-1 on the Arch client, when I use sshfs or scp, I get a “Connection reset” when I access the server.

Does the public key have to go under root’s home folder, or does it go on the admin user I set up?

Just to make sure: private key of the client in the client’s home folder, right?

I did, in the “authorized_keys” file on the DietPi server I have the exact same thing I have in my Arch client’s public key file. The private key on the client is the same one I generated with ssh-keygen.
I nuked both .ssh folders on the client and server, did everything again, and I’m still getting the same issue.

The public key should be stored in the ~/.ssh/authorized_keys file of the user you connect to the server with. I typically connect to my server with the dietpi user, so my public keys are stored in /home/dietpi/.ssh/aauthorized_keys. If you connect to your device with the root account then the keys need to be added to /root/.ssh/authorized_keys as Joulinar mentioned.

It is fine to add the same public keys to both locations if you wish; just double-check the permissions on the file after copying it over.

That’s right, the home folder of the user that will be connecting to the DietPi box (home/andoru/.ssh or whatever the username is). Typically both the id_rsa and the are in this folder; the id_rsa must be in this folder, otherwise when you connect using the key you need to specify its location as a argument in your SSH request.

There is one step of that guide that seems very strange, which is the method used for copying over the public key to the server. It sounds like it is working, and your method for checking is the same as what I would do, but typically I use the ssh-copy-id command to send the public key over. In my case it would look like this:

ssh-copy-id dietpi@

My comment was pointing to the server side. You could use Dropbear as SSH server and simply install the OpenSSH Client package on server side to enable SCP :wink:

Thank you for the lenghty explanation everything is set just as you suggested @BluishHumility. I can’t for the life of me figure out what I did wrong for this to not work as intended.

I tried both methods, both do the same thing, not sure why the author used the cat method.
I followed other guides as well, so I was aware of the ssh-copy-id method as well.

Ah, gotcha. Well, with all having failed, I might as well try reverting back to Dropbear.

You can disable password authentication on the server, but if you have not verified that public key authentication works, you might find yourself locked out.
One more thing to check is whether the ssh client is asking first for password authentication rather than public key.
Finally post the /etc/ssh/ssd_config for clarity.

How does one check that?

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

Include /etc/ssh/ssh_config.d/*.conf

Host *
#   ForwardAgent no
#   ForwardX11 no
#   ForwardX11Trusted yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   GSSAPIKeyExchange no
#   GSSAPITrustDNS no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   IdentityFile ~/.ssh/id_ecdsa
#   IdentityFile ~/.ssh/id_ed25519
#   Port 22
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p
#   RekeyLimit 1G 1h
#   UserKnownHostsFile ~/.ssh/known_hosts.d/%k
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

He may have meant to post /etc/ssh/sshd_config, which should contain the line

PubkeyAuthentication yes

The default is yes and typically the line is commented out unless you want to change that.

Certainly no harm in un-commenting the line, and making it an explicit “yes”. I think I’m running out of ideas!

Quick sanity check: the user you are logging in to the box as is the owner of the .ssh/ folder, right?

1 Like

Here you go: Hastebin
PubkeyAuthentication yes is uncommented.

Yes, the user I connect to owns the folder, and the permissions are set to 700, excepting the private keys. This is true for both the server and the client (I have the same username on both).

ls -la ~/.ssh ; ssh -vvv user@host

1 Like

Alright, realised that I was the culprit. I gave the key a custom name on the client, so it didn’t show up as “id_ed25519_custom name”, it was only as the custom name itself.
Fixed it, and now it works.
Thanks for your help guys, and for your patience!