Baslinux mailing list

[Karolis Lyvens <karolisl AT gmail.com>]

On Thu, Jan 11, 2007 at 01:21:45PM -0600, James Miller wrote:
> On Wed, Jan 10, 2007 at 09:29:16PM +0000, Lee Forrest wrote:
> > We all have this nifty tcp tool called netcat (nc). About 19K
> > for the standalone utility that needs only libc. It will make
> > any kind of TCP/UDP connection and pass anything you want to the
> > other end of the connection. And accept anything you want.
> > 
> > Yet each and every client and server we have:
> > http/ftp/smtp/pop/irc/dns/irc/nntp...has the same basic code
> > built into it. Usually a much less efficient, and therefore
> > larger, version. This is a wasteful redundancy and a potential
> > security problem: Having just one discrete and tiny utility to
> > do the job makes monitoring and filtering your connections much
> > simpler. It certainly makes configuration and trouble-shooting
> > simpler.
> 
> Ok. It's high time I got meself edumacated about this netcat thing. I 
> recently began 
> discovering how to use scp and had been thinking this is the best way to 
> transfer things to 
> and from my fileserver from out on the wider 'net. But maybe netcat would 
> work even better? 
> The first thing I need to know is whether it does or needs any form of 
> authentication. Does 
> it run by default without? I.e., you just specify matching ports on client 
> and host, make 
> sure your firewall won't interfere, then initiate the transfer by IP? If it 
> doesn't do 
> authentication, it could certainly be piped through ssh, correct? But then 
> what would be the 
> advantage over scp? I did look at the manpage, btw, but input from users 
> who deploy it in 
> the real world would help me disambiguate things.

No, netcat doesn't require any authentication; it can be thought as a
neat continuation of UNIX pipe through network: you only have to specify a 
matching
host and port, and you can redirect your standard output via it; the
server part of netcat connection redirects the data he gets via that
connection to stdout. For example:

---
mkdir ncreceived && cd ncreceived && nc -l -p 1234 | tar xzvf - # On server 
side
cd dirtosend && tar czf - ./* | nc serverhost 1234 # On client side
---

will tar up the "dirtosend" directory, redirect the tarfile creation to
stdout, pipe it through netcat, which will make a basic TCP connection to
port 1234 on "serverhost" and will pipe it's stdin (in this case, data
it receives from tar) to serverhost:1234. Netcat in another side will
receive the connection and will redirect it's stdin to stdout (the same
behaviour as cat's or dd's in this case), and, in turn, shell redirects
nc's stdout to "tar xzvf"'s stdin which in turn extracts tarball it
receives via stdin to current directory. After the sending of file
is finished nc closes the connection and closes the connection. Server
part goes with it...

It was a really lenghly and oververbose explanation, but i think that
it only proves my point that netcat acts only as an extension of UNIX's pipe.

And yes, because it's only a basic TCP connection, it can be tunelled
over ssh. Advantage over scp? It is more versatile. It can be used for
any kind of data, and not only for file copying, but also for some HTTP/FTP
chats (with a shell script that can process responses, etc). If you have
a working SSH server, the only advantage would be that you can initiate
a connection and send some files via it without disclosing any passwords
or giving keys.

P.S. I sometimes curse myself for my time-wasting-and-lenghty
    explanation style which tends to eat up time when i have to type
    it...

Karolis