mirror of
git://anongit.mindrot.org/openssh.git
synced 2024-12-27 12:22:09 +00:00
81 lines
3.2 KiB
Plaintext
81 lines
3.2 KiB
Plaintext
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.
|
|
|