Help me make SSH Keys, I'm going crazy :-)

[ckizer]

I run my cpanel server with Redhat Enterprise Linux 3, I'm trying to create an SSH key to use. I did this on mac os x to create the key, but apparently i didn't upload it to the cpanel server correctly. I'm trying to make a key for root, since root login is disabled through ssh by default. Using a key will allow my sftp program to connect as root "securely".

I'm still confused about generating the key. This is what I did exactly on Mac OS X:


Executed on Mac:
ssh-keygen -t rsa

2 Files Appeared in my Home Directory:
mykey & mykey.pub

Then I SSHed into my remote server:
su - (this to become root user)
[email protected] [~]# cd ~/.ssh/authorized_keys

Then Added the Contents (copy&pasted) mykey.pub here


Then followed your steps, to select "mykey" when connecting and set my username in the connection window to "root"

Keeps giving the error for wrong user/pass

 

[ckizer]

no-one has ever done this?

 

[pshepperd]

okay, look,

Why are you generating new certificates, are you trying to set this up so that you can login without a password?

What is the goal?

 

[brianoz]

Root login is still disabled even with a key, I think you'll find. Why do you want to do this? Looks to me like you could be going about solving a problem the wrong route, hence why I ask.

 

[ckizer]

i want to use keys for login instead of password, how do i set this up? I'll handle the rest.

the other part is I want to edit files that only root could edit through a GUI SFTP client rather than PICO.. (I'll figure this part out on my own)

But could somebody PLEASE explain where to put the keys I'm generating? This should allow me to login by SSH without passwords, but obviously I'm not doing it correctly.

 

[Spiral]

Considering that your client computer would need a copy of the key on it to connect anyway,
there wouldn't be any difference in you just simply programming that same computer to
simply remember the password and automatically login.

 

[brianoz]

There is a difference between using an SSH key for remote access and embedding a root password which would be obvious if you knew much about SSH.

The main difference is that you can limit user commands via SSH which can make it possible to lock down access via a particular remote key to just a particular command.

The second difference is that a password offers greater access to the system than SSH key access. And a password can often be remembered where it's difficult to remember a multi-line SSH key.

As to where to put the SSH key, I really recommend reading the documentation when looking for this sort of stuff! There are also a series of great summaries on how to use SSH for all sorts of things around the net - check out HOWTO documents.

The ssh -i option allows you to specify an ssh key when initiating a connection. Otherwise you can use the .ssh directory in the home directory of the user (you have to for incoming connections).

On the initiating side of the connection, either:
- use "ssh -i keyfile targethost command", or
- put the keyfile in ~/.ssh
- if you use rsync, use RSYNC_RSH="ssh -i $BACKUP/.ssh/backup_key" where BACKUP is a pointer to your backup home directory

On the receiving side:
- put the public key file in ~/.ssh/authorized_keys file

If you check out the manual you can see how to restrict access via editing the line in authorized_keys

For more info, check out Google - these links are from the first page of a search for "ssh authorized_leys backup":
http://servers.linux.com/servers/04/11/04/0346256.shtml?tid=119&tid=47
http://sial.org/howto/rsync/
http://oceanpark.com/notes/howto_ssh_keychain_public_key_authentication_forwarding.html

I haven't closely read each of the above articles but they do give detailed steps for generating the key (main tip is, press Enter for the keyphrase to generate a key without a keyphrase) and there are many more out there.

 

[Aric1]

Of course there is a very big difference between allowing root login via the root password and via a SSH key.

You didn't say which OS your home computer was running, so I'll just say that if you are using a PC, then Putty can create and use SSH keys, but you have to tell it to do so and make sure the local key and remote key match.

On a Mac (these directions apply in a modified way to many Linux distros as well) you need to be sure the file is located here:

~/Users/username/.ssh/

and it should be called id_dsa or id_rsa (depending on which key type you use). The file should be owned by you and permissions should be 0600 (owner read. write access). The key in that file should be ONLY the key itself, with no extra lines, spaces or invisible character.

On the server, the public key should be placed in authorized_keys taking care that the key is only one line with no extra spaces, characters or improper encoding.

Edit /etc/ssh/sshd_config to make sure root login is still allowed while you test your key.

Restart SSHD via service sshd restart and then log out and back in.

If your key is in the correct location and it matches the public key on the server, you will see:

Enter passphrase for key '/Users/username/.ssh/id_dsa' (or id_rsa):

Enter the key password. If it works, great. Now you can edit sshd_config and turn off root password login. On a cpanel server especially, key-only login is much safer than su to root.

If not, or if it asks you for your root password right away, you've done something wrong. Check your keys and try again.

 

[HostMerit]

If it's asking for your password right away, I dont think you're authenicating with your private key.

Once you've added your key to authorized_keys (Make sure it's on one line and didnt skip one)

Add your key to Putty, and use RSA 2 Protocol - Once you've selected this, go back to the main putty area, click Default Settings, and click Save - Putty by default doesnt save your key.

I dont think its trying to pass your key through, which is why it asks for the PW immediately.

Could be wrong though...

 

[Spiral]

There is a difference between using an SSH key for remote access and embedding a root password which would be obvious if you knew much about SSH.

Of course there is a very big difference between allowing root login via the root password and via a SSH key.

Both of you missed my point entirely which tells me that neither of you really know much about SSH ....

Otherwise, you would have immediately understood what I was actually talking about instead of throwing
out comments on a totally unrelated subject which absolutely nothing to do with the point at hand.

 

[chirpy]

Please refrain from flaming people on the forums or your posts will be removed. There's no need to make disparaging remarks just because someone may or may not have understood you.

 

[brianoz]

Both of you missed my point entirely which tells me that neither of you really know much about SSH ....

Otherwise, you would have immediately understood what I was actually talking about instead of throwing out comments on a totally unrelated subject which absolutely nothing to do with the point at hand.

Your original point stated that there was no difference between programming a client to remember a password and using an SSH key:

Considering that your client computer would need a copy of the key on it to connect anyway,
there wouldn't be any difference in you just simply programming that same computer to
simply remember the password and automatically login.

What I said earlier was that there was a difference, and I then went on to discuss the original poster's question, albeit with content about remote backups which was superflous to the OP's question. The difference - if you're using the key for remote login from the client, then the difference is less, but if you're using it for remote backup, the difference is enormous. (Ability to restrict access to certain commands, and an SSH key only works for SSH access whereas a password works for many things - ftp, POP, IMAP, possibly SMTP, possibly telnet if not yet disabled, etc). Good security practice is to never use a password for remote access other than remote login.

If I missed something else, apologies, and feel free to explain! Apologies for the abrasiveness of my earlier comment, that was rude and I do withdraw it. (I wrote the comment late at night here, I should remember not to do that!)