www.openssh.com/faq.html#2.3
OpenSSH is a FREE version of the SSH suite of network connectivity tools that increasing numbers of people on the Internet are coming to rely on. Many users of telnet, rlogin, ftp, and other such programs might not realize that their password is transmitted across the Internet unencrypted, but it is. OpenSSH encrypts all traffic (including passwords) to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks. The OpenSSH suite includes the 35 ssh program which replaces rlogin and telnet, and 36 scp which replaces 37 rcp and 38 ftp. OpenSSH has also added 39 sftp and 40 sftp-server which implement an easier solution for file-transfer. This listens for connections from client machines, and whenever it receives a connection, it performs authentication and starts serving the client. Its behaviour is controlled by the config file 43 sshd_config. OpenSSH is a suite of tools to help secure your network connections. All communications are automatically and transparently encrypted. The program automatically sets DISPLAY on the server machine, and forwards any X11 connections over the secure channel. Pure RSA authentication never trusts anything but the private key. Currently, almost all communications in computer networks are done without encryption. As a consequence, anyone who has access to any machine connected to the network can listen in on any communication. This is being done by hackers, curious administrators, employers, criminals, industrial spies, and governments. Some networks leak off enough electromagnetic radiation that data may be captured even from a distance. When you log in, your password goes in the network in plain text. Thus, any listener can then use your account to do any evil he likes. Many incidents have been encountered worldwide where crackers have started programs on workstations without the owner's knowledge just to listen to the network and collect passwords. Programs for doing this are available on the Internet, or can be built by a competent programmer in a few hours. Businesses have trade secrets, patent applications in preparation, pricing information, subcontractor information, client data, personnel data, financial information, etc. Currently, anyone with access to the network (any machine on the network) can listen to anything that goes in the network, without any regard to normal access restrictions. Many companies are not aware that information can so easily be recovered from the network. They trust that their data is safe since nobody is supposed to know that there is sensitive information in the network, or because so much other data is transferred in the network. Even though OpenSSH is developed on 54 OpenBSD a wide variety of ports to other operating systems exist. The portable version of OpenSSH is headed by 55 Damien Miller. For a quick overview of the portable version of OpenSSH see 56 OpenSSH Portable Release. Currently, the supported operating systems are: * OpenBSD * NetBSD * FreeBSD * AIX * HP-UX * IRIX * Linux * NeXT * SCO * SNI/Reliant Unix * Solaris * Digital Unix/Tru64/OSF * Mac OS X A list of vendors that include OpenSSH in their distributions is located in the 57 OpenSSH Users page. The OpenSSH developers have tried very hard to keep OpenSSH free of any patent or copyright problems. To do this, some options had to be stripped from OpenSSH. OpenSSH does not support any patented transport algorithms. In SSH1 mode, only 3DES and Blowfish are available options. In SSH2 mode, only 3DES, Blowfish, CAST128, Arcfour and AES can be selected. OpenSSH provides support for both SSH1 and SSH2 protocols. Since the RSA patent has expired, there are no restrictions on the use of RSA algorithm using software, including OpenBSD. In addition to the main 58 OpenSSH website, there are many mailing lists to try. Before trying any mailing lists, please search through all mailing list archives to see if your question has already been answered. For more information on subscribing to OpenSSH related mailing lists, +please see 60 OpenSSH Mailing lists. Information about submitting bug reports can be found at the OpenSSH 61 Reporting bugs page. The OpenSSH client uses low numbered ports for rhosts and rhosts-rsa authentication because the server needs to trust the username provided by the client. UsePrivilegedPort no Or you can specify this option on the command line, using the -o option to 62 ssh command. A privileged port is also required for rhosts-rsa authentication to older SSH releases. Additionally, for both rhosts-rsa authentication (in protocol version 1) and hostbased authentication (in protocol version 2) the ssh client needs to access the private host key in order to authenticate the client machine to the server. If you wish to use a privileged source port, you must manually set the setuid bit on ssh. Their code was not supplying the full data block output from the digest, and instead always provided 128 bits. The old versions of SSH used a patented algorithm to encrypt their /etc/ssh/ssh_host_key. This problem will manifest as 65 sshd not being able to read its host key. To solve this, use the command below to convert your ssh_host_key to use 3DES. NOTE: Use the 66 ssh-keygen program from the Commercial SSH product, *NOT* OpenSSH for the example below. Such keys were advertised as being full-length, but are actually, half the time, smaller than advertised. OpenSSH will print warning messages when it encounters such keys. To rid yourself of these message, edit you known_hosts files and replace the incorrect key length (usually "1024") with the correct key length (usually "1023"). The default configuration files disable authentication agent and X11 forwarding. Between versions changes can be made to sshd_config or ssh_config. You should always check on these changes when upgrading versions of OpenSSH. You can verify if your shell is doing this by executing: ssh yourhost /usr/bin/true If the above command produces any output, then you need to modify your shell initialization. The closest thing it has to a specification is "what rcp does". Since the same command is used on both ends of the connection, adding features or options risks breaking interoperability with other implementations. New features are more likely in sftp, since the protocol is standardized (well, a 68 draft standard), and the client and server are decoupled. If the remote server is running sshd, it may be possible to tunnel'' certain services via ssh. This may be desirable, for example, to encrypt POP or SMTP connections, even though the software does not directly support encrypted communications. Tunnelling uses port forwarding to create a connection between the client and server. The client software must be able to specify a non-standard port to connect to for this to work. The idea is that the user connects to the remote host using ssh, and specifies which port on the client's machine should be used to forward connections to the remote server. The options most relevant to tunnelling are the -L and -R options, which allow the user to forward connections, the -D option, which permits dynamic port forwarding, and the -f option, which instructs ssh to background itself. It does not matter which port is used, as long as it's greater that 1023 (remember, only root can open sockets on privileged ports) and doesn't conflict with any ports already in use. The connection is forwarded to port 6667 on the remote server, since that's the standard port for IRC services. The remote command sleep 10'' was specified to allow an amount of time (10 seconds, in the example) to start the service which is to be tunnelled. If no connections are made within the time specified, ssh will exit. If more time is required, the sleep value can be increased appropriately or, alternatively, the example above could be added as a function to the user's shell. See ksh and csh for more details about user-defined functions. However, use of this option causes ssh to wait around for ever (as opposed to exiting after a remote command has completed), and the user must take care to manually kill the process afterwards. This is usually the res...
|
http://csua.com/feed/