© Copyright Robert Vasvari, 1993-2014.
Secure Shell Protocol (SFTP-SSH)
RBrowser will always be updated to use whatever ssh/sftp
client that is distributed by Apple. Please do not change the ssh
client, or if you absolutely
have to, save the old one in a different name, and point RBrowser to it
Requirements on the client side (the machine that runs
RBrowser): There must be a working ssh client installed,
i.e. you must be able to just pull up a terminal and type
"ssh RemoteHost" and be able to connect
successfully. The standard path for this client is
/usr/local/bin/ssh. It does not matter what kind of
authentication ssh uses to connect to the remote host (RSA or
Requirements on the server side (the machine that
RBrowser is connecting to): The remote host must run
sshd, and your client machine must be authorized to
connect to it.
Why is RBrowser better than other SFTP clients?
Here is what other SFTP clients do: simply connect to an SFTP server
and use whatever is available
under that protocol. However SFTP has serious limitations:
RBrowser combines all the secure tools available on both the local and
the remote system.
The SFTP, SSH , PAX , the Bourne Shell, and SCP clients are all part
of OSX. Other UNIX systems do not have pax but have the rest. Each
have their strong points
and their limitations as well. SFTP is better for file transfers
because unlike scp it can
hold a continuous connection and create links. Ditto is used if both
hosts are macs, so fork data
is preserved during file transfers. SSH is used for file operations on
the remote hosts, since SFTP has
major limitations: for example it cannot make a copy of a file from on
folder to another on the remote
host! Also, SFTP does everything file-by-file, which takes a long time
if it operates on a big file system.
ssh, using a remote shell can do recursive file operations like rm,
chomod very fast. Direct remote-to-remote operations require SCP.
RBrowser automatically selects the best available tool for the job, so
you do not even have to think about it! So, summary of what RBrowser
gives you in secure file operations:
- No Recursive commands: SFTP does everything file-by-file,
which takes a long time if it operates on a big file system.
- No Direct Remote-to-Remote transfer
- Cannot reach hosts behind a firewall
- Cannot copy files between folders on the remote host, so
file management is problematic.
- Finder Info-Fork Data is preserved during Folder Sync or
File Transfer to another Mac
- Recursive (fast) file operations, easy remote file
- Folder Sync from the Local Host to a Remote Host using
- Remote-to-Remote File Transfers between any hosts,
regardless of protocol
- SFTP-SSH access through firewalls with tunneling
How does it work: The SFTP protocol is
implemented differently from FTP because RBrowser
actually does not contain any sftp-ssh client code. This way you are
free to choose what ssh client to use. By default, the sftp client
supplied by the system (/usr/bin/sftp) is used. So,
for each connection RBrowser establishes to the remote site,
RBrowser runs the ssh/sftp client as a subprocess in the background,
and uses that as a transport vehicle. All of this, of course,
goes on in the background; you do not have to lift a finger to get
all this into motion. Just select SSH in the protocol popup on the
Site Manager, fill out the required
fields and hit "Connect."
The first time you connect to a site using SSH, RBrowser will
look for the default ssh client (ssh) in /usr/bin.
If it is not there, you will be prompted to enter the path of the
ssh client. This path will then be stored in the
SSHClientPath default. See the Startup/Helpers tab
in Global Preferences.
It is possible your ssh site does not require a
passphrase/password, or even a username. Therefore, it is OK to
leave those fields blank. IMPORTANT: If you have
remote hosts which let you log in without a password, it is still
a good idea to supply the password, so RBrowser can use it during
remote-to-remote file transfers. If you are transferring from
HostA to HostB, HostA will ask for the password of HostB and
RBrowser will only have that if you entered it during login.
Once the connection to an SSH site is established, it acts
just like the UNIX protocol, namely that RBrowser talks to a (or
several) shell(s) on the remote host.
Remote-to-Remote Transfer Gotchas:
What is the point, you may ask, in doing a Remote-to-Remote
transfer? Sounds complicated... here is the main reason:
connectivity. If you sit on a relatively slow link and have to
move files from hostA to hostB, both of which are on a fast link
(and this is generally the case) it would be extremely time
consuming to copy everything down to your local host through that
slow link then copy everything to the destination over that same
slow link! Direct Remote-to-Remote File Transfers work very
nicely in RBrowser, as long as you observe some very simple
1. The source machine must be able to resolve the target
machine's name. If you are transferring from HOST1 to HOST2,
HOST1 must be able to resolve the name HOST2. For this reason,
always login using fully qualified hostnames, such as
HOST2.MYDOMAIN.COM that can always be resolved. If the source
host cannot resolve the target host, the transfer will just hang,
and eventually time out.
2. As described above, the username/password supplied at login
time will be used to initiate an scp connection from user1@HOST1
to user2@HOST2. If you use special RSA keys while logging on to
user2@HOST2, it is possible that those RSA keys do not work
coming from user1@HOST1.
Remote-to-Remote Advanced Options:
Here is what happens in the general case during a direct
remote-to-remote transfer: RBrowser allocates a connection to the
source of the transfer and initiates an scp transfer to the
destination host directly. This means that the destination must
be reachable (i.e. not blocked by a firewall) and a login from
the source must be permitted. When this transfer starts, the
source host is asked to authenticate itself, usually by supplying
a password. By default, the password that you supplied when you
logged on to the destination is used for this purpose. As pointed
out above, this may not always work, since with ssh you can have
a private login arrangement between two hosts that allows access
without [the appearance of] an actual login. Because of this, we
have two advanced options in the SSH Site Preferences:
When this option is set for hostA, it is used when hostA is the
destination in a Remote-to-Remote transfer and hostA needs to use
password authentication to grant access to hostB or any other
source. This means that this password will be used every time
hostA is the target!
This option is connected to the source host. One can have special
RSA/DSA keys defined using ssh-keygen, typically protected by a
passphrase. These keys are usually copied to the destination
machine's ~/.ssh/authorized_keys. This allows source
and destination to authenticate without transmitting passwords at
all! In such a case, you can set the SCP Passphrase on a host,
and whenever it is the source of a Remote-to-Remote transfer and
it is asked for a passphrase, the supplied passphrase will be
SSH Tunneling; Proxy Hosts, Firewalls...:
You can get past your company's firewall and reach your servers
directly with RBrowser by tunneling through the firewall host that all
users outside the firewall must go through. In RBrowser this is done at
the time you enter your login parameters in the Login Panel. After you
have entered your the URL, Username, and password for your target host
in the Login Panel, but before you hit the Login button, click the Site
Preferences button. Select Proxy from the selections along the top of
the window. Fill out the host/login information for the firewall host.
(Both the firewall and the target host must have sshd running,
preferably compatible versions). Hit Save to close the Site Preferences
and then hit Login.... This will provide a secure tunnel straight to
the target machine inside the corporate firewall!
Su to root (or another user):
While it works it should really be used only as a last resort. Logging
in directly as root is a much better idea, as su-ing incurs lots of
extra overhead and these connections are noticeably slower as a result.
Also, there is a serious limitation on "su to root" logins: scp does
not recognize them. That means that even if you are su'd to root, to
transfer files to and fro, scp only recognizes your original login
credentials. This is not a bug, it is a "security feature" of SSH/SCP.
Because of this, you may have to copy files into a writable directory
like /tmp, then on the remote viewer where you are already root, move
it into its final protected directory. What else you can do? Do not
forget, you are root in the remote Viewer. So if you want to transfer a
file and scp is failing, you can either change the read permissions, or
even change ownership using the Inspector Panel.
If you want to define various other options for SSH you can do
so, by defining them in the ~/.ssh/config file.
There are many options, like cipher,
protocol, etc. Here is an example:
Under the sftp-ssh protocol RBrowser uses
sftp or pax for file
transfers. If neither is available, RBrowser falls back to scp.
scp should reside in the same directory as the
ssh client (usually in /usr/local/bin).
RBrowser does its best to find it; if it cannot be found, you
will see a panel asking for the full path of scp.
The most important new feature: if you have two
remote ssh sites, you can transfer files from one to the other
DIRECTLY by simply dragging and dropping as
The SSH2 protocol defines SFTP as a way to have simple file
transfers over an encrypted (secure) transport. SFTP is included
in all SSH2 servers, including OpenSSH. SFTP is implemented as a
subsystem in sshd. It can be enabled in the