Yes. Since ssh is a drop-in replacement for rsh, backup scripts should continue to work. You can use datbkr by David Cinege, which uses SSH to do backups over an SSH connection. You can get datbkr at http://www.psychosis.com/datbkr.
You can also use rdist and rsync, which there is more information at below.
Yes; you can use TCP forwarding for that, by using its secure TCP forwarding features. You can also tunnel through another open port through the firewall (I'm sure all those system admins love me now :-) by running a daemon on the remote side on a port that's allowed through a firewall, like SSL (port 443).
Set up the remote daemon running sshd on port 443:
# sshd -p 443
Then, on your local system, open a connection on port 443:
$ ssh -p 443 remotehost.example.org
Yes.
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 through 6.1.5, 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);
}
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
http://rsync.samba.org/rsync. You can use
the --rsh=/usr/local/bin/ssh option to use SSH as a transport.
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 .
Also look into Magnus Lundström's replacement for ssh-ppp in C for Linux,
which is now being ported to other OS's. See
http://detached.net/vpnstarter. The vpnstarter is more reliable (and easier to set up) than ssh-ppp.
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.
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.
You can either use ftpsshd by Per-Erik Martin at http://www.docs.uu.se/~pem/hacks/ for SSH1, or you can do this by hand.
Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do
myhost$ ssh -g -L 1234:ftphost.example.com:21 ssh-serverThis logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost.
Note: You need to use -g if you're forwarding to localhost.
Then, in another window, you do
myhost$ ftp localhost 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.internatif.org/pub/unix/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 4 and 5 support should work in 1.2.16 or later. Socks support in version 2.0.11 and later should work.
There's two patches available for AFS in SSH:
Yes. To configure the sources and create an SSH build that supports TCP Wrappers:
# ./configure --with-lib-wrap=/PATHOF/libwrap.a
Then add the following lines to Secure Shell Makefile:
-I/PATHOF/tcpwrappers
WRAPLIBS = -L/PATHOF/tcpwrappers -lwrap
You will also need to define the /etc/hosts.allow and /etc/hosts.deny appropriately. See the TCP Wrappers documentation for more details.
To configure the sources and create an SSH build that supports X forwarding:
# ./configure --with-x
Run make and make install normally. You'll also want to make sure your configuration file is set properly. In /etc/ssh_config for ssh1:
ForwardX11 yes
In /etc/sshd_config for sshd1:
X11Forwarding yes
In /etc/ssh_config for ssh1:
ForwardX11 yes
In /etc/ssh2/sshd2_config for sshd2:
ForwardX11 yes
Note that you do not have to change the /etc/ssh2/ssh_config file. If you are running TCP Wrappers along with X forwarding, you need to make sure you add the necessary sshdfwd-X11: line in the /etc/hosts.allow file. This should not
contain the host you are coming from.
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.
No, not currently. As digital certificates become more popular, SSH will probably support
digital certificates in the future.
Only in SSH2. It's supported in release 2.0.13 or later.
| Table of contents of this chapter | | General table of contents | | Beginning of this section |