Other Topics

© 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 in Preferences/Tools.

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 password).

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:

  • 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.
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:
  • Finder Info-Fork Data is preserved during Folder Sync or File Transfer to another Mac
  • Recursive (fast) file operations, easy remote file management
  • Folder Sync from the Local Host to a Remote Host using SFTP-SSH
  • Remote-to-Remote File Transfers between any hosts, regardless of protocol
  • SFTP-SSH access through firewalls with tunneling (SSH-Proxy)

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 rules:
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:

SCP Password
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!

SCP Passphrase
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 used.

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.

SSH Options:
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:

Ciphers blowfish-cbc,3des-cbc,cast128-cbc,arcfour

File Transfer:
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 usual!

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 /etc/ssh2/sshd_config file.