SSH works by the exchange and verification of information, using public and private keys, to identify hosts and users. The ssh-keygen command creates a directory ~/.ssh and files that contain your authentication information, The public key is stored in ~/.ssh/identity.pub and the private key is stored in ~/.ssh/identity/. Share only your public key. Never share your private key.

I upgraded to OpenSSH 3.1 and X11 forwarding stopped working. Starting with OpenSSH 3.1, the sshd x11 forwarding server listens on localhost by default; see the sshd X11UseLocalhost option to revert to prior behaviour if your older X11 clients do not function with this configuration. In general, X11 clients using X11 R6 should work with the default setting. Some vendors, including HP, ship X11 clients with R6 and R5 libs, so some clients will work, and others will not work.

For the SSH1 protocol, you can find this information in an old IETF draft available here. It is also available with the source distribution.

IP spoofing, where a remote host sends out packets which pretend to come from another, trusted host. Ssh even protects against a spoofer on the local network, who can pretend he is your router to the outside. In other words, ssh never trusts the net; somebody hostile who has taken over the network can only force ssh to disconnect, but cannot decrypt or play back the traffic, or hijack the connection. The above only holds if you actually use encryption.

Earlier versions of ssh had a less restrictive license; see the file COPYING in the accompanying source distributions. SSH2: The licensing for SSH2 is more strict than the licensing for SSH1. The UNIX version of ssh 2.0.13 may only be freely used for educational or personal use (see license agreement). If commercial use is wanted, it must be purchased from Data Fellows. See LICENSING.SSH2 for more information.

There may be other implementations that have developed for SSH2; however, I do not have that information. If you do, please let me know. The non-commercial Unix version of SSH1 works on almost all unix variants, including at least the following: There are also non-commercial ports of SSH for SSH1 including PalmOS, Windows, Macintosh, OS/2, BeOS, WindowsCE, Java, and OpenVMS. See section 2 of this FAQ for information on how to SSH.

SSH1 attempts to fall back to the "r" commands when it cannot connect to an ssh daemon on the remote host. It does this by execing your old rsh to use the old protocol. You probably have installed ssh as rsh, and forgotten to give the --with-rsh=PATH option to configure the second time. When ssh is looking for rsh, it keeps executing itself (or an older version of itself). To solve this, recompile ssh with the correct place for rsh.

The reason why .shosts authentication does not work by default in more recent versions of FreeBSD is because ssh(1) is not installed suid root by default. To ''fix'' this, you can do one of the following: a temporary fix, change the mode on /usr/bin/ssh to 4555 by running chmod 4555 /usr/bin/ssh as root. Then add ENABLE_SUID_SSH= true to /etc/make.conf so the change takes effect the next time make world is run.

SSH 2.3 and earlier versions contain a flaw in their HMAC implementation. Their code was not supplying the full data block output from the digest, and instead always provided 128 bits. For longer digests, this caused SSH 2.3 to not interoperate with OpenSSH. OpenSSH 2.2.0 detects that SSH 2.3 has this flaw. Recent versions of SSH will have this bug fixed. Or you can add the following to SSH 2.3 sshd2_config.

SSH Communications Security, is the developer of secure shell (SSH) protocol and maintains the releases of SSH1 and SSH2. However, since SSH Communications Security releases the non-commercial product, there is no formalized support for it. Since SSH has licensed the Secure Shell technology to Data Fellows, they control the commercial SSH distribution and provide support for SSH.

To install SSH, download the tar files and place in a temporary directory. Then do the following: # gzip -dc ssh-2.0.13.tar.gz | tar -xvf - # cd ssh-2.0.13 # ./configure # make # make install If you run into any problems, check out the troubleshooting section before sending it to the SSH mailing list. Note: You may have to use specific options with configure to get SSH to work the way you want (with certain ciphers, using TCP Wrappers, socks support, etc.).

SSH is similar to telnet, but it's more secure. It uses high level encryption and compression to make sure nobody can takeover or eavesdrop on your telnet session. Most hosts no longer allow Telnet for security reasons.

The symptom: there is a long delay between the time the TCP connection is established and the time when the client software asks for a password (or, in telnet(1)'s case, when a login prompt appears). The problem: more likely than not, the delay is caused by the server software trying to resolve the client's IP address into a hostname.

SSH Communications Security develops the SSH technology along with IPSec toolkits. However, Datafellows has licensing rights to sell and support SSH. SSH Communications Security does not provide support for SSH; however, SSH Communications Security does develeop the technology--so bug reports are welcome. If these resources don't help, you can post to the Usenet newsgroup comp.security.ssh or send mail to the gatewayed mailing list for ssh users at ssh@clinet.fi.

You need an ssh account on the remotehost and access to the repositorypath. This setup is particularly useful for secure authenticated development access, while cvsd is more useful for public read-only access. Older versions of cvs (at least 1.10.7 but 1.11.1p1 is fixed) have a bug where the repository is a direct descendant of the root directory. You should probably upgrade cvs on the server side.

If you ssh directly into the TeraFlop LAN from your own LAN, you should not need to set the DISPLAY variable. If you are remotely logged into your LAN, and want to export the display, you will need to set the DISPLAY variable before executing ssh.

You may have to use a different absolute pathname, whatever the location of imapd on your mailserver is. This option tells fetchmail that instead of opening a connection on the server's port 143 and doing standard IMAP authentication, fetchmail should ssh to the server and run imapd, using the more secure ssh authentication (as well as getting ssh's end-to-end encryption). Most IMAP daemons will detect that they've been called from the command line and assume the connection is preauthenticated.

SSH/SCP applications are based on keys of individual computers to realize the encryption. Doing ssh or scp to andrew.cmu.edu or unix.andrew.cmu.edu (that are not individual computers, but generic name for a pool of computers) will use one computer in the pool (say unix3.andrew.cmu.edu) for the connection. Next time ssh is used to the same andrew.cmu.edu, the connection is done to another computer in the pool having another key.