I need to access GitHub from multiple cloud VMs. Do I have to create an ssh key on each VM and have a ridiculously long list of keys in my GitHub account, or can I (and even if I can, should I) copy the private ssh key to all the VMs, so that I only need to configure a single public key on GitHub? Is that a) possible and b) stupid?
You can use Personal Access Token instead if you don't want to access via ssh. Here is the official link about how to do this.
Related
A colleague of mine told me he could SSH into a server where his key is only listed in authorized_keys. I was surprised and wondered why ssh-copy-id copies the key to the server then ?
Because that is how you would let a client connect to the server via Public Key Authentication.
ssh-copy-id is a script that installs a public key on a remote machine via ssh. Basically what it does is append the public key to the remote machine's ~/.ssh/authorized_keys (see ssh-copy-id man page for more details). It can be useful especially if you do not have physical access to the machine.
But of course, since the public key you would like to use wouldn't be installed on the target server yet, you would have to log in with an already available authentication method like login password, preventing potential malicious users from adding their own public key.
Our current infrastructure uses ssh keys for passwordless login to our Linux servers.
As our infrastructure grows, managing these authorised keys is getting harder.
As we also have an Active Directory (AD) server, I would like to authenticate the users over ssh using this mechanism, but maintain the passwordless nature of ssh keys.
Is it possible to authenticate the users over ssh without password, using some AD mechanism?
This is usually done via SSH key certificates in order to keep the password-less nature and at the same time have a Central Authority that can be trusted to generate new certificates for each account.
LDAP/Active directory use on login is not advised - apart from having to use passwords, it also becomes a single point of failure for access to any system it manages.
See RedHat documentation on how to do this and also Facebook's good write up on their use of certificate authentication with SSH.
Option 1
This is a good article explaining how to do this.
Storing SSH keys in Active Directory for easy deployment
Basically, it will allow people to post their public keys to your Active Directory and then you can set up a cron script on your servers to fetch a copy of the public keys every 5 minutes or so.
Option 2
You could also use a file server that has all your keys and get each server to fetch from there using a cron script. Obviously, you need a way to verify each key's authenticity especially if you are using FTP or some other insecure protocol. This could be achieved using GPG. You could have a company master GPG key that signs all the employee keys.
Personally, I like option 2 the best because I think it is more secure, but either method should work. Hope this helps!
My approach would be to reduce the problem to an already solved one by
Use active directory to authenticate without password and establish an HTTPS connection using Kerberos. The Dzone Tutorial Configuring Tomcat 7 Single Sign-on with SPNEGO might be a good starting point for that approach.
Wrap SSH into the https-protocol like, see section Wrapping SSH in HTTP(S) at https://unix.stackexchange.com/questions/190490/how-to-use-ssh-over-http-or-https
Quite simple: How can guest SSH access to a server be granted to multiple users who will share the same 'guest' login?
The server has only RSA key access (no password login) and this works fine for the normal case where the public keys of single users are copied to authorized_keys on the remote server. What I'm looking for is guest access as user 'guest', the problem is the keys - I don't want to have to install keys from all my clients, rather give them a key to use - would this be the private 'guest' key? How does this work?
Clients will be connecting from Linux, and Windows using Putty.
I dont see a problem here.
In your setup you treat all connecting people as a single person. Thus they all can use the same key, in this case you have to hand out the private key to all of them.
However that is a BIG security risk. Once that key is given out (happens with lots of unexperienced users) you have to replace the keys for ALL people. That does not sound very good.
All you have to do is reverse the procedure.
Create the RSA keys at server side. And then copy public key to the authorized_keys file and take private key at client side.
So now multiple clients can do ssh to the server using this private key.
I was going to do rsync, but rsync over SSH needs to have the private key on the second EC2 instance. I'm concerned about copying my private SSH key to the server. That can't be safe, right?
Is there another possibility, e.g. somehow getting authentication via my computer? If it's only a little auth check at the beginning of each sync, I don't mind that.
Or can I securely sync files between EC2 instances without the private key?
Thanks for your input,
MrB
You needn't use your EC2 keys to setup SSH between the two EC2 instances. Look at this guide - http://ask-leo.com/how_can_i_automate_an_sftp_transfer_between_two_servers.html .
Simple outline of the process is, lets say you want to transfer files from Server1 to Server2. You basically create a new key for your user on Server1 (note this is different from the key you downloaded to access your EC2 instance - Server1 in this case). Then load up the public part in Server2's authorized_keys and you should be able to setup SSH.
If the user that the rsync process is going to run under is not your user, then you will have to setup SSH keys for the user that the process will run under.
HTH
Just create a snapshot of the volume you have your modified files contained and attach it your outdated instance after detaching the outdated volume.
I always use ssh in putty to connect a remote server. As I know, ssh is based on public/private key mechanism, is it?
Does that mean the client will receive a public key first time when it connects to the server and then use the public key to continue with following communication?
Thanks.
Do you mean for authentication, or for encryption?
For authentication, Section 5.5.1 here covers it:
http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch05_05.htm#ch05-46136.html
In general, you create the key pair and get them there through other means.
If you mean for the encryption, try section 3.9.1.3 here:
http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch03_09.htm#ch03-65213.html
There are two parts where public/private key come into play -- session initialization and (optionally) user authentication.
In session initialization, the host public and private keys are used to set up the encrypted connection, but are not used to encrypt the connection itself. Instead, the initial set up is used to securely generate a unique session key that is used to encrypt the connection. The host public/private keys are generated and installed on the server.
While connecting, your ssh client (PuTTY in this case) will verify that the host key is what it remembers from the last time you connected. (If they are different, then somebody might be snooping on your connection!) This is why PuTTY asks you to confirm the hash of the host key the first time you connect -- it doesn't have a record of what the key is supposed to be, so it asks you to verify. If you tell PuTTY to confirm and save, then PuTTY will save the hash of the host key in the registry for future connections.
In user authentication, the user public and private keys are used to allow access to the server. The public key is installed for the user on the server. The server can then use that key to issue a challenge to the client that can only be answered correctly by using the user's private key. The user generates the public/private keys him/herself (e.g. with ssh-keygen).
For PuTTY, you can generate your own public and private key using the PuTTYgen utility (this is the PuTTY equivalent to ssh-keygen). It's up to you how you want to get the public key installed on the server. Then, run Pageant (a little app that sits in your notification area) and add your private key. If you set a passphrase on your private key, then Pageant will prompt you to enter it. Pageant, while running, will then work with PuTTY (or pscp, psftp, etc.) to make use of your private key.
This is a gross simplification of the processes involved; see James' answer for links to details.