2

When I tried to change my password on an ssh key, I received the following error message:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/Users/username/.ssh/id_rsa' are too open. 
It is recommended that your private key files are NOT accessible by others.
This private key will be ignored.

What does it mean? How can I fix this?

Edit: This solved my problem

sudo chmod 600 ~/.ssh/id_rsa
0

3 Answers 3

2

While fftcc's answer gives you detailed instructions how to make your permissions conforming to ssh's requirements, it may be useful to understand just why these requirements exist.

You can think of a pair of private/public keys as a secret and a test.

The secret is the private key: It is only known to you. It is like a door key. It fits in exactly one lock. The lock tests the secret: The public key is able to verify the private key. (The actual cryptography is more interesting: The public key can test the private key without knowing it, which a door lock cannot do.)

The door lock is public: Everybody can see it and try to put their key in it (and trust me, they do), but it will only ever accept the right one.

If you let people copy the private key (or your door key), they can enter your server (or your house). Therefore, nobody may read that private key.

As explained in the other answer, write permissions in any directory above the secret let a user recursively acquire permissions until they reach the secret, which is why ssh imposes requirements even on the user's home directory above it, which seems weird at first. By the way, I'm not sure whether ssh simply assumes or checks that the directories above the user's home directory are also write protected for the public: While that is, of course, the typical setup, it is not necessarily a given.

From these principles the necessary permissions for the various files make mostly sense. A certain complication arises because one would assume that some files like authorized_keys, especially on the server side, need third party read access so that sshd can read them. But sshd runs as root — it opens a socket on a privileged address, after all — and can read anything it desires, independent of file permissions.

By the way, this implies that your local system admin intern can read your secret keys which you use to access your bitcoin wallet, chmod 600 my butt. For that reason it is possible to encrypt your private key, which seems ... redundant at first but makes perfect sense if you have seen our admin. This question was actually concerned with encrypting the private key; the permission issues were purely incidental.

2

From the man page:

ssh-keygen -p [-f keyfile] [-m format] [-N new_passphrase]
                   [-P old_passphrase]

Check that the file must have the correct permissions.

2
  • You have wrong permissions on your pk file. Change it so that only you can access it
    – Jens
    Jan 16, 2023 at 10:43
  • @fatPotato This error message is an essential information which must be part of the question. The question (and fftc's answer) may be quite useful for posterity. It is important that they contain the information for others to find them. So, please edit your question (even though it has been answered already), describe what you did, and then include this error message. Then everything makes sense :-). Jan 16, 2023 at 14:24
1
sudo ssh-keygen -f ~/.ssh/YOU_PRIVATE_SSH_KEY -p

If the terminal displays the message Permissions 0644 then run the command as root

If the terminal displays the message failed: Permission denied

To fix permission issues, first you need to set the correct ownership and permissions for the home directory and directory .ssh:1

sudo chown -R user:user $HOME sudo chmod 750 $HOME sudo chmod -R 700 $HOME/.ssh This creates the permissions for all files in .ssh necessary to satisfy SSH requirements. SSH recommendations and requirements (underlined) for individual directory files.ssh are listed below (from the manual page):

~/.ssh/id_rsa (or any PRIV KEY — private, primary key) — These files contain sensitive data [namely your authentication secret] and should be readable by the user, but not accessible for others (read/write/execute) — e.g. 0600. The ssh program will simply ignore the private key file if it is accessible by others.

sudo chmod 600 ~/.ssh/id_rsa

~/.ssh/config — due to the possibility of abuse, this file must have strict permissions: read/write for the user and not writable for others - it is enough to install 0644.

sudo chmod 644 ~/.ssh/config

~ /.ssh/authorized_keys — This file is not highly sensitive, but the recommended read and write permissions for the user and are not writable for others are 0644.2

sudo chmod 644 ~/.ssh/authorized_keys

~ /.ssh/known_hosts — This file is not highly sensitive, but read and write permissions are recommended for the user and read-only for others, hence 0644.

chmod 644 ~/.ssh/known_hosts

~/.ssh/ — There is no general requirement to keep all the contents of this directory secret, but the recommended read/write/execute permissions are for the user and inaccessible for others — 0700 is enough.

sudo chmod 700 ~/.ssh

~ / .ssh /id_rsa.pub (OR ANY PUBLIC KEY) — These files are not confidential and can (but not necessarily) be readable by anyone.


1 Write permissions to a directory lets a user change the permissions of the files and directories it contains. .ssh contains the secret private key which must not be known by anybody except the owner. If a different user had write access to the containing directory (.ssh) they could change the permission of the secret key in that directory and read the file. This argument recursively applies all the way up to the file system root.

2 Even though authorized_keys does not contain strict secrets — all keys in it are public — it specifies who can log in: Anybody with the (unknown but verifiable) private keys associated with the public keys listed in the file. Therefore, write privilege to authorized_keys must be restricted to the account owner.

3
  • 644 is not "inaccessible for others" (that would be n00). Jan 16, 2023 at 10:50
  • You can correct my post if you see fit.
    – fftcc
    Jan 16, 2023 at 12:36
  • 1
    This answer contains bad advice, such as running the key generation as root if there are permission issues and changing the permissions and ownership of all files and directories of one's home directory recursively. It also contains factual inaccuracies, such as saying that you may change the permissions on a file in a writable directory if you don't own it.
    – Kusalananda
    Jan 27, 2023 at 8:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .