© 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/
|