I'm about to reformat my ubuntu desktop and I need ssh keys to access my servers on the cloud. (DigitalOcean)
what would be the best way to go about this?
I was thinking I'd just copy my id_rsa and id_rsa.pub files on over, but is there are better way?
Create new keys and update digitalocean
Keep a copy of the keys and move them over
I would do 2
Related
I had an user account set up by my collegue weeks ago, to access our server(rhel). Now Im asked to copy my key so I can login to other servers in the cluster.
My first approach was to copy my /home/user/.ssh folder from the (already set-up) server to the new one. This one obviously fails, I found out with ls -a , that in my .ssh directory is only one file - known_hosts.
Im bit confused from my search results, is it necessary to create a new private-public key pair (I dont have any log about creating in before for the first server, so it was probably already setup for me), or is it sufficient to copy files from the first server and setup owners and permissions?
What you're probably looking for is file ~/.ssh/authorized_keys on the server. If you have your key set up, your public key should be stored there. If there is no such file, than you don't have your keys set up(do you have private keys files on your desktop?).
Please note that for usually ssh will require strict access permissions(rwx for user only) for your ~/.ssh directory and authorized_keys file.
Also you can use as many and as few keys as you wish, depending on your security needs. So using single key pair for multiple servers is possible.
I have an inventory of multiple servers. SSH access to these servers is secured using PEM key files. I would like to periodically change the PEM key used by my servers. So, I would like to use Ansible to do the following:
Generate a new PEM key file
For each server in my inventory, connect to the server using old PEM key file
Install new PEM key file
Test to ensure SSH with new key works and old key does not work
What is the best way to do this via Ansible?
You should split this in three playbooks.
The first to generate a new PEM key. This will run locally. See: https://docs.ansible.com/ansible/playbooks_delegation.html#local-playbooks
The second one will do the rollout. So it copies the key to all servers. You can use authorized_key or copy depending on what your preferred workflow is. But thats another question.
The third step then would be a testing playbook, maybe with an assert statement or just using ping to ensure the connection works.
When you have all this playbooks combine them in a single with include or add this three plays in one playbook in the right order. See: https://docs.ansible.com/ansible/playbooks_intro.html
So I have 2 public/private key pairs (id_rsa and id_rsa.pub - one of them is sitting in a "key_backup" folder I made currently), one for GitHub and one for passwordless SSH'ing into a cluster. I looked around Google and could only find guides on how to use two public keys at the same time.. does the same hold for private keys?
How can I maintain authentication w/ GitHub while also being able to maintain passwordless login with my cluster?
Thanks!
-kstruct
You can use multiple private keys at the same time by making sure that your ssh key agent knows about both keys: ssh-add id_rsa1 id_rsa2 on Mac OS or Linux, or add both to Pageant on Windows.
The other option would be to create separate Host entries in ~/.ssh/config that points each of your two keys at their intended uses.
I couldn't find any basic info for designers (on a mac) for how SSH keys work - so thought I'd ask them here.
If I want to connect my work workstation to:
Github
A DEV server
A LIVE server
Do I generate one ssh key on the workstation and add it to all those servers or do I generate multiple keys - one for each server?
Once I've generated a key (or keys), do I copy it into the id_rsa file in my user account on that server (I realize I may have to create the id_rsa file)?
And if I now want to access the same server but from my home laptop, do I add the laptop's ssh key to the same id_rsa file on the server or do I create a new file?
If I need to create a new file, does it matter what the file is called - laptop_rsa?
I basically want to disable root login on my servers but I don't really understand how SSH applies to multiple machines and multiple servers.
Any help or pointers in the right direction would be much appreciated.
Cheers
You only need one key for the local machine that you are connecting
to all three servers.
For the DEV server and the LIVE server, you can add the contents of
your id_rsa.pub file to the
authorized_keys file on each of the target servers.
This file will be in the ~/.ssh directory. You will
need to create the file if it's not there (touch
~/.ssh/authorized_keys). Adding your public key to this file
will let you login with your passphrase rather than a password.
Place all authorized keys (i.e. your laptops id_rsa.pub) in the same
authorized_keys file on the target server.
Adding your keys to authorized_keys doesn't affect root login (that is a separate setting), however, it will prevent people from attempting to brute-force your password if you then turn off password login.
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.