On Tue, Mar 06, 2001 at 02:10:18AM +1100, Martin Pool wrote:
> On 5 Mar 2001, Dave Dykstra <[EMAIL PROTECTED]> wrote:
>
> > Proposed patch to implement ssync follows. I decided to go ahead
> > with the shell script idea. Unless I hear objections, I'll figure
> > on submitting this to rsync CVS in a day or two.
>
> I think we should have a AC_ARG_WITH option to set the default
> RSYNC_RSH, although unlike my patch we should be careful to make it
> default to the current behaviour.
Ok with me.
However, I think it's not such a good idea to encourage people to begin to
migrate the default RSYNC_RSH to ssh because then people won't know what to
expect when they move between systems.
> However, I really don't think we should ship ssync, as it pollutes the
> command namespace to deal with a problem that I think is quite
> specific to your site, and that is likely to go away over the next
> couple of years.
I'm sure that many other people will have the same issue.
By next couple years I expect you mean that by then everybody will be
compiling in ssh as the default RSYNC_RSH, but I don't think that's going
to happen. If you're on a restricted network, RSH works just fine and it
is faster, so I don't think it's going to go away completely. Also, when
IPSEC and DNSSEC are finally deployed it's not clear that much of SSH's
functionality is going to be needed anymore. I actually expect RSH with
additional authentication mechanisms + IPSEC + DNSSEC to be the standard in
the future. Solaris 8 already comes with a Kerberized RSH.
> There are lots of different default arguments that people might like
> as well as -e ssh, but it's just not good style to create new
> top-level commands when options will do just as well.
'-e ssh' is not just one of many ordinary default arguments. I'm talking
about a mindset change that fits right in with a precedent of 'r'* commands
being secure drop-in replacements of 's'* commands.
> By all means put the script into the FAQ, or a doc/examples/
> directory, but my preference is that it not be in the main system.
If it's not in the standard package I won't use it because I want people to
only rely on standard things, and I want to avoid future potential
nameclashes. I suppose I could make a whole separate package on
sourceforge and registered on freshmeat but I'm not sure I'm willing to go
that far (although I was planning on at least registering the name on
freshmeat). Please ask Tridge what he wants to do now. He previously said
it was ok with him, but maybe he's changed his mind. I'll abide by his
decision.
> By the way, I'm pretty sure you can make sshd behave as an exact
> superset of rshd to allow a smooth(er) transition. Won't something
> like
>
> /etc/ssh/sshd_config:
>
> RhostsAuthentication yes
> IgnoreRhosts no
>
> mean that for a particular situation if rsh does not need a password,
> then ssh will not either?
I could do that but I don't want to because the host keys are currently
vital for good security and is the direction I want everybody to migrate
to; they are supposed to give up RSH in favor of SSH over the next couple
years. But, like I said, I expect that RSH is eventually going to come
back into favor, probably a few years after that.
- Dave Dykstra
