Which is the grep command itself. If i try to kill 29899 it says it doesn't exist, which is correct since the command has already finished executing and it is not an ssh agent.

Now this is most likely where things go bad. First, I want to make notice of the fact that this terminal behaves differently being CentOS than ubuntu, which I am used to. For some reason, any command that has a question that requires a yes or no response causes current processes from terminal commands to break and stop.

For example when I did the command earlier:

ssh-keygen -t rsa -f mykey

I added -f mykey to name the file. If I waited for the prompt to enter a name it fails. Does anyone know why this is happening? Is it because I am connected to the server remotely? Is this a possible reason that my password (which I am about to get to) isn't working?

Welcome to Server Fault! You might have a little more luck getting an answer if you can distill this down a bit into the parts that are actually relevant to the problem you need help solving - there is quite a lot here. Consider summarizing exactly what it is you want help with.
–
Falcon MomotDec 10 '13 at 1:14

Man, I've been downvoted before for being lazy in asking a question, never for being thorough. Sorry. The purpose of having all of the information is to avoid those who answer with things like, "well, if you provide us with the text from the terminal maybe we could actualy help you."
–
UnipartisandevDec 10 '13 at 3:42

2

I really apologize for being a bear, but there is a very large tl;dr factor with this. I've tried to answer as best I can.
–
Falcon MomotDec 10 '13 at 8:09

2 Answers
2

ssh-add adds an identity, which is your private key, to your authentication agent on the box you're typing into the terminal on. ssh will later use this to authenticate to a remote host. However, as often as not you don't need to do this and can simply copy the id_rsa file into place in ~/.ssh/ (and set its mode chmod 400). This file is often encrypted (a wise choice), but in this case it's not a private key so of course you can't decrypt it.

The file ending in .pub is your public key. You would provide this to the remote GIT host or whatever else you are authenticating to. You don't need to keep this value private; you can share it among all the people to whom you authenticate. They have a 1:1 correspondence with private keys.

When you specify the -f option to ssh-keygen, it doesn't touch id_rsa. You will have to put the generated private key in place yourself. You can also specify an option (I believe it's -i for identity file) to ssh to specify an alternative identity (the one you just created) when authenticating. However, since I am sure your web service is running with its own service account it should be perfectly OK to not do this and just use the default path ~/.ssh/id_rsa.

I don't believe ~/.ssh/id_rsa is supposed to be a directory. In my experience, it is a file containing one private key.

It turns out that the issues with commands breaking in terminal was from using the browser-based ssh client provided by a2hosting.com. When it would ask the file and had (/.ssh/id_rsa): I was typing a filename as if it were going into id_rsa. I finally just wrote 'ssh-keygen -t rsa -f myfile' it should have said '-f ~/.ssh/id_rsa'
–
UnipartisandevDec 10 '13 at 9:28

So now you have a public key mykey.pub and a private key mykey. Copy the public key to wherever you need it to be, I've put mine remote_host in ~/.ssh/authorized_keys which has the permissions appropriately set.