Before you start the SSH server, please be sure you have at least
changed the root password from the default password shipped in all our
root file systems!

To change the root password, first log in as 'root' on the serial port
(debug port), then use the "passwd" command to change this password.

The SSH daemon is not started automatically. To start the ssh server, run
'/etc/init.d/ssh start' from the command line. To make the system start SSH
automatically at boot-time, create a symbolic link from /etc/rc3.d/S20ssh
to /etc/init.d/ssh. This will start the ssh server automatically at
runlevel 3 (runlevel 3 is the default).

The SSH daemon has been designed with security in mind, but no
software can ever be 'bug-proof'. If you do not require network
remote access, disable SSH by removing the ssh start files from
the /etc/rc*.d directories.
You should seek the advice of an experienced systems administrator or
security professional before deploying a networked system.

SSH uses two sets of cryptographic keys for security. SSH host keys
allow the SSH client to ensure it is connecting to the correct server.
SSH user keys can optionally be used to authenticate user logins.

Our root file systems come with SSH host keys pre-installed.
If you are using SSH, then you need to determine what your requirements
for ssh keys are. If you do nothing you will have the same host key on
all of your boards, and the same key as any other ADS customers who do
nothing. You may want to create your own host keys, perhaps distinct
keys on each board. To do so, log into the board as root, and run the
following commands:

        ssh-keygen -q -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa
        ssh-keygen -q -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa
        /etc/init.d/ssh restart

Contact us if you need help determining or implementing your ssh key
requirements

On May 13th, 2008, a cryptographic weakness was discovered in the
OpenSSL library included in Debian, and on our file systems. New versions
of openssl and SSH were released to fix this security hole.

The impact of the security hole is that SSH keys are weaker than they
should be. This exposes a system running SSH to attackers who can guess
what its keys are. In some situations, the impact can be as bad as an
attacker guessing root's password.

We will provide updated file system images soon that fix the problem in
OpenSSL and SSH. If you have SSH enabled, and are using a file system
released before May 13th, you should either stop the SSH server, or take
other steps to ameliorate the problem. A detailed explanation of the
security issue, and how to fix it is available
on Debian's wiki.