From 6604fadbdd4dd5371aef4c3f83e87402d8fb8924 Mon Sep 17 00:00:00 2001 From: Damien Miller Date: Mon, 6 Nov 2000 12:48:54 +1100 Subject: - (djm) Remove UPGRADING document in favour of a link to the better maintained FAQ on www.openssh.com --- UPGRADING | 132 -------------------------------------------------------------- 1 file changed, 132 deletions(-) delete mode 100644 UPGRADING (limited to 'UPGRADING') diff --git a/UPGRADING b/UPGRADING deleted file mode 100644 index df3a23e17..000000000 --- a/UPGRADING +++ /dev/null @@ -1,132 +0,0 @@ -[ A Japanese translation of this document is available at -[ http://www.unixuser.org/%7Eharuyama/security/openssh/index.html -[ Thanks to HARUYAMA Seigo - -OpenSSH is almost completely compatible with the commercial SSH 1.2.x. -There are, however, a few exceptions that you will need to bear in -mind while upgrading: - -1. OpenSSH does not support any patented transport algorithms. - -Only 3DES and Blowfish can be selected. This difference may manifest -itself in the ssh command refusing to read its config files. - -Solution: Edit /etc/ssh/ssh_config and select a different "Cipher" -option ("3des" or "blowfish"). - -2. Old versions of commercial SSH encrypt host keys with IDEA - -The old versions of SSH used a patented algorithm to encrypt their -/etc/ssh/ssh_host_key - -This problem will manifest as sshd not being able to read its host -key. - -Solution: You will need to run the *commercial* version of ssh-keygen -on the host's private key: - -ssh-keygen -u -f /etc/ssh/ssh_host_key - -3. Incompatible changes to sshd_config format. - -OpenSSH extends the sshd_config file format in a number of ways. There -is currently one change which is incompatible with the old. - -Commercial SSH controlled logging using the "QuietMode" and -"FascistLogging" directives. OpenSSH introduces a more general set of -logging options "SyslogFacility" and "LogLevel". See the sshd manual -page for details. - -4. Warning messages about key lengths - -Commercial SSH's ssh-keygen program contained a bug which caused it to -occasionally generate RSA keys which had their Most Significant Bit -(MSB) unset. Such keys were advertised as being full-length, but are -actually only half as secure. - -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"). - -5. Spurious PAM authentication messages in logfiles - -OpenSSH will generate spurious authentication failures at every login, -similar to "authentication failure; (uid=0) -> root for sshd service". -These are generated because OpenSSH first tries to determine whether a -user needs authentication to login (e.g. empty password). Unfortunatly -PAM likes to log all authentication events, this one included. - -If it annoys you too much, set "PermitEmptyPasswords no" in -sshd_config. This will quiet the error message at the expense of -disabling logins to accounts with no password set. This is the -default if you use the supplied sshd_config file. - -6. Empty passwords not allowed with PAM authentication - -To enable empty passwords with a version of OpenSSH built with PAM you -must add the flag "nullok" to the end of the password checking module -in the /etc/pam.d/sshd file. For example: - -auth required/lib/security/pam_unix.so shadow nodelay nullok - -This must be done in addtion to setting "PermitEmptyPasswords yes" -in the sshd_config file. - -There is one caveat when using empty passwords with PAM -authentication: PAM will allow _any_ password when authenticating -an account with an empty password. This breaks the check that sshd -uses to determined whether an account has no password set and grant -users access to the account regardless of the policy specified by -"PermitEmptyPasswords". For this reason, it is recommended that you do -not add the "nullok" directive to your PAM configuration file unless -you specifically wish to allow empty passwords. - -7. X11 and/or agent forwarding does not work - -Check your ssh_config and sshd_config. The default configuration files -disable authentication agent and X11 forwarding. - -8. ssh takes a long time to connect with Linux/glibc 2.1 - -The glibc shipped with Redhat 6.1 appears to take a long time to resolve -"IPv6 or IPv4" addresses from domain names. This can be kludged around -with the --with-ipv4-default configure option. This instructs OpenSSH to -use IPv4-only address resolution. (IPv6 lookups may still be made by -specifying the -6 option). - -9. Logins from commercial ssh generate the error "Selected cipher type - idea not supported by server" - -This error is generated when a commercial ssh which has been configured to -use the 'idea' cipher attempts to connect to an OpenSSH server. To rectify -this, select a different cipher in ssh_config or ~/.ssh/config (3des for -security or blowfish for speed). - -10. "can't locate module net-pf-10" messages in log under Linux - -The Linux kernel is looking (via modprobe) for protocol family 10 (IPv6). -Either 1. load the appropriate kernel module, 2. enter the correct alias -in /etc/modules.conf or 3. disable IPv6 in /etc/modules.conf. - -For some silly reason /etc/modules.conf may also be named /etc/conf.modules - -11. Password authentication doesn't work on Slackware 7.0 - -Configure OpenSSH with --with-md5-passwords - -12. ./configure or sshd complain about lack of RSA support - -Ensure that your OpenSSL libraries have been built to include RSA support -either internally or through RSAref. - -13. "scp: command not found" errors - -scp must be in the default PATH on both the client and the server. You may -need to use the --with-default-path option to specify a custom path to -search on the server. This option replaces the default path, so you need -to specify all the current directories on your path as well as where you -have installed scp. For example: - -./configure --with-default-path=/bin:/usr/bin:/usr/local/bin:/path/to/scp - -- cgit v1.2.3