Secure Telnet and FTP Servers for UNIX

Most recent update: Tue Jul 30 10:40:54 2002

Whenever you make a connection to a network host and send your password as part of the authentication process, the connection is insecure. It doesn't matter whether the connection is telnet, ssh, ftp, smtp, pop, imap, or http.

Why is a password sent over a unencrypted connection insecure? Passwords sent over an unencrypted connection can be captured by anybody who can listen to the connection. That includes anyone who can connect to the network.

Don't encrypted links (such as SSH) provide protection for my password? Yes, but only if you can verify the identity of the server and are 100% sure that the host has not been compromised. Since the latter is impossible to know and the public-key authentication built into SSH does not provide a secure method for authenticating the server, the answer is sadly: No. The SSH method of authenticating the host with public keys is secure only if the public key is transmitted to the client via a secure out-of-band channel.

The Telnet and FTP protocols have options that provide for strong authentication and encryption just as SSH does. Telnet supports a wide variety of authentication methods including Kerberos 4, Kerberos 5, Secure Remote Password, NTLM, and X.509 public key certificates.

What about my X Windows session data? Telnet protocol supports X Windows System Data Forwarding and uses a much stronger model of authorizing the connections from X Windows clients than is used by SSH.


SECURE TELNET AND FTP CLIENTS FROM THE KERMIT PROJECT

The following secure clients are available from the Kermit Project at Columbia University:


SECURE TELNET AND FTP SERVERS

Most operating systems do not ship with secure methods of remote access. The Telnet and FTP servers provided by the operating system vendors are insecure and should be replaced by ones that are secure. For a partial list of secure Telnet and FTP servers, CLICK HERE.

[ Top ] [ Kermit Home ]


The Kermit Project / Columbia University / [email protected] / 30 July 2002