Member Avatar for JySysAdmin

I'm trying to connect to my Fedora machine using my SSH PEM Key. I've added the key to .ssh/authorized_keys and am still getting promted for a password. The machine can connect to other machine's with the key, but not my Fedora one.

I've setup CentOS to accept SSH Keys but I believe this is my first time for Fedora, maybe there's an extra something I'm missing.

I uncommented these lines in /etc/ssh/sshd_config and still no luck :( :

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      .ssh/authorized_keys
AuthorizedKeysCommand none
AuthorizedKeysCommandRunAs nobody
  • 2 Contributors
  • 3 Replies
  • 377 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by rubberman

Dani AI

Generated

As confirmed the public key was placed (and pointed out the private/.pem vs public/.pub distinction), the usual Fedora-specific causes to chase next are: client/server debug output, sshd's effective AuthorizedKeysFile, strict Unix permissions/ownership, SELinux file contexts, and any network-filesystem or ACL oddities. The steps below are a compact checklist that fixes the vast majority of “key ignored / falls back to password” cases.

Start with client and server debug so the failure reason is explicit. From the client run:

ssh -vvv username@host

and on the server inspect authentication messages (either /var/log/secure or the journal) and the effective sshd config:

sudo tail -n 200 /var/log/secure
sudo journalctl -u sshd -e
sudo sshd -T | grep -i authorizedkeysfile

The client debug shows which key is offered and whether the server accepted or refused it; server logs show why (bad modes, permission denied, SELinux AVC, etc.). (docs.digitalocean.com)

Verify ownership and traditional Unix permissions (sshd’s StrictModes requires these). Typical fixes are:

ls -ld ~ /home/username ~/.ssh
ls -l ~/.ssh/authorized_keys
chown username:username ~/.ssh ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

If any parent directory (home) is group- or world-writable, sshd will reject keys. (wiki.centos.org)

If permissions look correct, SELinux often blocks access even when UNIX bits are OK. Check mode and context, then restore the standard context:

getenforce
ls -Z ~/.ssh ~/.ssh/authorized_keys
sudo restorecon -Rv ~/.ssh

(It is common that ssh-copy-id or an editor leaves the wrong SELinux label; restorecon fixes that.) Checking /var/log/audit/audit.log for AVC denials helps confirm SELinux involvement. ()

Other edge cases: home on NFS (UID/GID mismatches or root_squash), custom AuthorizedKeysFile/AuthorizedKeysCommand entries, or POSIX ACLs can also stop key lookup. If homes are network-mounted, try a local test account or move an authorized_keys to a local path to rule out NFS issues. (docs.redhat.com)

Typical resolution order: 1) reproduce with client -vvv, 2) check server logs, 3) fix ownership/permissions, 4) restore SELinux labels, 5) re-check custom sshd config and NFS/ACLs. These steps usually reveal the exact reason Fedora is rejecting a working public key.

Recommended Answers

All 3 Replies

Member Avatar for rubberman

You need to add the public key part to authorized_keys. The .pem file has the private key. When you ran the program ssh-keygen, it created the .pem file, but it also generated a .pub file. It is the .pub file that you need to append to .ssh/authorized_keys. The following is from the ssh-keygen man page:

 Normally this program generates the key and asks for a file in which to store the private key.  The public key is
 stored in a file with the same name but “.pub” appended.  The program also asks for a passphrase.  The passphrase
 may be empty to indicate no passphrase (host keys must have an empty passphrase), or it may be a string of arbi-
 trary length.  A passphrase is similar to a password, except it can be a phrase with a series of words, punctua-
 tion, numbers, whitespace, or any string of characters you want.  Good passphrases are 10-30 characters long, are
 not simple sentences or otherwise easily guessable (English prose has only 1-2 bits of entropy per character, and
 provides very bad passphrases), and contain a mix of upper and lowercase letters, numbers, and non-alphanumeric
 characters.  The passphrase can be changed later by using the -p option.
Member Avatar for JySysAdmin

I added the public key part (Did my post lead you to believe that I added the PEM?). I did things the same way as I did on CentOS and it's working there, but not on Fedora for some reason.

Edited by JySysAdmin
Member Avatar for rubberman

Ok. Yes, I misunderstood that... :-) Unless the file was mangled for some reason (DOS CR/LF line terminators vs. Unix/Linux LF terminators, for example), then I don't know why Fedora won't work. Anyway, verify that the file is a Linux text file (LF line separators) and not in DOS/Windows format.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.