On Tue, 2004-05-11 at 20:23, steve wrote: > Jim Cheetham wrote: > > thing. Possession of the public key will allow anyone to connect to
> But seeing as the public key is a) machine specific, b) user specific, > and c) of use only on the target machine, the only way you can use it is > if you are on the source machine, logged on as that user, connecting to > that target, or connectnig said user to another host, for which you > already have privileges to modify the authorized_hosts file. Well, sort-of, yes. I made a mis-type, and should have said "private key". The point was that before the creation of the keys, only a human with knowledge of the password -of the target host- could connect. However, once the ssh key has been created (passwordless), anyone who gets their hands on that small datafile (the private key) can now connect to the target host. You can mitigate against that with settings on the target host that limit the ways that the key can be used - however by default there are no restrictions. > How can you automate the provision of a pass phrase without writing it > down when this job is to be run fron cron? You run an ssh-agent process, and ask that to load the key into memory. It will ask you for the passphrase in order to decrypt the key, and then loads the decrypted key. Any ssh process can now ask the ssh-agent for the key, rather than picking it off the disk, and won't need the passphrase. Many people invoke ssh-agent as part of their login process. Once it's in place, (by default) child processes can add keys to the agent, take them away, or use them with ssh commands. Non-child processes, like invocations from cron, can also access the agent, as long as they know where it is (i.e. where the socket is), and have permission to do so. (I use a Debian package called 'keychain' to help with the settings) It's a compromise, of course. To many people it's an acceptable one. > I think that you've missed the point of ssh/scp. ... > What it does provide is an encrypted link between two hosts No, I haven't missed the point at all. ssh will provide an encrypted link, true, but all that does is protect you against eavesdroppers on the network. The other part of the security is *authentication*. If you have a passwordless key that is accessed by someone else (i.e. authentication failure on the source machine permits it) you have given them valid authentication for the target machine as well. The encryption of ssh is irrelevant here. Now, in practice most people don't bother with these sorts of things. They just take the defaults, go passwordless, and carry on. That's fine if all the machines involved are "yours". However, if any of them are not yours - your customers', your employers', or even shared-responsibility with your friends - then you should be aware of the risks, and know how to find out about mitigating against them. Here's an example - I have a service that frequently connects to remote machines to gather service statistics. It uses ssh to connect before talking to local service agents. The key it uses has no pasword ... but I protect the server with a number of measures - limits in the authorized_keys file to say that the ssh connection can only open a tunnel, and that to only one port, and a 'false' shell for the user. $ cat authorized_keys from="202.37.218.10",command="/bin/false",no-pty,no-X11-forwarding,no-agent-forwarding,no-port-forwarding,permitopen="localhost:4949" ssh-dss AAAAB3Nz....(actual key here) > as opposed to telnet/ftp which is all cleartext As is the majority of users' POP3 collection of email. And generally that's the same username/password as the ISP accepts for other things, like actual chargeable dial-up time. Go figure. -jim
