why does rsync translate user at host into '$RSYNC_RSH -l user host'?

[Kevin Korb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/19/11 18:58, Cameron Simpson wrote:
> On 19Oct2011 12:02, Benjamin R. Haskell <rsync at benizi.com> wrote:
> | On Wed, 19 Oct 2011, Kevin Korb wrote:
> | >Because it is an even bigger joy to be able to type 'ssh newhost'
> | >and have it just work even though you can't talk to newhost.  You
> | >can do that by properly configuring ssh in ~/.ssh/config with
> | >something like this:
> | >
> | >Host accessiblehost
> | > User cameron
> | >
> | >Host newhost
> | > ProxyCommand ssh accessiblehost -W %h:%p
> | > User root
> | 
> | +1.  Seems easier than a DIY script.
> 
> You guys are kidding, surely? You hand edit your ssh configs for every
> ah doc chain of hosts you might want? So when I go:

Absolutely.  If I need ssh parameters to connect to a particular sshd
then I absolutely refuse to type them more than twice.  I will type them
once to figure out what I need then I will type them into the
configuration file.  I consider this to be "properly configuring ssh".
To do otherwise is like having a lobotomy every time the shell prompt is
printed.

> 
>   for h in a b c d e; do sshto transithost!$h do_foo; done

well, I don't do bash so I will respond in csh:
foreach Host in (a b c d e)
  ssh $Host do_foo
end

More importantly when I want to ssh to host "a" I simply type 'ssh a'
and it knows what username, port number, compression, and any other
thing I might need with me only needing to tell it once.

> 
> you find it easier to make a bunch of ssh config clauses first, each
> with cool distinctive names? I salute your typing skills.

My ~/.ssh/config file is currently 94 lines long including comments and
blank lines.  Yet it specifies special configurations for hundreds of
host names.

> 
> (Besides, I wrote my first sshto tool before the ProxyCommand directive
> existed.)

That is completely valid.  It is now up to you which is the easier
system to maintain.

To be completely fair...
I do not actually use the ssh_config syntax that I sent you.  I only
have 1 inaccessible network that I ever have to ssh to.  It is a private
IP NAT at work that handles some administrative systems.  Since I
control the NAT system I forward TCP ports to each system.  The private
range is 192.168.42.0/24 and I configured the NAT router to forward TCP
ports 22xxx to 192.168.42.xxx:22.  Then I use the following ssh_config
entry format for each real system:

Host RealHostName RealHostName.fqdn
  Compression yes
  User me
  Port 22xxx
  HostName NAT_IP.RealDomain.tld
  HostKeyAlias RealHostName.fqdn

This allows me to 'ssh RealHostName' and it just works without the added
overhead of ssh tunneling.

I currently have only 15 systems configured this way.  Being a shared
web hosting provider means that most of my stuff has real IP addresses.
 In fact some of my servers have hundreds of them.  So I don't have to
deal with private network stuff much.

OTOH, my personal network is a private LAN with a single static IP on
the Internet.  When I venture out into the world carrying my netbook I
use OpenVPN to bridge myself back into my LAN so I can talk whatever
protocols I want (including NFS) to my private IPs.

So, while I don't really know what your universe is like I still think
you are doing things the hard way.

> 
> | But to answer the original question:
> | 
> | >On 10/19/11 03:40, Cameron Simpson wrote:
> | >>Why does rsync believe it knows more about the use of the token
> | >>to the left of the colon than the program which will be used as
> | >>the remote connection?
> | >>
> | >>[...]
> | >>
> | >>what it invokes is:
> | >>
> | >>  sshto -l cameron at accessiblehost!root newhost rsync .....
> | >>
> | >>Since sshto is my own tool I can probably have it cope with this
> | >>mangling of my target string into "-l foo bah", and undo it.
> | >>
> | >>But WHY does rsync believe this is desirable, or even necessary?
> | 
> | rsync has to parse the URL you're passing.  The fact that it then
> | takes that and runs something like `$RSYNC_RSH -l user host` is
> | because rsync expects it's handing the connection duties off to
> | something that uses rsh-like calling conventions.  So, it's
> | "desirable" because rsh-like tools traditionally expect it.
> 
> But rsh-like tools _all_ accept user at host already.
> They don't "expect" the "-l" form - they cope with it.
> 
> This argument does not make it desirable unless rsh or ssh don't cope
> with user at host. Which they do.
> 
> | If rsync didn't parse the URL and split it out, each tool would have
> | to do its own {user}@{host} parsing.  So, it's not fully
> | "necessary". (Most of the tools probably do have that kind of
> | parsing.)  It just makes things easier for tools that use the '-l'
> | convention.
> 
> The point here is the rsync is presuming to know about the tool. The
> whole point of the -e and $RSYNC_RSH stuff is to use arbitrary tools.
> Having rsync pull out the user doesn't _help_ rsh or ssh, both of which
> has always (AFAIR) accepted user at host and does raise the implementation
> bar for other tools for no actual benefit.
> 
> Has anyone a use case that _breaks_ if rsync doesn't pull out what it
> imagines is the "user@" part?
> 
> Cheers,

- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6fnFAACgkQVKC1jlbQAQfUfgCeLIJe6jS0GbJRMnbrUnD19vHe
ow0AoMHxX4siBahxemcVMkVxxwXq5dEV
=WdPI
-----END PGP SIGNATURE-----