Unfortunately I forgot my id_rsa key passphrase. Since the only solution I found so far is to reset the key by a new SSH key. I now have the problem that I need to add the new key to each server I'm connected to. Is there a possibility to do this automatically? Maybe by copying the information from the "known_hosts" file of the old key to the new one?
This is not quite a duplicate of How to reset or change the passphrase for a GitHub SSH key?, but the answer there is valid.
You have to remember that the whole point of the passphrase mechanism was to prevent access by untrusted hosts. The machinery is specifically setup so only a machine with the proper passphrase (or several) can connect to the server.
The known hosts are only useful to you as a todo list. You need to access one by one somehow (not SSH), to send the new passphrase you generated. The known hosts itself is not the security mechanism, it's just a small part (the less important part, security can do without). It will save you typing some ys in the future.
I'm sorry to say you have to manually get to each machine. If by some miracle you had another vpnish API that all your servers shared you could automate that, but most of us don't.
Related
After allowing an application to install ssh keys on my local machine, I can no longer connect to my Digital Ocean shell. (The app is not related to DO; totally different.) I get a
Permission denied (public key)
error that, with -vvv, debugs to
Trying private key: /Users/macbook/.ssh/id_dsa
no such identity: path/.ssh/id_dsa: No such file or directory
My keys are rsa. I have no idea why the machine is asking for dsa.
My .ssh/config file (which I have never read until now) has only information about the application I allowed access. Maybe it was overwritten. If this is the case, could you tell me how to rewrite my .ssh/config file?
My keys on my cloud server (accessed through a DO gui shell) and on my machine still match up. The folder permissions are ok. I've been using this for months with no trouble until now.
Any suggestions?
Edit:
This was probably a result of the third party application overwriting my .ssh/config file. Because the writing of this file was always automated for me, I never took any notice of it. If you try:
regenerating new keys
appending the new public key to the authorized_keys file on your server on a new line
writing a new .ssh/config file as so:
-
Host 111.11.11.1
User bob
IdentityFile ~/.ssh/new_file.pem
then you might make it. Somehow now I can't get a passphrase to work on the new keys.
I've installed new Ubuntu from scratch on my new machine and want to have an access to the remote host using ssh. The problem is that even if I have both public and private keys I forgot the passphrase used whilst creating keys because right after that I've passed it to ssh-agent. But I still have it (the passphrase) stored in the ssh-agent in my laptop. How can I restore the passphrase from ssh-agent if I have root access and both keys?
As far as I understand it, the passphrase is used to encrypt the private key. ssh-agent doesn't remember the passphrase - it remembers the decrypted private key.
And, as a damienfrancois mentioned, it shouldn't remember it past a reboot.
If you wished to extract the decrypted private keys from ssh-agent itself, you would have to find a tool written to search the memory of the running process and locate keys. One such tool can be found here, but you may well find it very challenging to use.
For a more practical answer, you can just delete your keys from ~/.ssh/id*, make new ones that you know the passphrase for, and move on - for a new machine, you probably haven't gotten too reliant on them yet.
I want to use Gitolite for Git access control.
My question is on ssh keygen for dynamic IP changing workstations. So, do I need to generate ssh keys every time whenever my IP changes. This going to be tedious work for all developers as they use laptops and they need to generate keys and push to Gitolite repo.
Is there any workaround or some other solutions for this ssh public keys generation problem for Gitolite use?
Key generation has nothing to do with IP address from the client perspective.
When you generate an SSH key-pair, for lack of a better analogy, you're generating some files which contain really long numbers which can be used to encrypt or decrypt things. The private key is stored in .ssh/id_rsa (for an RSA key) and the public key is stored in .ssh/id_rsa.pub
You can move that key pair to any machine you wish. You should make sure that the private key is always well protected. The public key, you can give to anyone or copy it wherever you like. It's public. You can also have multiple keys on a machine, with different keys used for different hosts. This is controlled by a .ssh/config file. However, most users don't need that, and stick with a single key pair.
Specifically in the case of gitolite, you'll be storing the public keys of your users in the gitolite-admin/keys directory.
In any case, the fact that your laptop's IP address is changing will have no effect on your keys.
I use a private SSH key and passwordless entry for a number of user accounts on a server that hosts a number of websites.
I use the same private key for each user account. (because I'm lazy? or is that the "right" way).
I now want to authorise another trusted computer in a different part of the country. If I copy the contents of my ~/.ssh onto that machine will that work without any other set up?
Will both machines be able to maintain a connection at the same time?
Update: as an additional security recommendation, you should generate a new set of keys for a new machine and send your new public key out to the various hosts you use it on, rather than copying your private keys. If you're just moving everything to a new computer however, you can take your keys with you, but remember to destroy them securely on the old computer.
The correct answer is to copy your .ssh directory from the old machine to the new. This part is easy (scp -r .ssh user#newmachinehost:~ will do fine—or you can type the keys in character-by-character, up to you).
BUT—I think the missing link to answer this question is what you have to do after you copy your private keys to the new machine.
I had to run the following for each key (I have 3 separate keys for various organizations)
ssh-add .ssh/[key-filename]
If the filename argument is omitted, id_rsa is assumed.
Once you do this to each key (and enter they key's passphrase if required; it will prompt you), ssh will be able to use those keys to authenticate.
Otherwise, no amount of copying will do much. SSH will ignore the keys in .ssh until they are explicitly used (via ssh -i [keyfilename] ...).
This should work, and both machines should be able to maintain a connection at the same time - I've had to copy my ~/.ssh directory a few times before when hard drives have crashed.
Copying ~/.ssh between systems is fine so long as it's limited to just files like authorized_keys, config, and known_hosts. If you want two hosts to be able to access each other, each host needs its own private SSH key, which must then be added to the other host's authorized_keys file.
It is not a good idea to copy private keys across systems!
Think of real world secrets. Each person who learns the secret increases the chance of it being revealed.
Every time you copy your private key to a new system, you increase your risk of exposure because copied private keys are less secure than the weakest system they live on (because the other systems aren't invulnerable either).
If your laptop gets stolen, you need to revoke all private keys (and saved passwords) that were stored there. This becomes problematic when the only way to log into servers is with that very key. You'd better remember to generate a new key on your desktop and install it on each system you revoke the old key from!
Now consider your desktop gets hacked and somebody steals your private key without your knowledge. Perhaps you had shared this key between your work laptop and your personal desktop, but your desktop doesn't really need access to your work system (because you have good work/life balance). That attacker can now access your work system even without having compromised your laptop. The infosec team at work forces you to hand over your laptop so they can audit it, but after a week of analysis, they find nothing. Not so fun.
These may seem far-fetched and unlikely, especially if you're not a prime target (e.g. an executive or sysadmin), but it's just a good practice, especially given how easy it is to create new keys for each system and install their public keys on each appropriate server. (Consider one of the myriads of config/dotfile propagation systems if this seems daunting.)
Additionally, it means you'll upgrade the security of each key to meet the standards as they improve. As you retire old systems and remove their keys, you rotate out their weaker keys. (And if some trash picker finds your old laptop and undeletes your keys, they won't grant any access.)
This is secure so long as you don't share you private key. Just place the public key in the remote machine's ~/.ssh/authorized_keys file for passwordless entry. Don't share the private key though.
The keys are just for authentication. You can log on as many times as you wish with the same key, so long as you can log on with that private key once.
I get this error
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED
The rest of the error message is similar to here.
I have SSH keys in my server. I have my private key in my desktop. I am not sure where I should put it.
Add correct host key in ~/Users/Sam/.ssh/known_hosts to get rid of this message.
Should I add the public key of my server to the file?
The issue is that the server's public key has changed from the one used the last time your client connected, and it may be indicative of an attempt to fool you into connecting to a server that's masquerading as your intended target in some fashion, in order to steal your credentials or some other malicious behaviour.
The message also naturally occurs if the public key on the server has been explicitly changed, which can happen for a number of legitimate reasons - a vulnerability in Debian-based Linux distributions in the not-so-distant past necessitated key regeneration for many people, for example.
If you can confirm that you're connecting to the intended destination, and you know that any key change was legitimate, then you can usually accept the key change. Alternatively, as the message explains, you can obtain the server's public key via an alternative (secure) channel and update your client's local copy so it recognises the server's credentials once more.
If you don't control the server, contact the person or organisation that does, and find out whether the change was legitimate.
You don't need to modify your private key in any way; this is nothing to do with your key pair.
If the keys were really changed on the server (ie. you are not a victim of a man-in-the-middle attack), the easiest think to do is get the line number from the message (offending key is in path/known_host:line_number), delete this line, login to the server (and accept the key).
You mean, programatically?
Probably you can find better support at the forums posted in this question:
https://stackoverflow.com/questions/321618
I was just having this error and I think it's because I'd been previously using another Vagrant instance on my laptop for a work assignment I had, and now that that assignment has finished I'm trying to use Vagrant for my own project, but the old Vagrant instance's public key was still in my known_hosts file. So I just deleted the old entry in the known_hosts file for 127.0.0.1 and saved the file and the error went away.