Single file version available here.
Last updated on 2008-06-06.
To discuss, comment here.
| Prev | Next | |
| Home |
*Tags*: remote authentication
To avoid having to type your password every time for your CVS/SSH developer account, you may put your public key(s) in your ~/.ssh/authorized_keys file.
To generate a public key, run the program 'ssh-keygen' (or ssh-keygen1). The public key will be placed at '~/.ssh/identity.pub'.
Ssh implements the RSA authentication protocol automatically. The user creates his/her RSA key pair by running ssh-keygen(1). This stores the private key in .ssh/identity and the public key in .ssh/identity.pub in the user's home directory. The user should then copy the identity.pub to .ssh/authorized_keys in his/her home directory on the remote machine (the authorized_keys file corresponds to the conventional .rhosts file, and has one key per line, though the lines can be very long). After this, the user can log in without giving the password.
Newsgroups: comp.programming,comp.security.ssh,comp.security.unix,comp.unix.shell
I'd imagine that ssh would make your life easier since it's designed as a drop-in replacement for rsh. You wouldn't have to worry about terminal emulation or require something like expect to automate things.
However, if you don't pass ssh something to do on the command line, it will log you into an interactive session much the same way rsh falls back to rlogin.
The downside of using ssh in scripts is that you would need some way to store the key in memory. This is accomplished using ssh-agent in ssh2. You'd need to start cron under ssh-agent and enter the passphrase for your key once. Then any children it spawns will have access to the key in memory. Creating keys with empty passphrases is another solution, but this essentially defeats much of the security around ssh. Once someone gets your private key, they have unrestricted access to any systems that accepts it.
Mario
| Prev | Next | |
| Home |