Ssh, passwordless authentication
m (clarity edits) |
|||
| (10 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
Sometimes, you need to be able to SSH into a remote machine for scripted maintenance purposes and not get challenged with a password. To do this, you need to set up key-based authentication between the user account you'll be using on your local computer, and the user account you'll be logging into on the remote computer. Here's a quick and dirty how-to. | Sometimes, you need to be able to SSH into a remote machine for scripted maintenance purposes and not get challenged with a password. To do this, you need to set up key-based authentication between the user account you'll be using on your local computer, and the user account you'll be logging into on the remote computer. Here's a quick and dirty how-to. | ||
| − | Creating a public/private keyset on the computer and under the user account you want to log in FROM: | + | Creating a public/private keyset with [[ssh-keygen]] on the computer and under the user account you want to log in FROM: |
ph34r# '''mkdir ~/.ssh''' | ph34r# '''mkdir ~/.ssh''' | ||
| Line 39: | Line 39: | ||
NOTE: it is highly HIGHLY recommended that you only set up passwordless authentication to extremely neutered accounts on the target machine; perhaps an account with absolutely no privileges at all beyond [[sudo]] permission (if necessary) to run a single script which the account in question DOES NOT have write permission on. This limits the damage a potential rogue user who compromises the computer on the other end could cause. | NOTE: it is highly HIGHLY recommended that you only set up passwordless authentication to extremely neutered accounts on the target machine; perhaps an account with absolutely no privileges at all beyond [[sudo]] permission (if necessary) to run a single script which the account in question DOES NOT have write permission on. This limits the damage a potential rogue user who compromises the computer on the other end could cause. | ||
| + | |||
| + | One way to use passwordless authentication in a safe way, is to replace the default shell (sh, csh, bash...) by a more restricted shell. The scponly is such a shell. Scponly only allows a very restricted set of commands. It can also do a chroot, thus greatly limiting the access to the system. Scponly is mainly used to let people access a remote account with commands like "scp" or "rsync" over "ssh"to do secure remote backups. | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
| + | |||
| + | You may also be interested in these articles at IBM's "developerworks" library: | ||
| + | |||
| + | [http://www-128.ibm.com/developerworks/linux/library/l-keyc.html Understanding RSA/DSA authentication, Part 1]<br> | ||
| + | [http://www-128.ibm.com/developerworks/library/l-keyc2/ OpenSSH key management, Part 2]<br> | ||
| + | [http://www-128.ibm.com/developerworks/linux/library/l-keyc3/ OpenSSH key management, Part 3] | ||
| + | |||
| + | |||
| + | ---- | ||
| + | |||
[[Category:Common Tasks]] [[Category:FreeBSD for Servers]][[Category:Configuring FreeBSD]] | [[Category:Common Tasks]] [[Category:FreeBSD for Servers]][[Category:Configuring FreeBSD]] | ||
Latest revision as of 18:45, 12 January 2010
Sometimes, you need to be able to SSH into a remote machine for scripted maintenance purposes and not get challenged with a password. To do this, you need to set up key-based authentication between the user account you'll be using on your local computer, and the user account you'll be logging into on the remote computer. Here's a quick and dirty how-to.
Creating a public/private keyset with ssh-keygen on the computer and under the user account you want to log in FROM:
ph34r# mkdir ~/.ssh
ph34r# chmod 700 ~/.ssh
ph34r# cd ~/.ssh
ph34r# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key ("your_local_home"/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
17:5a:e7:77:ad:2c:0b:8e:f3:97:f8:20:53:79:69:55 root@ph34r
Getting the public half of the key to the REMOTE computer and user account you want to log in TO:
ph34r# scp ~/.ssh/id_rsa.pub jimbo@l0ath1ng.tehinterweb.net:/home/jimbo/id_rsa.ph34r.pub ph34r# ssh jimbo@l0ath1ng.tehinterweb.net Password: % mkdir .ssh % chmod 700 .ssh % cat id_rsa.ph34r.pub >> .ssh/authorized_keys % chmod 644 .ssh/authorized_keys
Checking to make sure it worked:
% exit ph34r# ssh jimbo@l0ath1ng.tehinterweb.net %
Bingo.
From here on out, whenever logged in as root on the computer ph34r, I will be able to SSH into my account jimbo on the machine l0ath1ng without being presented with a password challenge (assuming I did NOT enter a passphrase when I generated the RSA key in the first step). Note that I will not be able to use this key to bypass the password when logging into jimbo@l0ath1ng from any account OTHER than root@ph34r - if I were try it from jimbo@ph34r, I would still need a password.
If I wanted to log in from or to any other user accounts, the steps would be the same, just do them as the appropriate user.
NOTE: it is highly HIGHLY recommended that you only set up passwordless authentication to extremely neutered accounts on the target machine; perhaps an account with absolutely no privileges at all beyond sudo permission (if necessary) to run a single script which the account in question DOES NOT have write permission on. This limits the damage a potential rogue user who compromises the computer on the other end could cause.
One way to use passwordless authentication in a safe way, is to replace the default shell (sh, csh, bash...) by a more restricted shell. The scponly is such a shell. Scponly only allows a very restricted set of commands. It can also do a chroot, thus greatly limiting the access to the system. Scponly is mainly used to let people access a remote account with commands like "scp" or "rsync" over "ssh"to do secure remote backups.
You may also be interested in these articles at IBM's "developerworks" library:
Understanding RSA/DSA authentication, Part 1
OpenSSH key management, Part 2
OpenSSH key management, Part 3
