[ On Mon, January 25, 1999 at 12:02:19 (-0800), Joe Rhett wrote: ]
> Subject: Re: How do I sz/rz under an ssh connection?
>
> > Wait a minute here.  If you have to "log out and log back in again"
> > around each transfer then you're doing something wrong.  SSH, like rsh
> > before it, and even FTP, works perfectly fine, in parallel with your
> > current login session.  It should be possible to invoke it from either
> > end
>       ..
> > This should all be possible even if you're connected to your local
> > computer with a "dumb" terminal.
> 
> It _should_ be possible .. that is the nature of my arguement. If it is
> possible, I've never seen documentation of how.

Normally such information is embedded in the lore of how to use your
particular environment.  I'm still not sure what your particular
environment really is, so it's hard to describe how you you might go
about this in detail.

If I had to use a dumb terminal, connected to a local unix host, to
slogin to another remote unix host and then transfer files back and
forth, but with the restriction that I wasn't able to use either
~/.shosts or a blank RSA pass-phrase to authenticate myself, then I'd
use "screen" to set up at least two session "windows", one being on the
local host, and the other running "slogin remote".  Then every time I
had a collection of files to transfer I would use either the local shell
session, or the slogin session, as appropriate, to initiate a single
"scp" command to transfer the entire batch of files (the "as
appropriate" part means whichever end makes the easiest filename
expansion pattern).  If I had to do this more than a couple of times,
and especially if the filenames were difficult to type all on one
command-line, then I'd write a simple one or two line script to do it
all.

Of course this is very hypothetical because *I* wouldn't regularly use a
remote system in such a way if it didn't let me initiate SSH connections
that didn't require a password.

In the one case where one of my clients required a crypto-card for
passage in through their firewall I easily convinced them that it was
safe to allow outbound SSH connections without restriction.  Since I was
willing to allow inbound SSH connections on my network I would then
telnet to their firewall, authenticate myself with the crypto-card,
login to the internal server, and then slogin or ssh or scp back to my
own network as necessary (using "screen" to manage multiple slogin
sessions which I used to avoid flow control problems when using
tunnelled X11 connections).  That initial connection could even have
been via a dial-up modem from a dumb termainl or any other type of login
session through any medium, but of course it was easiest with telnet.

> > Of course if you've got any kind of
> > multi-"window" environment at your "workstation" then you should be able
> > to have one or more a command-line sessions running on each end (even
> > with multiple slogin connections!), and life will be even more exciting
> > and versatile (and of course this kind of environment can be emulated
> > using job control or tools such as screen on Unix clients).
>  
> Of course. This is _not_ the point. The point relates to multiple file
> transfers over a single connection. Why can't I use my existing connection
> to perform this transfer?

You can.  Use port forwarding SSH tunnels.  That's the primary reason
SSH provides them.  They are it's answer to the "single login" issue.

> > SSH is a _network_ tool, not a modem tool.  It need not be restricted to
> > opening one connection at a time or even to transfering one file at a
> > time (that's just a limitation of bandwidth and latency).
> 
> Indeed, it need not. But if it isn't limited to transfering in sessions 
> distinct from the login session, please let me know what I'm missing.

Port forwarding.  Once you've made that leap you can do anything.  Some
people even tunnel PPP through SSH.  I run X11 clients through SSH all
the time, but that's easy because SSH normally sets this up automatically.

Just be warned that there is no flow control implemented in the SSH v1.x
protocol, and I've found that almost all implementations of this
initial experimental protocol revision lock up when you try to do too
many things at a time through one connection.  SSH v2 is supposed to
correct this, but I've not yet tried it.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <[EMAIL PROTECTED]>      <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>

Reply via email to