Your requirements #5 (no third-party/cloud storage) and #6 (no
IP/hostname disclosure) are in mutual conflict: to transfer a file to
a remote computer, you either make a direct connection or you don't.
If you do, the remote end will have your IP address (just because of
the way TCP/IP works); if you don't, then by assumption you are
relaying on a third party to do the transfer and they have to store
your data.
That said, there are a few approximations to your request.
F*EX: using web-based 3rd party transfer
The F*EX server was born exactly
for this purpose. From the fex package description:
F*EX (Frams's Fast File EXchange) is a service that can be used to allow users anywhere on the Internet to exchange very large files quickly and
conveniently.
The sender uploads the file to the F*EX-server and the recipient automatically gets a notification e-mail with a download-URL.
Main features of F*EX:
- file transfer of virtually unlimited file size
- sender and recipient only need an e-mail program and a web browser (of any kind; they do not have to install any software)
[...]
- maintenance-free: no administration necessary beyond creating new F*EX accounts
- multiple recipients only require one stored copy
- F*EX uses HTTP and needs no firewall tunnels
- shell clients provided for commandline users:
fexsend and fexget. (fex-utils package)
As far as I understand, F*EX does not do encryption natively, but you
can just encrypt the file you want to send with GPG.
The F*EX server is entirely opens-sourced, so you just install and run
it on a server you trust.
The F*EX homepage explains in detail
how F*EX compares with other file transfer services and protocols.
sendfile: asynchronous file transfer across UNIX computers
The sendfile command has been
around for about 10 years: you install it and and the accompanying
daemon on both the sending and the receiving end, and then the
transfer is as easy as typing:
sendfile a.file user@otherhost
In addition, sendfile can automatically encrypt the file using GPG
(look for the -pe and -ps options).
Since this makes a direct connection, however:
- the receiving computer must be up and running at some point,
- it will have to be able to accept connections on the
sendfile port, which means it should be reachable through a public IP
- it can log the senders' IP address
sendfile
was written by the same authors of F*EX (see above), and they explain
the reasons why they chose to switch to an HTTP-based 3rd-party
service on the sendfile homepage
do-it-yourself: use nc
It's relatively easy to do the file transfer using only
netcat.
On the receiving side, you run:
nc -l 9999 > myfile
After that, on the sending side, you run:
nc otherhost 9999 < myfile
As usual, you should encrypt the file with GPG before sending (or you
can do that on-the-fly with a pipe, if you are confortable with the
shell). You can substitute the 9999 with any other valid port
number (for instance, to make several transfers at once).
Disadvantages:
- coordination: you must issue the two commands on the two ends in the right order, so both the sender and the receiver must be online at the same time, and they must coordinate over, e.g., a chat or telephone line.
- it will have to be able to accept connections on the 9999 port, which means it should be reachable through a public IP
- the receiving end can log your IP address
software-recommendationso we can get more people looking at this. – jrg♦ Oct 15 '11 at 12:36