RBrowser

   Other Topics

© Copyright Robert Vasvari, 1993-2003.

Secure Shell Protocol (SSH/SFTP)

RBrowser is now compatible with ssh 1.2.x (1.2.27 plus security patches; 1.2.33 should be OK) AND ssh 2.x. RBrowser should work fine with OpenSSH also.

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.

How does it work: The SSH protocol is implemented differently from UNIX or FTP because RBrowser actually does not contain any ssh client code. This way you are free to choose what ssh client to use. By default, the ssh client supplied by the system (/usr/bin/ssh) is used. So, for each connection RBrowser establishes to the remote site, RBrowser runs the ssh 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 Login Panel, fill out the required fields and hit "Login."

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.

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 inside your company's firewall and reach your servers directly with RBrowser tunneling through an ssh proxy. This is the firewall host all sites that come from the outside must go through. You can specify the host/login/password for the firewall host on the preferences panel for an individual site and RBrowser will make a secure tunnel straight to the target machine inside the corporate firewall! Here is how: to reach host foo inside the firewall, fill out the fields in the login panel as usual, specifying foo as the target machine. Before you hit login, hit "Edit Preferences". Fill out the host/login info for the firewall host. Both the firewall and the target host must have sshd running (preferably compatible versions). Hit Save, close preferences and hit Login...

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 Mode:
SSH Mode - a new button on the login panel where you can force the local ssh client to talk ssh1 or ssh2 to the server. The default is 'Auto Mode'--which means the client is free to negotiate with the server about which protocol to use.

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 ssh protocol RBrowser uses scp for file transfers. 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!

SFTP:
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.

Known SCP Bugs:
During SCP file transfers OpenSSH "chases" symbolic links;, i.e. if you have a symbolic link in a directory you are transferring, scp will transfer the target of that link as a real file/directory. There is no way to tell it to just create another symbolic link. This is a bug in OpenSSH, has nothing to do with RBrowser. If you want this feature, send mail to the OpenSSH folks.

SSH1 versus SSH2 compatibility:
Today, many systems use ssh2 while still many use ssh1 (or a compatible free implementation like openssh. RBrowser does not have the client in it; rather, it uses whatever client you tell it to use. By default, it uses the first 'ssh' it finds in your path. In the Site Preferences Panel for each site you can define which ssh/scp client you want RBrowser to use. This is important because many systems today have both ssh1 and ssh2 clients installed. This way, you can use a different ssh client for each site. You MUST check the Site Preferences Panel before you log in. There is a button on the Login Panel called "Set Preferences." This panel lets you decide which local ssh/scp clients you want to use with this site. If, once you log in, you get messages like "Protocol Version is not supported," it means that you are not using the correct ssh client. Please contact your system administrator to find out what the correct ssh version is, and TEST your sites on the command line before using RBrowser to connect to them (like prompt> ssh remotehost <ENTER>). This is the best way to make sure things work smoothly.

Compatibility is very important when you do Direct File Transfers between remote hosts. If one of them is ssh1 the other has ssh2 server installed, they probably cannot talk to each other unless the ssh2 server is in ssh1 compatibility mode. For instance, if you get messages like "Wrong protocol version," or simply "The connection is lost, disconnected," there most likely is an ssh1-ssh2 mismatch between the two machines. You can get around this by specifying the correct Remote SCP Client in the Site Preferences Panel for the Source ssh site (shown below). Example: Host A has SSH2 server. Host B has SSH1 and SSH2 client installed. You are copying a file from B to A. You must specify the scp2 client in the Site Preferences Panel/Remote SCP Client, and things will work just fine.

SCP problems:
Many UNIX systems use OpenSSH today, which works quite well in most cases. Unfortunately, there is a problem with scp, where upon copying something to the remote system it fails with a message like:

bash: scp: command not found
lost connection

This problem has nothing to do with RBrowser, as if you attempt to run scp on the command line, you will get the same result. It is caused by the fact that the ssh server has to invoke scp on the remote server during file transfer, and it has to find it there. It does not use the PATH to find scp; rather, it is compiled in during build/install time. The scp client *cannot* be moved after that! If is is moved it will produce the the error above.

Places to obtain SSH:

MacOSX:
Follow Scott Anguish's excellent article on how to build OpenSSH on MacOSX.
FreeBSD:
OpenSSH is included in the base system; /usr/ports/security has other versions (openssh, openssh-portable, and ssh).
Debian Linux:
dselect, choose access method ftp
ftp site: nonus.debian.org
ftp dir: pub/debian-non-US
distributions: dists/unstable/non-US
RedHat Linux:
ftp://ftp.zedz.net/pub/crypto/redhat/
Other UNIX systems: (source code)
http://www.openssh.com/