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

[Cameron Simpson]

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?

I have a script called sshto with accepts targets like this:

host1!host2!host3

and constructs the requisite ssh ProxyCommand options to do a multihop
ssh to host3 to run a command. Very useful if connecting to firewalled
nonroutable hosts or to take a particular route through a network.

It is a particular joy to run:

rsync -e sshto foo host1!host2!host3:bah

and have things "just work".

So here I am attempting to deposit a kit onto a newly installed
nonroutable machine:

sshto cameron@accessiblehost!root@newhost blah

which works just fine. But if I call rsync with this:

rsync -e sshto -aH kit/ cameron@accessiblehost!root@newhost:kit/

what it invokes is:

sshto -l cameron@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?

Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

If NT is the answer, you didn't understand the question. - Peter Blake
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[Kevin Korb]

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

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

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?
>
> I have a script called sshto with accepts targets like this:
>
> host1!host2!host3
>
> and constructs the requisite ssh ProxyCommand options to do a multihop
> ssh to host3 to run a command. Very useful if connecting to firewalled
> nonroutable hosts or to take a particular route through a network.
>
> It is a particular joy to run:
>
> rsync -e sshto foo host1!host2!host3:bah
>
> and have things "just work".
>
> So here I am attempting to deposit a kit onto a newly installed
> nonroutable machine:
>
> sshto cameron@accessiblehost!root@newhost blah
>
> which works just fine. But if I call rsync with this:
>
> rsync -e sshto -aH kit/ cameron@accessiblehost!root@newhost:kit/
>
> what it invokes is:
>
> sshto -l cameron@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?
>
> Cheers,

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Kevin Korb Phone: (407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc. Ke...@FutureQuest.net (work)
Orlando, Florida k...@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/

iEYEARECAAYFAk6e7lUACgkQVKC1jlbQAQdrQgCdHMFHsrheg5h3ycobenoIMHA7
7+sAoOpsUSaO5y24/3qrLPgBRsyrs/qd
=Ev0/
-----END PGP SIGNATURE-----

[Benjamin R. Haskell]

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.


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@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.

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.

--
Best,
Ben

[Cameron Simpson]

On 19Oct2011 12:02, Benjamin R. Haskell <rs...@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:

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

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

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

| 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@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@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@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@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,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

I hate to advocate drugs, alcohol, violence, or insanity to anyone, but
they've always worked for me. - Hunter S. Thompson

[Brian K. White]

I think it's not reasonable to expect complex muti hops like that to
work. For instance, they only work for you because you just luckily
happen to be using all the same kind of tool for all hops.

It's not a common case. Would your trick work if any of the hops had to
be rsh or telnet or serial? If any of the hops used a nonstandard tcp port?

I do agree I'd rather rsync didn't try to parse anything it didn't have
to. Maybe I don't think this situation is general enough to go out of
the way to support, but I do agree it's undesirable to go out of the way
to break it without some specific reason, and a reason that's overall
worth more.

--
bkw

[Cameron Simpson]

On 19Oct2011 22:14, Brian K. White <br...@aljex.com> wrote:
| On 10/19/2011 6:58 PM, Cameron Simpson wrote:
| >On 19Oct2011 12:02, Benjamin R. Haskell<rs...@benizi.com> wrote:
| >| 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@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@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@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?
|

| I think it's not reasonable to expect complex muti hops like that to
| work. For instance, they only work for you because you just luckily
| happen to be using all the same kind of tool for all hops.

Within the same administrative domain it is entirely reasonable.
The very name of the script "sshto" says I probably expect ssh all the way.

Out of curiosity, how many non-ssh rsync setups have _you_ encountered
in the wild? (Ignoring "rsync daemon" stuff.)

| It's not a common case. Would your trick work if any of the hops had
| to be rsh or telnet or serial? If any of the hops used a nonstandard
| tcp port?

Do people use rsync over telnet? I concede that telnet accepts -l and
doesn't accept user@host. But is this a real world example?

A nonstandard port is indeed not addressed unless there's a handy
ssh_config clause.

| I do agree I'd rather rsync didn't try to parse anything it didn't
| have to. Maybe I don't think this situation is general enough to go
| out of the way to support, but I do agree it's undesirable to go out
| of the way to break it without some specific reason, and a reason
| that's overall worth more.

Well, I've modified my script to unmangle rsync's overparsing, so my
particular problem is resolved. But I think reading extra structure into
the [user@]host: part is a misfeature at best.

Cheers,
--
Cameron Simpson <c...@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

What if you are underpaid? Know the joy of being worth more than you get -
the pure joy of unrecognized superiority. - Rev. S. M. Smith

[Benjamin R. Haskell]

On Thu, 20 Oct 2011, Cameron Simpson wrote:

> On 19Oct2011 12:02, Benjamin R. Haskell <rs...@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?

No. But, why do you have so many ad hoc chains of hosts in the first
place? I don't fully understand the use case, I s'pose.

You can replace: 'Host newhost' with 'Host *.inaccessible.subnet'.
That's what the %h:%p affords (%h = host, %p = port).

> So when I go:
>
> for h in a b c d e; do sshto transithost!$h do_foo; done
>
> you find it easier to make a bunch of ssh config clauses first, each
> with cool distinctive names? I salute your typing skills.

Host newhost
in the example ssh/config becomes:
Host a b c d e

and

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

becomes:
for h in a b c d e; do ssh $h do_foo; done

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

That, on the other hand, is a valid rationale.

> | 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@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@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@host. Which they do.

Rsh doesn't.

$ rsh root@localhost
rcmd: getaddrinfo: No address associated with hostname

(Tested under Gentoo Linux and FreeBSD.)

> | 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.

At the time the feature was introduced (it's in the first revision that
made it into git, so, pre-1996), the point wasn't to insert arbitrary
commands, it was to allow the use of alternatives to rsh. Probably
remsh, a tool that provided an alternative to rsh. Later, ssh, another
tool that could replace rsh, and which understood `-l $user`.

> Having rsync pull out the user doesn't _help_ rsh or ssh, both of
> which has always (AFAIR) accepted user@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?

Using "real" rsh, apparently.

--
Best,
Ben

[Kevin Korb]

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

On 10/19/11 18:58, Cameron Simpson wrote:
> On 19Oct2011 12:02, Benjamin R. Haskell <rs...@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@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@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@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@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. Ke...@FutureQuest.net (work)
Orlando, Florida k...@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-----

[Kevin Korb]

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

I should also point out that I am not making up cool distinctive names
for my config file. I am using that actual host name of the system that
I am trying to connect to so that I can type 'ssh hostname' as if I were
plugged into the LAN that it was on.

I can sit at my house with my 172.22.100.0/24 private IP, type 'ssh
hostname', and end up logged into a server at work with a
192.168.42.0/24 private IP. I got there by actually connecting to a
real internet IP address/host name but I don't have to specify that
every stinking time I want to ssh.

On 10/19/11 23:58, Kevin Korb wrote:
> you find it easier to make a bunch of ssh config clauses first, each
> with cool distinctive names? I salute your typing skills.

- --
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
Kevin Korb Phone: (407) 252-6853
Systems Administrator Internet:
FutureQuest, Inc. Ke...@FutureQuest.net (work)
Orlando, Florida k...@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/

iEYEARECAAYFAk6fnqMACgkQVKC1jlbQAQfJDQCg1l7BELx2r2LLHKJtoxKhGjQp
liwAoO2frxZgcmMFGXaXsWdQzD3yqqpx
=+dPN

[Brian K. White]

On 10/19/2011 11:38 PM, Cameron Simpson wrote:
> On 19Oct2011 22:14, Brian K. White<br...@aljex.com> wrote:

> | On 10/19/2011 6:58 PM, Cameron Simpson wrote:
> |>On 19Oct2011 12:02, Benjamin R. Haskell<rs...@benizi.com> wrote:
> |>| 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@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@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@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?
> |

> | I think it's not reasonable to expect complex muti hops like that to
> | work. For instance, they only work for you because you just luckily
> | happen to be using all the same kind of tool for all hops.
>
> Within the same administrative domain it is entirely reasonable.
> The very name of the script "sshto" says I probably expect ssh all the way.

Your use case description in no way implies using the same protocol and
the same client app on each hop. Every single hop from one box to
another, implies a new chance for that hop to work differently from
others. Just because ssh is common really means nothing.

You are arguing the option should be more generic than it is, for the
good of all, not to unnecessarily break unpredicted use cases.

Yet are ok with it only working for what you happen to need, assuming
standard ssh all the way, because that's all you need.

You have to pick one or the other philosophy or else no one has to care
what you want because it just means you want what you want like everyone
else. I want lots of stuff but I don't ask for it unless it might be
generally useful for anyone.

> Out of curiosity, how many non-ssh rsync setups have _you_ encountered
> in the wild? (Ignoring "rsync daemon" stuff.)

For several years I used rsync regularly between SCO Open Server boxes
that had no ssh, and could not have it either, but did have rcmd. (on
SCO "rsh" is a plain old local /bin/sh with restricted features for
reduced privilege sessions. What linux calls rsh, sco calls rcmd.) I
either used -e rcmd --rsync-path=/usr/local/bin/rsync, or compiled my
own rsync with those options set as default.
http://www.aljex.com/bkw/sco/#rsync

Most of those boxes have died by now, but so what?
Also, it's only most, not all.

> | It's not a common case. Would your trick work if any of the hops had
> | to be rsh or telnet or serial? If any of the hops used a nonstandard
> | tcp port?
>
> Do people use rsync over telnet? I concede that telnet accepts -l and
> doesn't accept user@host. But is this a real world example?

More importantly, some telnet clients and some telnet servers can be
made 8-bit clean, but generally require options or run-time command-mode
commands that rsync can't do. But if rsync were more generic in this way
it could. Then again I could always write a wrapper script that would
work. There is also telnet-ssl.

With kermit I can make an 8 bit clean and error correcting serial
connection too, though I've never actually tried to run rsync over it,
but I'm pretty curious about it now that I say it. Heck I wonder if
rsync even needs the error-correcting part.

The occasion hasn't occurred yet where I had serial console access to a
remote box, could not restore normal network access, and needed to
transfer more files than plain whole-file zmodem over 115k was fine for.
But I'd love to have such a thing as rsync over serial without ppp in my
toolbox of magic exotic guru tricks.

But my point was as stated above, just that assuming a single protocol
for all hops is no nicer than assuming a single hop. Whether there are 5
or more possible connection types or just 2 is unimportant. Any day
someone may make up a new one.

> A nonstandard port is indeed not addressed unless there's a handy
> ssh_config clause.

>
> | I do agree I'd rather rsync didn't try to parse anything it didn't
> | have to. Maybe I don't think this situation is general enough to go
> | out of the way to support, but I do agree it's undesirable to go out
> | of the way to break it without some specific reason, and a reason
> | that's overall worth more.
>
> Well, I've modified my script to unmangle rsync's overparsing, so my
> particular problem is resolved. But I think reading extra structure into
> the [user@]host: part is a misfeature at best.
>
> Cheers,

--

bkw

[Brian K. White]

On 10/20/2011 12:08 AM, Kevin Korb wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> I should also point out that I am not making up cool distinctive names
> for my config file. I am using that actual host name of the system that
> I am trying to connect to so that I can type 'ssh hostname' as if I were
> plugged into the LAN that it was on.
>
> I can sit at my house with my 172.22.100.0/24 private IP, type 'ssh
> hostname', and end up logged into a server at work with a
> 192.168.42.0/24 private IP. I got there by actually connecting to a
> real internet IP address/host name but I don't have to specify that
> every stinking time I want to ssh.

Some of us ssh from random machines to other random machines.
Some ssh servers and clients are on appliances that are either
impossible or completely impractical to configure ~/.ssh/* or don't even
have any such thing as ~/.ssh/* in fact openssh is not even the only ssh
server or client even when you are dealing with a unix-like system.

Configuring ~/.ssh/* is nice in some cases, and utterly impractical, or
not even possible in others.

The OP's question was not about other ways to use ssh but why rsync
couldn't allow the user to supply an unpredicted type of url that they
happen to know would work if rsync would just not try to parse it but
just collect it and and hand it off.

> On 10/19/11 23:58, Kevin Korb wrote:
>> you find it easier to make a bunch of ssh config clauses first, each
>> with cool distinctive names? I salute your typing skills.
>
> - --
> ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
> Kevin Korb Phone: (407) 252-6853
> Systems Administrator Internet:
> FutureQuest, Inc. Ke...@FutureQuest.net (work)
> Orlando, Florida k...@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/
>
> iEYEARECAAYFAk6fnqMACgkQVKC1jlbQAQfJDQCg1l7BELx2r2LLHKJtoxKhGjQp
> liwAoO2frxZgcmMFGXaXsWdQzD3yqqpx
> =+dPN
> -----END PGP SIGNATURE-----

[Kevin Korb]

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

OK then...

Because it would break an officially supported use case (rsh). It would
also break the lsh utility included with rsync (in the support dir).
The --rsh parameter is for specifying alternative remote shells that are
command line compatible with rsh.

In this discussion we have 2 well known use cases plus a basic design
feature verses a single user's custom solution that could probably be
easily re-customized to be rsh command line compatible.

iEYEARECAAYFAk6gE/4ACgkQVKC1jlbQAQeszgCgn7mWokNiLD9WMJlTxOrLdWoT
BOkAn2YfwA4cP8QejqVHizvtrDC3jDaX
=2ZXJ
-----END PGP SIGNATURE-----