FBRIDGE is a service that acts as a bridge between two file transfer protocols: RSCS/JNET to FTP. It is a virtual machine (daemon) on MITVMC, but you do not need logon access to MITVMC to use it. With FBRIDGE, you can transfer a file from a hypothetical Machine A, having access to RSCS or JNET but not the Internet, to a Machine B, having access to the Internet but not to RSCS or JNET.
Note: We no longer have machines connected to each other via RSCS/JNET that do not also have an internet connection. Thus, there is no need to use FBRIDGE anymore. It should be possible to encrypt a file with PGP and transfer it directly to the remote computer using FTP without using FBRIDGE in the middle. However, since existing legacy systems still use this service, we include the documentation below.
To use the service, use the SENDFILE command (RSCS) or SEND command (JNET) to transfer a file to FBRIDGE@MITVMC. FBRIDGE looks up the file's sender and filename/filetype in its table, and if the file matches a table entry, it invokes FTP to transfer the file to the machine and directory listed in the table entry. The table entry can include a pass phrase to be used to encrypt the file with PGP prior to the FTP transfer.
For file transfers in the other direction, i.e., from FTP to RSCS/JNET, see RBRIDGE.
Before using FBRIDGE to transfer a file, you must have a table entry set up in FBRIDGE's Files Table. A table entry must be set up by a system programmer in O&S's VM System Services Team. (Contact Jim Repa, repa@mit.edu, 3-4109.) Each file in the table must have a CMS-style file descriptor of the form filename.filetype, where filename and filetype are 1-8 character alphanumeric strings. A table entry can contain a wildcard character in the filename, filetype or both, so a single entry can apply to more than one file.
A table entry in FBRIDGE's Files Table has the following fields
FILENAME filename of the file to be sent to FBRIDGE. Can be a
wildcard character (@) or contain a trailing @
FILETYPE filetype of the file to be sent to FBRIDGE. Can be a
wildcard character (@) or contain a trailing @
FROMNODE the name of the node or site of the sender of the file
FROMUSER the userid of the sender of the file
FTPSITE the Internet site to which to PUT the file via FTP
FTPUSER the userid to use for the FTP connection
FTPPW the password to use for the FTP connection
FTPPATH the remote pathname for the FTP file transfer
MAILADDR the E-mail address of person to be notified of successful
or unsuccessful file transfers
PASSPHRASE the pass phrase to use for encrypting the file prior to
transfer. The pass phrase can either be NONE, for no
encryption, or a string of 1 to 20 characters with no
blanks. The 20-character, no-blank restriction is a
limitation of FBRIDGE.
The following is an example of an FBRIDGE table entry.
FILENAME FILETYPE FROMNODE FROMUSER FTPSITE FTPUSER valued data mitsis joeuser mitdir.mit.edu janeuser FTPPW FTPPATH MAILADDR PASSPHRASE sesame /usr/mydir/dropfiles freddy1@mit.edu a.big.secret
The use of PGP encryption for files transferred with FBRIDGE is highly recommended. Without encryption, your data is vulnerable to attack while FBRIDGE does the FTP transfer. Network intruders could intercept or tamper with your data. Also, the FTP password used can be intercepted by network sniffers, whether or not you encrypt your file. However, if the table entry for your file has been configured to do encryption, you can verify that a file transferred by FTP has been encrypted with the secret key, and thus avoiding interception or tampering with your data.
If you choose to use encryption, you have two options. First, you can send a file to FBRIDGE unencrypted and have FBRIDGE encrypt it before doing an FTP transfer. The RSCS/JNET file transfer, if done between computers at MIT, does not use MITnet, and is much safer than the FTP stage. Second, you could encrypt the file prior to doing the FTP transfer to FBRIDGE, and do not have FBRIDGE do any additional encryption. This protects the file during the RSCS/JNET transfer as well as the FTP transfer stages. We describe the first option below.
To avoid the complexity of maintaining PGP keyrings, FBRIDGE uses the "conventional" encryption option of PGP. With this option, the same pass phrase is used for encryption and decryption, and this pass phrase can be specified on the command line for the PGP command.
Use the following PGP command line to decrypt a file after it has been transferred with FBRIDGE:
PGP encrypted.file -z "passphrase" +batchmode +force
where: encrypted.file is the name of the encrypted file
-z "passphrase" specifies the pass phrase
+batchmode tells PGP that this is a batch rather than
interactive use of the program, i.e., do not
prompt the user with any unnecessary
questions or prompt for alternate filenames
+force tells PGP to write over an existing output
file with the same name without confirmation
If the file was originally encrypted with the same pass phrase, PGP will decrypt the file and write it out with the original filename in the current directory.
RBRIDGE facilitates file transfers in the opposite direction from FBRIDGE. It provides a bridge from FTP to RSCS/JNET. It is a service virtual machine on MITVMA, but you do not need to log onto MITVMA to use it. The tool can be used to transfer a file from Machine B (having Internet access but not RSCS/JNET) to Machine A (having RSCS/JNET but no Internet access).
Note: We no longer have machines connected to each other via RSCS/JNET that do not also have an internet connection. Thus, there is no need to use RBRIDGE anymore. However, since existing legacy systems still use this service, we include the documentation below.
A user would use FTP to put a file into the POOLA:RBRIDGE.DROPBOX directory on MITVMA. Optionally, the user could encrypt the file with a previously agreed-upon pass phrase before transferring it with FTP. The RBRIDGE virtual machine periodically scans its POOLA:RBRIDGE.DROPBOX directory for new files, and when it finds one, it looks up the filename/filetype in a table. If the filename/filetype matches a table entry, it optionally decrypts the file (rejecting it if the file was not encrypted with the right pass phrase), and then uses RSCS to transfer the file to the userid and machine listed in the table entry.
For file transfers in the opposite direction, from RSCS/JNET to FTP, see FBRIDGE.
Before using RBRIDGE to transfer a file, you must have a table entry set up in RBRIDGE's Files Table. A table entry must be set up by a system programmer in O&S's VM System Services Team. (Contact Jim Repa, repa@mit.edu, 3-4109.) Each file in the table must have a CMS-style file descriptor of the form filename.filetype, where filename and filetype are 1-8 character alphanumeric strings. A table entry can contain a wildcard character in the filename, filetype or both, so a single entry can apply to more than one file.
A table entry in RBRIDGE's Files Table has the following fields
FILENAME filename of the file to be sent to RBRIDGE. Can be a
wildcard character (@) or contain a trailing @
FILETYPE filetype of the file to be sent to RBRIDGE. Can be a
wildcard character (@) or contain a trailing @
DEST-NODE the RSCS/JNET node (computer) to which to send the file
DEST-USER the username on DEST-NODE to whom to send the file
DEST-FN RBRIDGE can rename the file before sending it. This is the
filename to which to rename the file. Specify = to keep
the original filename.
DEST-FT RBRIDGE can rename the file before sending it. This is the
filetype to which to rename the file. Specify = to keep
the original filetype.
MAILADDR the E-mail address of person to be notified of successful
or unsuccessful file transfers
PASSPHRASE the pass phrase to use for decrypting the file prior to
transfer. The pass phrase can either be NONE, for no
decryption, or a string of 1 to 20 characters with no
blanks. The 20-character, no-blank restriction is a
limitation of FBRIDGE.
The following is an example of an FBRIDGE table entry.
FILENAME FILETYPE DEST-NODE DEST-USER DEST-FN DEST-FT vip data mitsis joeuser = = MAILADDR PASSPHRASE barney1@mit.edu a.nother.secret
The use of PGP encryption prior to transferring files to RBRIDGE is highly recommended. Without encryption, your data is vulnerable to attack as you transfer the file to RBRIDGE with FTP. Network intruders could intercept or tamper with your data. Also, file transfers to RBRIDGE are done with anonymous FTP, so anyone can transfer any file to RBRIDGE. The only way that RBRIDGE has of knowing if the file came from an authorized user is if it has been encrypted; only an authorized user should know the valid pass phrase for encrypting a given file.
If you choose to use encryption, you must encrypt the file prior to transferring it to RBRIDGE with FTP. After that, you have two options. You can have RBRIDGE decrypt the file before transferring it to its final destination with RSCS/JNET, or you can have RBRIDGE leave the file encrypted during the RSCS/JNET transfer stage. The FTP stage is much more vulnerable to attack than the RSCS/JNET stage, so having RBRIDGE decrypt the file for you may be a desirable option. This is the option we describe below.
To avoid the complexity of maintaining PGP keyrings, RBRIDGE expects the file to have been encrypted with the "conventional" option. With this option, the same pass phrase is used for encryption and decryption, and this pass phrase can be specified on the command line for the PGP command.
Use either of the following PGP command lines to encrypt a file prior to transferring it to RBRIDGE with FTP:
PGP -cta cleartext.file output.file -z "passphrase" +batchmode +force +armorsize 100000
PGP -ct cleartext.file output.file -z "passphrase" +batchmode +force
where: -c tells PGP to do conventional encryption
-t tells PGP to treat the file as a text file.
This is ESSENTIAL if you want RBRIDGE to
decrypt the file.
-a optional parameter that tells PGP to produce
7-bit ASCII output, similar to BINHEX.
output.file This is an optional parameter. Use it to
pick the name of the output file. Without
it, PGP will pick a name for you.
-z "passphrase" specifies the pass phrase
+batchmode tells PGP that this is a batch rather than
interactive use of the program, i.e., do not
prompt the user with any unnecessary
questions or prompt for alternate filenames
+force tells PGP to write over an existing output
file with the same name without confirmation
+armorsize n tells PGP how many records to include per output
file. (If PGP encrypts a large file, by default,
it will split it up into several small output
files. The default for n is 720, meaning PGP
will split up the output if it exceeds 720
80-byte records. Use a large number here to avoid
having the output split into multiple files.)
Whether or not you use the -a option on the PGP command determines whether or not you should do a BINARY transfer of the file in FTP. See the notes section below.
FTP MITVMA.MIT.EDU
USER ANONYMOUS
CD POOLA:RBRIDGE.DROPBOX
BINARY note: Only use this if you specified -ct and
not -cta when you encrypted the file with PGP
PUT your.file
QUIT
Last changed January 24, 2002