SSH refuesd remote connection to a Raspberry Pi minicomputer

Rocky Linux Help & Support
1

I am trying to connect my desktop computer (Rocky Linux 9.7) remotely via SSH to a Raspberry Pi (RPi) unit that is connected on the same (local) network:

“[bonanza@localhost ~]$ ssh bonanza@rpi.local
The authenticity of host ‘rpi.local (192.168.200.70)’ can’t be established.
ED25519 key fingerprint is SHA256:O6T8m3MA1NRPKMuRaZlREhxebqyjvmwdVPKo3X19ec8.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes”

On hitting “Enter”, instead of connecting to the remote RPi, I receive the following message:

“Warning: Permanently added ‘rpi.local’ (ED25519) to the list of known hosts.
Connection closed by 192.168.200.70 port 22”

Then when I try to reconnect, the remote RPi denies the connection with the following message:

“bonanza@rpi.local: Permission denied (publickey).”

I don’t understand the reason for the connection denial. I took the following troubleshooting steps - no joy:

  • put SELinux in permissive mode (although there was no SELinux error messages);
  • added port 2021 to the firewall;
  • disabled the firewall;
  • enabled the .local domain in “/etc/ssh/ssh_config.d/50-redhat.conf”

FYI, there is no problem connecting my laptop (running Linux Min 21) to RPi through SSH. I will appreciate any help that would help me solve the problem.

Thank you for your consideration!

2
  1. File permission issue with the private key on the Rocky end.
  2. Issue with the authorized_keys file on the remote end. Missing key, file permission, etc.
  3. Wrong username

You can attempt to log in using the ssh -v option to get more details about what the problem is.

3

As @FrankCox already mentioned, majority of times this occurs is due to the file permissions, but can also be the .ssh directory permissions too. On both sides (your computer and raspberry)

  1. .ssh directory should have 700 permissions
  2. private keys should have 600 permissions
  3. authorized_keys should have 600 permissions

Also, /var/log/secure on the raspberry side should also show if there is a permission issue and the rejection for it. Or as mentioned use ssh -v or even more verbose with ssh -vvv

4

Thank both of you (@FrankCox and @iwalker) for your replies. Here’s what I’ve found so far:

  1. There were no OpenSSH keys on Rocky desktop, whether public or private, that I could locate. The directory “~/.ssh” contains only one file: known_hosts. I created the key files with the “ssh-keygen” command (see below).
  2. “/home/bonanza/.ssh” directory has permission 700
  3. “authorized_keys” file on RPi has permission 600
  4. I was unable to find a “/var/log/secure” directory on RPi

After running ssh -vv, I’ve found that none key files (e.g. /home/bonanza/.ssh/id_rsa) exists. Following the man page for “ssh-keygen”, I created the public and private keys id_rsa and id_rsa.pub. Both keys have permissions 600, yet I still receive the “Permission denied (publickey)” error, as shown below:

bonanza@localhost ~]$ ssh -vvv bonanza@rpi.local
OpenSSH_8.7p1, OpenSSL 3.5.1 1 Jul 2025
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 55: Including file /etc/ssh/ssh_config.d/50-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for ‘final all’ host rpi.local originally rpi.local
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 3: not matched ‘final’
debug2: match not found
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1 (parse only)
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]
debug3: kex names ok: [curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 15: Applying options for *.local
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: /etc/ssh/ssh_config line 55: Including file /etc/ssh/ssh_config.d/50-redhat.conf depth 0
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug2: checking match for ‘final all’ host rpi.local originally rpi.local
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 3: matched ‘final’
debug2: match found
debug3: /etc/ssh/ssh_config.d/50-redhat.conf line 5: Including file /etc/crypto-policies/back-ends/openssh.config depth 1
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug3: gss kex names ok: [gss-curve25519-sha256-,gss-nistp256-sha256-,gss-group14-sha256-,gss-group16-sha512-]
debug3: kex names ok: [curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512]
debug1: /etc/ssh/ssh_config.d/50-redhat.conf line 15: Applying options for .local
debug3: expanded UserKnownHostsFile ‘~/.ssh/known_hosts’ → ‘/home/bonanza/.ssh/known_hosts’
debug3: expanded UserKnownHostsFile ‘~/.ssh/known_hosts2’ → ‘/home/bonanza/.ssh/known_hosts2’
debug2: resolving “rpi.local” port 22
debug3: ssh_connect_direct: entering
debug1: Connecting to rpi.local [192.168.200.70] port 22.
debug3: set_sock_tos: set socket 3 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /home/bonanza/.ssh/id_rsa type 0
debug1: identity file /home/bonanza/.ssh/id_rsa-cert type -1
debug1: identity file /home/bonanza/.ssh/id_dsa type -1
debug1: identity file /home/bonanza/.ssh/id_dsa-cert type -1
debug1: identity file /home/bonanza/.ssh/id_ecdsa type -1
debug1: identity file /home/bonanza/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/bonanza/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/bonanza/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/bonanza/.ssh/id_ed25519 type -1
debug1: identity file /home/bonanza/.ssh/id_ed25519-cert type -1
debug1: identity file /home/bonanza/.ssh/id_ed25519_sk type -1
debug1: identity file /home/bonanza/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/bonanza/.ssh/id_xmss type -1
debug1: identity file /home/bonanza/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_10.0p2 Raspbian-7
debug1: compat_banner: match: OpenSSH_10.0p2 Raspbian-7 pat OpenSSH compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to rpi.local:22 as ‘bonanza’
debug3: record_hostkey: found key type ED25519 in file /home/bonanza/.ssh/known_hosts:1
debug3: load_hostkeys_file: loaded 1 keys from rpi.local
debug1: load_hostkeys: fopen /home/bonanza/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug3: order_hostkeyalgs: have matching best-preference key type ssh-ed25519-cert-v01@openssh.com, using HostkeyAlgorithms verbatim
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,ext-info-c,kex-strict-c-v00@openssh.com
debug2: host key algorithms: ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
debug2: ciphers ctos: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
debug2: ciphers stoc: aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes128-gcm@openssh.com,aes128-ctr
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha2-256,hmac-sha1,umac-128@openssh.com,hmac-sha2-512
debug2: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,ext-info-s,kex-strict-s-v00@openssh.com
debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug3: kex_choose_conf: will use strict KEX ordering
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:O6T8m3MA1NRPKMuRaZlREhxebqyjvmwdVPKo3X19ec8
debug3: record_hostkey: found key type ED25519 in file /home/bonanza/.ssh/known_hosts:1
debug3: load_hostkeys_file: loaded 1 keys from rpi.local
debug1: load_hostkeys: fopen /home/bonanza/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory
debug1: Host ‘rpi.local’ is known and matches the ED25519 host key.
debug1: Found key in /home/bonanza/.ssh/known_hosts:1
debug3: send packet: type 21
debug1: ssh_packet_send2_wrapped: resetting send seqnr 3
debug2: set_newkeys: mode 1
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: ssh_packet_read_poll2: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 4294967296 blocks
debug1: Will attempt key: /home/bonanza/.ssh/id_rsa RSA SHA256:Bp10qdyS27rt78+d4F7fnzKpGjJT1lMExFuHG9m6Kt8 agent
debug1: Will attempt key: /home/bonanza/.ssh/id_dsa
debug1: Will attempt key: /home/bonanza/.ssh/id_ecdsa
debug1: Will attempt key: /home/bonanza/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/bonanza/.ssh/id_ed25519
debug1: Will attempt key: /home/bonanza/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/bonanza/.ssh/id_xmss
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 7
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com (unrecognised)
debug1: kex_input_ext_info: ping@openssh.com (unrecognised)
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /home/bonanza/.ssh/id_rsa RSA SHA256:Bp10qdyS27rt78+d4F7fnzKpGjJT1lMExFuHG9m6Kt8 agent
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/bonanza/.ssh/id_dsa
debug3: no such identity: /home/bonanza/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/bonanza/.ssh/id_ecdsa
debug3: no such identity: /home/bonanza/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/bonanza/.ssh/id_ecdsa_sk
debug3: no such identity: /home/bonanza/.ssh/id_ecdsa_sk: No such file or directory
debug1: Trying private key: /home/bonanza/.ssh/id_ed25519
debug3: no such identity: /home/bonanza/.ssh/id_ed25519: No such file or directory
debug1: Trying private key: /home/bonanza/.ssh/id_ed25519_sk
debug3: no such identity: /home/bonanza/.ssh/id_ed25519_sk: No such file or directory
debug1: Trying private key: /home/bonanza/.ssh/id_xmss
debug3: no such identity: /home/bonanza/.ssh/id_xmss: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
bonanza@rpi.local: Permission denied (publickey).

The output shows that there still are missing files, even after generating the public and private keys. What am I doing wrong? (Or, the better question would be: how do I generate the missing key files?)

Thank you for your consideration!

5

The above verbose output shows SSH keys exist on your system and it’s attempting to use those. There will also be .pub files for each of those, so eg: id_rsa.pub or id_ed25519.pub which would normally need to be copied to the Raspberry PI using ssh-copy-id or by editing the authorized_keys on the Raspberry and pasting them into it.

Of course, that means on the Raspberry the SSH password authentication needs to be enabled so that you can use ssh-copy-id which as it’s not offering that, would suggest that the /etc/ssh/sshd_config or files under /etc/ssh/sshd_config.d have that option disabled.

Normally, you don’t need to provide additional parameters when generating an SSH key. It’s enough to do ssh-keygen which would default to generating id_rsa, or you can add additional parameters, if you want to change the key length, or generate a different type instead of id_rsa.

6

Thank you for your help! I’ll follow the instructions (i.e. copying the keys to RPi) and taking it from there. I’ll have to learn more about the OpenSSH.

The above verbose output shows SSH keys exist on your system and it’s attempting to use those.

It’s odd that OpenSSH finds the keys on my system, as there are only three files in the .ssh directory:

[bonanza@localhost ~]$ ls -l ~/.ssh
total 12
-rw-------. 1 bonanza bonanza 2622 Feb 3 02:43 id_rsa
-rw-r–r–. 1 bonanza bonanza 581 Feb 3 02:43 id_rsa.pub
-rw-r–r–. 1 bonanza bonanza 95 Feb 3 02:24 known_hosts

A search throughout the home directory (ls -al | grep id_dsa) returned zero results.

Thanks again for your help!

7

Looks a bit odd to me. I’d expect to see ‘authorized_keys’ for pubic key (on both client and server, and I’d also expect to see mode set to 0600 on all three (rw only).

8

You don’t need authorized_keys on the client side. That file holds the public SSH keys so that someone can connect to that machine. Therefore, unless you are allowing people to connect over SSH to your client machine, then it is perfectly normal not to have it.

On some systems the .pub files do have 644 and that is not the problem here either. The known_hosts is only a list of entries that shows the hosts/servers you have connected to from your client machine. And depending on the Linux OS installed, just like the pub files the permissions can vary, but have no relevance to this problem either.

EL-based systems like RHEL and Rocky do have strict requirements that the .ssh directory has 700, that the private keys are 600, and that the authorized_keys is 600 as well. Then the connection is allowed.

The reason this host is not connecting is because it cannot find the SSH key - which is shown in the logs from the ssh debug command. It attempts a list of keys and then gives up as password auth is disabled. So the solution here is to resolve that by ensuring the SSH key on the client has been copied across to the Raspberry and that it exists in the authorized_keys file - and also ensuring that all the permissions previously mentioned on the appropriate files and directories are correct.