DietPi version |
G_DIETPI_VERSION_CORE=8
G_DIETPI_VERSION_SUB=8
G_DIETPI_VERSION_RC=1
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
Distro version |
bullseye
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.
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.
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 id_rsa.pub are in this folder; the id_rsamust 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:
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
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.
# 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,umac-64@openssh.com
# EscapeChar ~
# Tunnel no
# TunnelDevice any:any
# PermitLocalCommand no
# VisualHostKey no
# ProxyCommand ssh -q -W %h:%p gateway.example.com
# RekeyLimit 1G 1h
# UserKnownHostsFile ~/.ssh/known_hosts.d/%k
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
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).
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!
