Vyatta Community Edition 4 1 4 (VC4 1 4) CD ROM Image

Vyatta Community Edition 4.1.4

October 2008

Document Part No. A0-0097-10-0004 v01

Content

* Security
* New in This Release
* Behavior Changes
* Upgrade Notes
* Resolved Issues
* Known Issues

Security

Vyatta Release VC4.1.3 and all previous releases contain an error in the SSH v.2
host keys. This security vulnerability, documented as Vyatta bug #3798, could
allow an attacker to execute a man-in-the-middle attack, or to decrypt existing
SSH v.2 sessions.

This vulnerability affects the Vyatta SSH subsystem in all Vyatta versions prior to
VC4.1.4. This vulnerability does not affect Vyatta site-to-site VPN or Vyatta remote
client VPN features configured with the Vyatta CLI.

The SSH vulnerability is fixed in VC4.1.4. If you upgrade to VC4.1.4, no further
action is necessary.

If you do not upgrade to VC4.1.4, SSH keys generated using previous versions of
the system should be regenerated using the following procedure:

1. Log on to the system as root.
2. Remove the files /etc/ssh/ ssh_host* or move them to another location.

3. Run the following commands:
ssh-keygen -t rsa1 -N '' -f /etc/ssh/ssh_host_key
ssh-keygen -t rsa -N '' -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa -N '' -f /etc/ssh/ssh_host_dsa_key
/etc/init.d/ssh restart

Systems upgraded or installed with Vyatta versions VC4.1.3 or earlier, using an ISO
install from LiveCD, will reintroduce this vulnerability. In this case, keys must be
removed and regenerated to eliminate the vulnerability again.

A warning message may displayed on your SSH client after you change the key on
your router. This message is specific to the SSH client, and the client should follow
the instructions of the SSH client in order to update the client’s key database.

New in This Release

There are no new features in this release.

Behavior Changes

There are no behavior changes in this release.

Upgrade Notes

SYSTEMS OLDER THAN VC4.0

There is no package upgrade from releases prior to VC4.0. You must install a fresh
system using the procedure found in the Vyatta System Quick Start Guide.

Automatic migration of existing configurations to VC4.1.4 is not supported for
system releases prior to VC4.0. Users must recreate the equivalent configuration
manually.

Before upgrading to VC4.1.4, save your existing configuration file for reference.
Your configuration file is named “config.boot”, and is located in the directory
“/opt/vyatta/etc/config.”

VC4.0

The Vyatta system can be upgraded from any VC4.0 release to VC4.1.4 using an
ordinary package upgrade. The URL for the testing repository is
http://packages.vyatta.com/vyatta. The component is “main” and the distribution
is “stable,” as in the following configuration example:

system {

package {

repository community {

components main

distribution stable

url http://packages.vyatta.com/vyatta
}

}

}

The series of upgrade commands used in previous releases has been simplified into
a single command. To upgrade the Vyatta system, issue the following command as
the root user:

full-upgrade

This command will upgrade the software and, where possible, preserve any non-
Vyatta packages that have been installed. All installed packages can be seen by
issuing the “show version all” command. You may explicitly control which
packages are retained during the upgrade process using “full-upgrade –i”. For
more information on the “full-upgrade” command see the Vyatta System
Command Reference.

NOTE: It is strongly recommended that you let the upgrade process proceed until
completion as interrupting it may require manual intervention for a successive
upgrade to complete successfully.

Upgraded packages are listed on the screen as they are upgraded. Your
configuration is automatically modified to reflect changes in command syntax
between a VC4.0 release and VC4.1.4.

NOTE: If you are upgrading from an SSH or Telnet session, the session will be
terminated. The upgrade will continue to completion and the system will
automatically reboot. You will need to wait until the upgrade has completed and
the system has rebooted before attempting to login again. This may take several
minutes depending on the extent of the upgrade and the speed of your network.
For additional control during the upgrade process, we recommend that you
upgrade using a system console.