Correct file permissions for ssh keys and config.

generate-ssh-key.sh

ssh-keygen -t rsa -b 4096 -N '' -C "rthijssen@gmail.com" -f ~/.ssh/id_rsa
ssh-keygen -t rsa -b 4096 -N '' -C "rthijssen@gmail.com" -f ~/.ssh/github_rsa
ssh-keygen -t rsa -b 4096 -N '' -C "rthijssen@gmail.com" -f ~/.ssh/mozilla_rsa

ssh-key-add.sh

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_rsa
ssh-add ~/.ssh/github_rsa
ssh-add ~/.ssh/mozilla_rsa

ssh-key-permissions.sh

chmod 700 ~/.ssh
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts
chmod 644 ~/.ssh/config
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/github_rsa
chmod 644 ~/.ssh/github_rsa.pub
chmod 600 ~/.ssh/mozilla_rsa
chmod 644 ~/.ssh/mozilla_rsa.pub

Thanks man, it helped

Thank

is that ok to have: chmod 644 ~/.ssh/id_rsa? (private key)

@Emilio66 no, otherwise ssh will complain that the permissions are too open.

Thank you so much for this! 🥇

Thanks!

Thanks!

This is very handy. Thanks!

Thank you for this!

Thank you! I aways forget the permissions...

Thanks for sharing. I used these and quickly resolved an issue :)

Should chmod 644 ~/.ssh/authorized_keys be chmod 600?

Exactly what I was looking for, thank you!

Something that has always mystified me...

If ~/.ssh is set to 700 (only file owner can "read,write,execute(open)" the directory, then it seems setting 644 (owner can read/write, group and world can read) is pointless since the world and the group can't even get into the directory where the file is stored. Yet, 700 on the .ssh directory and 644 on authorized_keys is a common recommendation. It just doesn't make sense to me.

So... I was about to follow suit here, and then remembered that there is always man ssh, and the man file says this:

~/.ssh/
        This directory is the default location for all user-specific con-
        figuration and authentication information.  There is no general
        requirement to keep the entire contents of this directory secret,
        but the recommended permissions are read/write/execute for the
        user, and not accessible by others.


 ~/.ssh/authorized_keys
        Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used
        for logging in as this user.  The format of this file is
        described in the sshd(8) manual page.  This file is not highly
        sensitive, but the recommended permissions are read/write for the
        user, and not accessible by others.


~/.ssh/id_dsa
 ~/.ssh/id_ecdsa
 ~/.ssh/id_ed25519
 ~/.ssh/id_rsa
        Contains the private key for authentication.  These files contain
        sensitive data and should be readable by the user but not acces-
        sible by others (read/write/execute).  ssh will simply ignore a
        private key file if it is accessible by others.  It is possible
        to specify a passphrase when generating the key which will be
        used to encrypt the sensitive part of this file using AES-128.

~/.ssh/id_dsa.pub
~/.ssh/id_ecdsa.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_rsa.pub
        Contains the public key for authentication.  These files are not
        sensitive and can (but need not) be readable by anyone.

Based on this excerpt, it is required that the .ssh directory be 700 and the private key files be 600, but it is easier to remember, and will be fully functional, to be utterly restrictive and use 700 on the .ssh directory and 600 on ALL the files.

Thus:

 $ chmod 700 .ssh
 $ cd .ssh
 $ chmod 600 *

Should be all you need.

Thus:

 $ chmod 700 .ssh
 $ cd .ssh
 $ chmod 600 *

Should be all you need.

Well, while this is probably a valid configuration for your user, you'll soon run into problems if your public-key files are not readable by applications and processes that possibly / often run in a different user context e.g. as a different "user" internally in the OS and needs to access your public keys for things like signing and / or verifying files using ssh.

The original gist has the most common and flexible enough permission setup, and is the way most systems, programmers and software expect the permissions to be set.

This certainly helped @grenade. Thanks!

thanks. saved me before the holiday ;-)