My last post was quite controversial as I wrote about an authentication form using the password on the command line. Today I’ll be writing about how to login without password prompting but also about ssh-agent, secure RSA keys and how to execute remote commands with ssh.
First of all you need to generate a RSA key:
ssh-keygen -t rsa
accept the default location, and then protect the certificate with a password.
By now in your $HOME/.ssh folder you have at least these two files id_rsa.pub and id_rsa. The .pub file is the file that contains your public RSA key part, as the name says it’s public and you can use it to authenticate with remote hosts, the id_rsa file is the private part of your key and no1 else besides you should have access to it. Nevertheless we also protect the key with a password so if someone access it it won’t be a big problem.
Now, to use the “passwordless” authentication you need to copy the content of id_rsa.pub to the $HOME/.ssh/authorized_keys on the remote machine, if the file doesn’t exists please create it before.
If you want do this in a simple command line just type the following:
cat $HOME/.ssh/id_rsa.pub | ssh YOUR_USER@REMOTE_SERVER “cat >> ./ssh/authorized_keys”
It will ask you the password just the first time. And your done.
But now every time you use the certificate it will ask you for the certificate password not the user at server one (and this because you protected your certificate, if you didn’t protect it you would be logged in by now).
If you want a totally automated process you can use ssh-agent. This way you’ll be able to put your certificate password only one time (for instance at session start) and use it when logged in.
To use ssh-agent just do the following:
cp /etc/X11/xdm/sys.xsession ~/.xsession
edit the .xsession file so some variables look like the following:
usessh=”yes”
sshagent=”yes”
now you need to reset your X (just logout and login).
Now to use ssh-agent and having your certificate available just type:
ssh-add
This will ask you for your certificate password and now you may use it for login into remote servers without using passwords anymore (until the next logout or shutdown).
Cheers,
Pedro Oliveira
Your first cat statement has a typo. You’re missing the dot for the SSH folder on the destination side 🙂 Nice writeup otherwise
to ease your life even more there is a wonderful command ssh-copy-id which automaticly sets permissions etc correct on the authorized-keys file and .ssh dir:
/usr/bin/ssh-copy-id [-i [identity_file]] [user@]machine
In addition to this post I can give the following advice about the use of your private key:
Create a seperate key pair for every computer you use. One for your home pc, one for your laptop, one for your portable app usb stick. etc. If one of the computers is lost or stolen, you only need to remove that certain public key from the authorized_keys file
You can add a comment about a public key on the end of the line that holds the public key! e.g.: ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuuSoMv0NciZfOv+THI9ZXj02XHgqpHaG4//qN6z/8CzghCk0Kwwj82gXFkoPMyzy16YFDxLB5vlrq9QZ8EY0gEAGBXgyyss4+WxkHDxGq842Q== Omko@private-laptop
You can limit from which IP addresses the key pair is allowed to connect. e.g.: from=”192.168.1.116,10.0.0.*” ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAuuSoMv0NciZfOvd5jUabuNRHuhJvhlFt1RVvTkQNEV+5snmVpjkPlgDo3f+LJ5dyI63VBzSFc17sahoPpYHbnICGyHJ22DqPHEgBwFteV8hW
Make sure to always set a password on your private key!!
puttygen is an excellent program to create key pairs. it also create the correct line that can be pasted inside the authorized_keys file. and it allows you to set a password.
SSH key based auth, especially as documented in the article is dangerous. Auth is really two things: Authorization and Authentication. Setting up SSH keys with no pass-phrase completely eliminates Authentication because the private key can be stolen by any admin on the machine.
Authorization: This is the process of determining if the identify in the credentials provided is allowed access to the resource requested. For example, let’s say if that the %wheel group is allowed to “sudo -s”. New user joe, not part of any groups, tries to “sudo -s”. He’s denied because the joe identity is not authorized to run that command.
Authentication: This is the process of proving you actually are the rightful user of the identity in the credentials provided. Using our same “sudo -s” example, bob is an admin and is in the %wheel group. User joe knows this and figures he’ll wait for bob to leave his desk. Bob gets up and joe proceeds to walk over and type “sudo -s”. But, joe is now prompted for bob’s password. Bob is authorized to run “sudo -s”, but joe now has to prove he actually can rightfully have the “bob” user run the “sudo -s” command. He of course doesn’t know bob’s password and joe is denied.
By using SSH keys without pass-phrases, you’ve removed Authentication entirely.
A better way to provide password-less logins, other advanced access controls is to setup Kerberos and LDAP. OpenSuSE provides fantastic tools to do so.
Sorry, but the article is about protecting your keys with password and then use a ssh-agent to manage authorization and then authentication while logged in. You can always argue that using ssh-agent to manage those process isn’t a safe thing, as i may argue that maintain hundreds of passwords for loads of systems without and automation process isn’t viable. The article just pretend to achieve a middle term.
Good info on the definitions of Authorization and Authentication though.
You’re right about many users on many machines, hence, my suggestion of Kerberos and LDAP.