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