There are those of us that do a lot of ssh during the course of a day. I know I do quite a bit for accessing my files from my office. In any event you’ll probably want to setup public key authentication which allows you to login via ssh without a password.
Of course this adds a level of convenience for you, but could be considered less-secure. While its difficult to spoof an rsa/dsa encryption key (probably more difficult than a simple password) anyone that has access to your machine would be able to access the remote machines via this authenticated key.
There are a few quick steps for setting this up that I’ll outline below.
First you’ll need to generate your local public key. This is the public end of a local public / private pair that you’ll share with the remote machine to identify you.
s
sh-keygen -t dsa(on your local machine)
Second you’ll need to copy this key to the remote machine using a command such as:
scp ~/.ssh/id_dsa.pub [email protected]:~
Lastly, log into the remote machine via ssh (using your password for the last time!) and use this command to add the newly generated key to the list of authenticated keys:
cat id_dsa.pub >> .ssh/authorized_keys
You’ll also probably want to delete the original key as well.
rm id_dsa.pub
At this point a copy of your key is now stored on the remote machine as an authorized keys and any ssh connection coming from the local machine will match that key and connect with the key authentication instead of a password. So nice.
…just remember that anyone with access to your machine will now have this access as well. Definitely keep this in mind if you’re using any kind of a public machine.
Actually, even with an SSH2 public key, they will still need your passphrase to login.
If you want to make it more secure, you need to disable your SSH2 daemon to only accept public key authentication. By default it will use that first, and then fall back to password authentication if the first one fails.
Or set a passphrase on the SSH key, and then use ssh-add once per session to add it to ssh-agent, so that you don’t have to type it for every ssh invocation.
(If SSH pubkey authentication fails, check the file and directory permissions. Your home directory must not be group-writable!)
a) if someone has access to your machine, you lose, whatever.
b) ssh-copy-id
c) what Marius said about keys.
You should also have a look at “keychain”. It’s a wrapper for ssh-agent which allows you to supply a single passphrase then not have to enter another one until you’ve logged out and in again. The credentials are only cleared when you log in, so cron jobs can use ssh without supplying a password even when you’re logged out, but if someone logs in as you they’ll have to supply the passphrase before they (or cron) can use passwordless ssh again.
Pingback: Aaron Toponce » Blog Archive » SSH Key Authentication
This guide is by far the simplest and most clear i’ve seen on the internet! Thanks!
Pingback: » What You Ought To Know About Securing SSH Ubuntu Tutorials : Breezy - Dapper - Edgy - Feisty
Why would you delete a public key?
hello- I use ssh-keygen and was given a series of options to choose from. I choose a few but none of them load. any suggestions..
i.e.
ssh-keygen (options)
thanks!
Nice guide.
however, I find some information is missing.
What happens if I’m
joe@localhost in the local machine, but I want to log-in as “[email protected]” ?
All the examples I’ve seen assume that username is the same on both the local system and the remote ssh system.
Or isn’t that the case?
Best
FC
Just apply the authoried key to whatever user you want to login as on the remote system, so for example, if I’m “Kirrus” on my machine, and I want to be “fred” on the remote machine, I’d do:
scp ~/.ssh/id_dsa.pub [email protected]:/home/fred/
To actually log in on many linux systems you must include the private key when you invoke your ssh session:
ssh -i ~/.ssh/publickeyname -X username@system
The -i means include the key
the ~ means find this in my home folder (typically /user/username)
The .ssh is a hidden file that contains your keys after you generate them.
The -X means transfer X windows to the new session and is optional. It allows you to run graphics or gui programs over the connection if you want to.
The user@system is your user id on the remote system and the name of that system.
/Len
WT6G
Thanks, you’ve been very clear and your explanation very useful, thanks again.
I’m missing something here. If you’ve create a new key e.g. my_id / my_id.pub with no password set, you need to create a file ‘config’ in ~/.ssh to get this working (at least in 8.04, 8.10, 9.04)
Host
IdentityFile ~/.ssh/my_id
where is this host you copied the public key to.
that dame thing swallowed the angle brackets…
Host <hostname>
IdentityFile ~/.ssh/my_id
where <hostname> is this host you copied the public key to.
I just like to add that your home directory on the remote machine (the SSH server) has to be at least as closed as chmod 755. In my case I did simply this and then everything finally worked (macosx client to Linux server):
$ chmod 750
sorry, this command of course:
$ chmod 750 /home/michiel
Great article, ran the commands on my Mac to connect to my Ubuntu Server. I will store the key on a flash drive so I can use it anywhere with the right utilities! Like the site, and the smiley face at the bottom left of site! 😛
I agree with Marius. I’ve seen public keys with no passwords cause a world wide break-in on more than a dozen important machines. I always advise using a password, then some key management system like ssh-add.
cool one, love it
i try it but it want me enter remote machine password yet!
i follow above steps its works fine, but some of the system not working (asking password). please any one give me support