Hello Lachlan,
Lachlan Cranswick wrote:
> (Before waffling on a side tracked issue - there is still a
> request for good web based passwordless ssh tutorials)
I don't really have anything to offer -- I learned some about public /
private key systems over a lot of years starting with a signature system
for signing contractor time sheets ~10 years ago (using an RSA
product). I'm starting to use ssh to communicate with SourceForge, but
the tutorials they have are focused on how to use ssh rather than
"security theory".
The remote machine can only confirm that someone/anyone
> has the correct key file. (authorised user or someone else - a
> hacker/cracker)
You're right about that. Having it on my own machine makes me feel
fairly secure, but ...
> So rather than only giving a hacker passwordless limited
> access to the rsync function on a remote machine - the hacker
> is getting complete access via ssh.
At least (or only) to everything he is privileged to do on that remote
machine.
> (Isn't having private key files like putting your pin
> number with your VISA/Mastercard/Cashcard? If the hacker
> gets into your machine (or a backup tape/cd-rom) and gets
> the private file?)
Yes, if he get into your machine. If your machine is in a semi-public
place (like a business or school), this could be more of a problem than
if you have control of physical access to your machine.
I'd have to think some more about your next two paragraphs -- I may
respond later. I guess, recognizing that the developers of rsnyc don't
have unlimited resources, I'd rather see them concentrate on rsync than
be diverted to incorporate ssh into rsync.
Not fully understanding the ramifications of chroot (as a Linux newbie)
I don't really know whether limiting someone's access by chrooting is
any more effective than limiting his access based on privileges provided
to his account. Probably will give me something to learn about over the
next several months. ;-)
> I would thus still put the argument that having an ssh
> system inside rsync could be very effective as
> if a client machine is hacked/cracked and rsync passwords
> are obtained - they are chrooted to some extent to
> what the rsync permissions will allow in terms of
> uploading and downloading files. Or at minimum - the
> hacker is in a more frustrated situation with respect
> to using these rsync passwords to "crack" a remote
> machine. However if they get the ssh private file -
> (which in the case of this discussion - was only generated
> to allow for secure rsync) then the world is their oyster(?)
>
> Having ssh inside rsync also means that only an rsync
> account has to be provided on the server rather than a complete
> ssh user account. One problem with UNIX is its
> habit of giving "all or nothing" when you may want
> something in between. (In this case only having an rsync
> based account)
>
> Lachlan.
>
> PS: If keeping rsync small is a priority for some people -
> compiling in an ssh module could be an option - as is done
> with apache modules to expand functionality.
If people feel ssh is essential, I would prefer that it be a module.
Thanks for the response!
Randy Kramer
