Yes. Since ssh is a drop-in replacement for rsh, backup scripts should continue to work. If you use rdist, see below.
No; you should keep it turned on, for security reasons.
Today's CPUs are fast enough that performance losses (if any) only are noticable for local Ethernet speeds, or faster.
You might want to specify
blowfish encryption instead of the default, IDEA, with -c blowfish,
for faster operation.
Following are some measurements where the different encryption methods were applied between a P5/90 and a 486/100, both running Linux, for copying files with scp across a lightly loaded Ethernet.
The model chosen was t=a+x/b; a is the startup time in seconds, and b the sustainable transfer rate in kB/s. Also given are the 68.3% confidence intervals for the data, as determined by the Levenberg-Marquardt algorithm as implemented a pre-3.6 version of gnuplot.
Encryption a[s] da[s] b[kB/s] db[kB/s] none 2.37 0.37 386.1 5.8 rc4 1.96 0.27 318.2 2.9 tss 2.33 0.37 298.5 3.5 des 2.07 0.19 218.8 1.0 idea 2.25 0.45 169.6 1.3 3des 1.92 0.11 118.2 0.2
Across a heavily loaded Ethernet, rc4 encryption together with compression may actually be faster than using rcp.
If you don't encrypt your sessions, you are vulnerable to all the attacks which are open on the "r" suite of utilities, and you might as well not use ssh.
Yes; you can use TCP forwarding for that, by using its secure TCP forwarding features.
Stock rdist 6.1.0 does not work together with ssh, due to bugs in it. The 6.1.1 versions of rdist and later versions are believed to work.
If you use rdist, don't forget to compile the path to ssh into it.
Alternatively, you may specify the -P option so rdist uses
ssh, and not rsh.
If you use password authentication with rdist 6.1.2 or 6.1.3, you will need to apply the following patch to rdist to make it work:
--- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996
+++ src/rshrcmd.c Tue Jun 11 16:52:05 1996
@@ -63,7 +63,7 @@
/* child. we use sp[1] to be stdin/stdout, and close
sp[0]. */
(void) close(sp[0]);
- if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0 || dup2(0, 2) < 0) {
+ if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0) {
error("dup2 failed: %s.", SYSERR);
_exit(255);
}
<p>
This also applies if you get a "Warning: Denied agent forwarding
because the other end has too old version." error (which occurs
if your client is 1.2.17 or later, and it connects to an older server).
Another alternative would be to use rsync, a rdist replacement, which was designed to work with ssh, and makes better use of bandwidth. More information can be found at ftp://samba.anu.edu.au/pub/rsync or ftp://sunsite.auc.dk/pub/unix/rsync .
You can run PPP over a regular ssh connection. See http://www.inka.de/~bigred/sw/ssh-ppp-new.txt for a working solution. It's a good idea to enable compression for this.
However, this may cause problems for forwarding TCP connections, because both the TCP connection over which ssh runs and a TCP connection forwarded over the PPP/ssh tunnel may retransmit at the same time. In this case, it is better to use encrypted IP tunneling via UDP. A possible implementation of this is http://www.inka.de/~bigred/devel/cipe.html .
There is a general working solution for RPC-based services, such as NIS. You can download it from ftp://ftp.tu-chemnitz.de/pub/Local/informatik/sec_rpc/ . NIS, in particular, is working.
In principle, this could also be adapted for NFS; this has not been done yet.
Services which are based purely on UDP, such as DNS, have not been secured with ssh yet, although it is possible in principle.
It is not likely that this will be implemented. GL uses a totally different protocol from X, and at least gld would have to be replaced.
OpenGL, when run as an X server extension, should pose no problem.
You may need to set the environment variable
GLFORCEDIRECT=no.
If you want to avoid sending ftp passwords in cleartext over the net, you can use ssh to encrypt your command channel. This will still leave your data channel open to all attacks on TCP, and will not work through a firewall.
Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do
myhost$ ssh -L 1234:ftphost.do.main:21 ftphostThis logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost.
Then, in another window, you do
myhost$ ftp mymachine 1234 220 ftphost FTP server (Foonix 08/15) ready. Name: (myhost:yourname): 331 Password required for yourname Password: 230 User yourname logged in.
This works if the remote ftp daemon accepts PORT commands which specify
a different host from the one the command channel appears to come from,
and if the ftp client always uses PORT. This is true for vanilla UNIX
ftp client and ftpd servers; it may not work for more advanced
ftpds, such as wu-ftpd.
For servers which do not accept this, you can see wether you ftp
client supports passive mode, and wether the ftp server accepts
PASV.
For POP, Stephane Bortzmeyer (bortzmeyer@pasteur.fr) has written a script
which protects the mail transfer and passwords ussing ssh.
It requires no modification to existing POP servers or clients, and
is available from
ftp://ftp.pasteur.fr/pub/Network/gwpop/
.
Other services could be secured by similar means. Note, however, that unencrypted ftp data connections are still vulnerable to session hijacking and snooping.
Socks 5 support should work in 1.2.16 or later.
At the moment, not in the main sources. There's an AFS patch
available from
http://www-personal.umich.edu/~dugsong/ssh-afs-kerberos.html
which should make it into the contrib directory shortly.
Next Chapter, Previous Chapter
Table of contents of this chapter, General table of contents
Top of the document, Beginning of this Chapter