I’m having an unresolved issue when attempting to SSH into my Raspberry Pi, model 3B+ SBC from my FerenOS Linux Main PC. The SBC is running RaspbianOS based on Debian 10 Buster and the Main PC is running FerenOS Linux based on Debian & Mint. Both the SBC and FerenOS Main PC are running OpenSSH and both are Active (Running) and Enabled.
On the Main PC, I went into ~/.ssh and removed the known_hosts file so I would be prompted for the password for the user (datapioneer) on the SBC which is identical to the user on the Main PC. The IP address of the SBC is 192.168.1.90 and is fixed. When I run the command:
ssh 192.168.1.90
I get the warning message:
The authenticity of host ‘192.168.1.90 (192.168.1.90)’ can’t be established.
ECDSA key fingerprint is SHA256:LmtH5FcZYg9b+7R7GBtlAcnpmLW9PSQ884wz/cp13zk.
Are you sure you want to continue connecting (yes/no)?
I respond with “yes” (without quotes) and hit Enter and instead of being prompted for the password for datapioneer, I receive the message:
Warning: Permanently added ‘192.168.1.90’ (ECDSA) to the list of known hosts. datapioneer@192.168.1.90: Permission denied (publickey,password).
instead. I used PuTTY to access the /etc/ssh/sshd_config file on the SBC and ensure that “PasswordAuthentication yes” is uncommented. After restarting the SSH server on the SBC I return to the Host Main PC, remove the unknown_hosts file again, then repeat the process. The result is the same whereas I am not prompted for datapioneer’s password.
Can anyone assist me with this issue? This issue is 100% reproducible. My intention is to log into the remote SBC the first time using a password, then create a ed25519 SSH keypair and upload the id_ed25519.pub file to the SBC and disable PasswordAuthentication to force the use of the SSH keys.
Note: When I create two identical VMs of Ubuntu 20.04 LTS, one as a workstation and one as a Server and ssh into the Server from the Workstation the first time, I do not encounter this problem and able to remove “PasswordAuthentication yes”, copy up the id_ed25519.pub key from the workstation to the Server using ssh-copy-id command, then restart the OpenSSH-Server to force the use of the ed25519 key pairs.
The issue I reported earlier has been resolved. The problem I had was a human error on my part. I had inadvertently uncommented a line in my local system /etc/ssh/ssh_config file which normally reads:
Password Authentication no
When I inadvertently uncommented this line, this prevented me from being prompted for the remote system user account password after the initial ssh into that remote system since password authentication was turned off. After re-commenting this line, saving the /etc/ssh/ssh_config file on the local system, and restarting the ssh client/server on the local system and retrying, the issue was resolved. I have now copied my id_ed25519.pub file up to the SBC which now resides in the remote system’s ~/.ssh/authorized_keys file and all is well.
Sorry it took me so long to see this, I should be back to a normal state of availability starting next week or thereabouts.
One of my favorite tricks to troubleshoot this, is to run this on the server (needs root privileges):
tail -f /var/log/auth.log
Then, just try to connect over and over. The error you received is very generic, I can think of a few completely different situations that will cause that error. But if you tail the log while you try to connect, it will typically give you more info, and the errors in there will usually be a bit more telling. I think that they intentionally keep SSH error messages vague to avoid giving an outside intruder too much information about why the connection isn’t working.
Thanks, Jay. This issue was finally resolved as I explained in the after-reply. It was quite easy to fix after all.
Keep up the great content on your YT channel. I have subscribed to you for a while now and always learn something new in Linux even though I’ve been an avid veteran user for the last almost 27 years now.