SSH Keys - Can't access server after changing desktop OS

So I’m very green when it comes to using SSH keys, but tried them on a couple ubuntu servers in my lab. I had it working fine. And I do have console access to both servers, so I can get to them if this doesn’t work, but I’d prefer to learn how it is supposed to be done.

I changed from Linux Mint to Pop OS! to give it a try on my desktop system, and I brought the whole .ssh folder from my home folder over to my rebuilt system. I put all the files back into the .ssh folder, thinking that would be enough to SSH back into those two ubuntu servers, but instead I get the error:

sign_and_send_pubkey: signing failed: agent refused operation
rick@ Permission denied (publickey)

My .ssh folder contains both private and public keys (at least thats what it looks like).

Try opening a terminal on your new desktop and issue: “ssh-copy-id rick@” and push your public key back up to the server.

same error unfortunately.

Sorry to hear that. I guess it may be prudent from a security angle to just remove the files under. .ssh on your new desktop and generate new keys. That should fix it.

So in theory then, I would have to generate a different ssh keys for every system that would SSH into a particular server? In my case, just changing the OS, I’d have to generate new keys everytime I reinstalled my OS?

I was under the impression that you would generate keys for a server you want to access, then you could move one of either the private or public key (not sure which one to be honest) around to a different system to access.

I tested your theory on my own Ubuntu 18.04 desktop, PopOS, and Ubuntu Server (headless) all running in Parallel virtual machines and I was able to successfully copy my public/private key pairs from Ubuntu Desktop over to PopOS and later log into my Ubuntu headless server without needing a password. So, you are correct, this should work.

I will admit I needed to install the ssh service first on my ubuntu desktop, and popos first and then manually copy over the id_rsa (private), (public) and known_hosts files over to get this to work since the ssh service was not installed and listening on these newly installed default desktop systems.

Make sure you have installed ssh on both the old and new systems and try to scp (secure copy) the files over to PopOS and try again. Good luck.

A private key in terms of SSH is a proof of identity. You don’t normally need a separate key pair for different machines. The way I do it is I have a single private key, protected with a passphrase, installed on all my SSH clients. This to me is logical because I don’t need separate identities on separate machines. I find it much more convenient to have the same identity from wherever I work.

The private key should never leave your systems! The machine you want to log into will only ever need the public key (in the authorized_keys file).

1 Like

So I think I found part of the problem. Still cannot connect to my server. I had to add

SSH_AUTH_SOCK=0 in front of ssh rick@ so …
SSH_AUTH_SOCK=0 ssh rick@

This has something to do with GNOME keyring (which I’m not using anyway), and once I disable it in the startup apps, I don’t have to enter the SSH_AUTH_SOCK=0 part.

So now, the only error is Permission denied (publickey). If I enable password authentication in sshd_config on the server, I can get in just fine, after supplying the password.

By process of elimination, the only change that occurred was moving my private key from my old Mint install, to my new Pop OS install. Both servers that I’m trying to connect to were working fine with SSH keys. I had a separate one for each server.

Do I have to do anything on my client machine to “register” my private keys or anything? or just copying them into the same location I had before do the trick, which in my case is ~/.ssh

I created a new key pair, did the ssh-copy-id command to send the public key to the server, it said it was successful. Once I disable password authentication on the Ubuntu server’s SSH config file, restart the service, I get the Permission Denied (publickey). The authorized_devices file shows my user@hostname of my client machine.

If I enable password authentication, it works fine, but obviously its using the password, not the ssh key.

I had an issue with Permission denied that was similar. Found that it was that the .ssh folder needed to be set with chmod 700 permissions and the authorized_keys file needed to be set with chmod 600. Not sure if that will help you with your issue but you might want to check those settings on your server.

Both .ssh folder and authorized_keys have the appropriate permissions.

If you use the -v switch with your ssh attempt what does the output show?


I had to add my private key to the SSH client agent by going…

ssh-add myprivatekey

Using the verbose logging, it showed the SSH client trying a bunch of private keys that did not exist, and was never trying my private key, until I manually added it to the SSH client agent.

Thanks to everyone who provided input.