I'm following the tutorial here and understand that the I'm making a key that is held in a directory somewhere so that when I go to a website, it will automatically see my key and give me access without me having to sign in. Is that correct? what does the "-t" and "-C" mean? What does putting in my email do? Does that mean that when I go to a site, if I put in my email it will automatically have access to my ssh key?
ssh-keygen -t rsa -C "yourname#yourdomain.ext"
First of all, whenever in doubt, consider checking MAN pages first.
In this case, MAN page tells us that -t rsa sets the type of the key to RSA (or, generates the key using RSA algorithm). The MAN page also mentions that it's the default one, so if you don't put that in, it will still generate RSA key.
As for the -C "yourname#yourdomain.ext", -C specifies a comment which will be put in the generated files that can help you identify the key later on (for whatever reason).
Keys don't work "automatically". Normally, you install your public key (NEVER share your private key - that's the purpose of it being private) on a remote machine, and then when you try logging on to it via SSH, there will be a series of challenge requests between the two that will result you being allowed to log on the instance without typing your password if your private key matches one of the installed remote public keys (there can be more than one if for example you install different public keys for every machine you log on from or have some sort of shared account).
Related
I have about 12 computers with exactly same specs. These are used for my PoS on my business.
I am creating a customized Ubuntu ISO to improve installation time and automate things.
One issue I am facing is OpenSSH-server generated keys (Pub and private), must be generated after installation through command ssh-keygen ...
However, I have to pass explicit and plain-text password, which I would like to avoid.
I would like to know if I can share same private and public keys to everyone, so that I can remote connect on them?
In this way, I can generate keys only once and seed it through post-script installation using pressed.
One issue I am facing is OpenSSH-server generated keys (Pub and private), must be generated after installation through command ssh-keygen...
They are generated after the installation for a reason. And that reason is certainly that they should not go to anyone else (from there is the private word). But they are Host keys.
However, I have to pass explicit and plain-text password, which I would like to avoid.
Why? You can store your public key on them and you would be still able to connect with your private key, which will be still safe.
I would like to know if I can share same private and public keys to everyone, so that I can remote connect on them? In this way, I can generate keys only once and seed it through post-script installation using preseed.
You can, but it is certainly not advised and fail-prone technique possibly leading to the compromised security.
I succesfully followed these instructions from GitHub on how to generate SSH keys and my connection with GitHub is succesfull.
But when I later want to check my SSH key following these instructions I don't get the SSH fingerprint I see in my GitHub SSH Keys setting page when I use ssh-add -l.
Instead of the SSH key fingerprint I get the message The agent has no identities. Why? And what does it mean?
This means you haven't successfully added your key to your agent. Use ssh-add to do so, as given in step 3, part 2 of your first link.
Note that this needs to be done for each ssh-agent instance; thus, if you log out and back in, you need to ssh-add your key again. Similarly, if you start ssh-agent twice, in two different terminal windows, they won't have shared private keys between them, so you would need to ssh-add once in each window (or, better, configure your system in such a way as to have an agent shared between all running applications in your desktop session).
Modern desktop environments generally will provide a SSH keyring for you, so you shouldn't need to start ssh-agent yourself if your agent is so configured, and the agent instance so provided should be shared across your entire session. gnome-keyring behaves this way, as does Apple's keychain and KDE's Wallet (with ksshaskpass enabled).
If you follow the GitHub HowTo "Generating SSH Keys", you get three files in your ~/.ssh directory: known_hosts, id_rsa, and id_rsa.pub.
The file known_hosts is used for the server authentication, id_rsa is used for the client authentification (here is an article, that explains the difference).
Why should I create / why GitHub does need both -- a host and a user authentification files? How does the GitHub authentification work?
Thx
This is just plain old SSH authentication; nothing about it is specific to GitHub.
id_rsa and id_rsa.pub are the two halves of your key: the private key and the public key. Effectively, the public key is the lock for the private key. You put the lock (public key) on whatever servers you want easy access to, without too much worry that someone else will see it, because it's just a lock. You keep the (private) key on your machine, and use it to log into those servers; they see you have a key fitting the lock, and let you in.
(Not to say that you should put your public key on completely untrustworthy machines; there are malicious tricks that can take advantage of shortcuts like ssh -A.)
known_hosts doesn't actually have much to do with this; it's just where ssh stores the fingerprints of all the servers you've connected to, so it can throw up a big scary warning if the fingerprint changes. (That would mean it's not the same machine: either something has changed radically on the server side, or your connection has been hijacked.)
So, anyway, one of the protocols Git itself understands is SSH. When you use git#github.com:... as a repository URL, Git is just connecting over SSH. Of course, GitHub doesn't want you mucking around on their machines, so they only let you do Git things, not get a full shell.
As usual, the Arch wiki has a whole lot more words on this.
known_hosts stores the server's identity the first time you connect, so that you know the next time that you're connecting to the same server. This prevents someone from pretending to be the server the next time you connect (but sadly not the first time)
id_rsa is your secret key that proves that you are really you. Never give this away.
id_rsa.pub is the public key, its purpose for authentication is basically just to prove that you have the secret key without giving it out. This key you can give to anyone what needs it since there's nothing secret about it.
When you connect to the server, SSH first checks that the server has the correct key (ie it should match the one in known hosts. If the client is comfortable that the server is genuine, it uses its private key to sign the following data and sends it to the server;
string session identifier
byte SSH_MSG_USERAUTH_REQUEST
string user name
string service name
string "publickey"
boolean TRUE
string public key algorithm name
string public key to be used for authentication
The server verifies the signature using the public key (which you earlier uploaded to Github), and if it is correct, the client is authenticated.
The known_hosts file is used by ssh whenever you actually connect to a host via SSH. It stores a signed key of sorts for the server. Then, if it changes, you will know.
ssh-keygen -t rsa -C yourgithub#accountemail.com is used to generate the SSH key in which you will give the id_rsa.pub to github. Then, when you connect to github you have the private key id_rsa in your ~/.ssh folder which is then used to validate your information with github.
This is a very low-level explanation, but the private key (non .pub) file is your end, the .pub is for github and the known_hosts is for your box to know what is what.
You can also generate a config file in ~/.ssh for use to specify which key goes to which host..
authorized_keys and known_hosts are entirely different..
Your SSH server (sshd, ie) uses authorized_keys, or whatever file is defined within your /etc/ssh/sshd_config/ for knowing the public side of another key. So when a user connects to your server, they pass their private key, your SSH server verifies against the public key it has within authorized_keys and if it doesn't match, it doesn't work.
Github maintains an authorized_keys so-to-speak on their users. Your public key goes into your authorized_keys on your account and then when you connect via ssh to clone,push,etc, it checks your private key you send over with your public key they already know.
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.
Bluehost only recommends PuTTy. However, is it possible to use ssh keys without any extra, visible programs in Mac?
I would like to have a connection to my server to be a breeze, so that I can control my server in Terminal.
Of course! On Unix and OS X, the ssh-keygen command will generate public and private keys for SSH public-key authentication. The usual way to invoke this command (on the client) is:
ssh-keygen -t rsa
This command will ask you where to place your private key; the default place is ~/.ssh/id_rsa, and the public key will be placed in the file of the same name with a .pub extension added (for example: ~/.ssh/id_rsa.pub). The command also asks you to create a password ("passphrase") for the private key; you can leave it blank for no password as I do, but I don't recommend this practice.
Once you have your public and private keys on the client computer, you need to make your server recognize that public key. If you have shell access to the server, you can upload the public key file with scp, then use ssh to run the following command on the server:
cat id_rsa.pub >> ~/.ssh/authorized_keys
If your hosting company doesn't give you shell access (though Bluehost does), or this procedure doesn't work, it will likely give you a web interface to the same functionality.
Once your server is set up to recognize your public key, it will allow you access without a password when ssh on the client tries to use your private key for authentication. You may still have to enter your private key's password, but typically you only need to do this once for each client login session.
Sure, I do this all the time. Just follow these directions to generate an SSH key and copy it to your server. The instructions should work on both Mac and Linux.
SSHKeychain is pretty much ideal for this. It lives unobtrusively on the menu bar and integrates seamlessly with OS X's Keychain and SSH implementations.
You will need to use ssh-keygen as described in other answers, but once you've done that you can use SSHKeychain to avoid having to type your private key passphrase all the time.
OpenSSH should be available to you on OS X; open a terminal and check out "man ssh". SSH keys get stored (in a format different from PuTTY) in ~/.ssh. Having a config in ~/.ssh/config can make your life easier, too; you'll be able to say "Use this $SHORTNAME for this $HOST using this $KEY" and similar.
At the terminal prompt do
$ apropos ssh
You should get a list of all the programs Mac OS X comes with related to ssh.
Using the ssh* tools, your ssh keys will be stored under ~/.ssh. PuTTY is nice, but compared to the standard OpenSSH tools, it's really only useful on Windows systems.
Sure can! First run:
ssh-keygen
And go through the steps. It is a good idea to give it a password and such. Then you can:
cat ~/.ssh/id_rsa.pub
and copy-paste the result into the bluehost public key textarea.