New answers tagged ssh-keys
ensure the permissions of the .ssh directory and authorized_keys are right as in 0700 for .ssh and 0600 for ~/.ssh/authorized_keys. If not, fix this first. ensure key authentication is enabled on your server but this should be ok by default, check your sshd_config to confirm. check your log files on your server, on RedHat / Fedora and most linux distros you ...
In my case, I had to copy the id_rsa file (private key) that I had created to the id_dsa file that the ssh process was looking for (previously not created). Using the ssh -v command helped me figure that out.
I have found the solution, it appears on the later installed servers. These servers also have my local DSA key i generated in a later stage. On fedora there is a gnome-keyring-daemon which only knew the RSA key, thus these new servers connection established with the DSA key. Deleting the DSA key from the servers authorized keys and restarting the daemon on ...
Short answer: yes. The makers of OpenSSL aren't stupid, and they didn't design the tool to produce insecure output by default. After that, it's up to the user not to make mistakes that make the system insecure, for instance by leaking the private key. A RSA 2048-bit key (or 4096-bit, if you're paranoid) will provide security for all your uses. Attacks on ...
Adding the following into /etc/ssh/sshd_config fixed it: AllowGroups root sshusers forge
I don't know a good way to do this, but I do know two ways. The ssh-agent seems perfectly happy to store multiple certificates for a single identity. So if you, for example, have id_ed25519 as your id and id_ed25519-cert1.pub and id_ed25519-cert2.pub, you can do this: cp id_ed25519-cert1.pub id_ed25519-cert.pub ssh-add id_ed25519 cp id_ed25519-cert2.pub ...
Top 50 recent answers are included