UPGRADING - security/openssh-library - Rivoreo Source Code Repositories

 [ A Japanese translation of this document is available at
 [ http://www.unixuser.org/%7Eharuyama/security/openssh/index.html
 [ Thanks to HARUYAMA Seigo <haruyama@nt.phys.s.u-tokyo.ac.jp>

 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).
	[ A Japanese translation of this document is available at
	[ http://www.unixuser.org/%7Eharuyama/security/openssh/index.html
	[ Thanks to HARUYAMA Seigo <haruyama@nt.phys.s.u-tokyo.ac.jp>

	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).