Dear users,


This is OpenSSH version 4.4p1.

There is a very important change in sshd with SuSE Linux 9.1: 

The "gssapi" support has been replaced with the "gssapi-with-mic" to fix 
possible MITM attacks (to enable support for the deprecated 'gssapi' 
authentication set GSSAPIEnableMITMAttack to 'yes'). These two versions 
are not compatible. The option GSSAPICleanupCreds is obsoleted, use 
GSSAPICleanupCredentials instead.

We disabled the new feature 'untrusted cookies' by default because it brings a
lot of problems. If you like to enable it, set ForwardX11Trusted to 'no' in
ssh_config.

The option UsePrivilegeSeparation was reverted to 'yes' because the problematic 
calling of PAM modules in this mode was fixed.

The option KeepAlive has been obsoleted, use TCPKeepAlive instead.

There is an important change in sshd with SuSE Linux 9.0:

The value of option ChallengeResponseAuthentication is reverted to default 
value yes, which is necessary for PAM authentication.

I this OpenSSH version is removed kerberos support from protocol SSH1, 
since it has been replaced with GSSAPI, but keeps kerberos password 
authentication for protocols SSH1 and SSH2. To enable Kerberos authentication 
read README.kerberos file. 

Important change in sshd with SuSE Linux 8.1 is that sshd X11 forwarding listens 
on localhost by default. See sshd X11UseLocalhost option to revert to prior 
behaviour if your older X11 clients do not function with this configuration.

The package openssh was splitted to openssh and the new package askpass.

OpenSSH supports two protocol versions (SSH1 and SSH2) which need to be 
configured differently.
Protocol version 1 is the old protocol and protocol version 2 is the new
protocol that has several advantages from the security point of view.

Please note that the default ssh protocol version has been changed to
version 2 with SuSE Linux 8.0. 

The change of the default protocol version brings one important change for
users who use identity keys for remote login with passphrases.

(Please note the difference: 'password' means a system password on a
given machine. The term 'passphrase', however, is usually used for the
string that an ssh private key is protected (encrypted) with.)

Protocol version 1 uses the key from file ~/.ssh/identity and compares
it with keys from file ~/.ssh/authorized_keys on the remote machine.

Protocol version 2 uses keys from files ~/.ssh/id_rsa or ~/.ssh/id_dsa
and they are compared with keys from file ~/.ssh/authorized_keys.
Note: Servers with OpenSSH < 2.9.9p1 use ~/.ssh/authorized_keys2 instead.

If you don't want to switch to protocol version 2 now, add a line saying
"Protocol 1,2" to /etc/ssh/ssh_config of the SuSE Linux 8.0 system to
retain the old ssh behaviour.

How to convert your environment to protocol version 2:

1) Creating the necessary identity keys for protocol version 2:

  There are two ways:

  A) You can use your old keys for protocol 1, but you have to convert them
     to the format of protocol 2.
     This can be done with the tool ssh-keyconverter:

     Every user that will use protocol version 2 needs to do this:

         cd ~/.ssh
         ssh-keyconverter -k identity
         - at this point you will be asked for the passphrase of ~/.ssh/identity
         ssh-keyconverter -a authorized_keys

     If OpenSSH < 2.9.9p1 is used on the server:

         grep ssh- authorized_keys >>authorized_keys2

     To enable login to other users with the converted protocol version 2 keys,
     the other user has to add the new ~/.ssh/id_rsa.pub to his authorized keys.

     You can do this by script by forcing version 1 with the -1 switch:

     for host in .... ; do
       ssh -1 user@$host 'cat >> .ssh/authorized_keys' < ~/.ssh/id_rsa.pub
       ssh -1 user@$host 'cat >> .ssh/authorized_keys2' < ~/.ssh/id_rsa.pub
     done


  B) You can generate new keys for protocol 2 by "ssh-keygen -t rsa" or
     "ssh-keygen -t dsa", then add id_rsa.pub (or id_dsa.pub) to
     authorized_keys2 and copy authorized_keys2 to the remote machine. See
     "man ssh" and "man ssh-keygen" for more info.


2) Handling of protocol version 2 with ssh-agent and ssh-add:

If you continue to use protocol version 1, there is nothing to do because
the default identity is still ~/.ssh/identity.

For protocol version 2, you have to pass the correct file (~/.ssh/id_rsa or
~/.ssh/id_dsa) to ssh-add. To support the version 1 key and the version 2
key you have to add both keys. Example:

	eval `ssh-agent -s`
	ssh-add ~/.ssh/identity ~/.ssh/id_rsa 

This will add your version 1 and version 2 keys and if they have the same
passphrase, you only have to type it once.

Other changes:

The OpenSSH handling of ssh-add/ssh-askpass is solved different as
with OpenSSH 2.x You don't need to call ssh-askpass any longer. If
ssh-add is called and doesn't have a real TTY, it will launch
/usr/lib/ssh/ssh-askpass itself. Make sure that the DISPLAY variable
is always set correctly.

If you want to use ssh-agent under X windows, just edit the file .xsession
in your home directory and change usessh="no" to usessh="yes". After 
logining in you only need to start ssh-add by hand, click or startup script.

If you want to use ssh-agent with startx, add the example above to your
~/.xinitrc before the window manager is started.

  Your SuSE Team