On the system you're planning to use as the source of the ssh session (that is, if you're on system A and want to log into system B using "ssh username@B", then we're talking about system A here):

cd ~/.ssh
ssh-keygen -t dsa -C "identifying comment"

Notes:

The -C "identifying comment" part can be left off, and on some systems a default will be generated, usually "username@systemname", while on others there will be no identifying comment. This is mainly used to keep straight different keys once they are loaded into the "authorized_keys" file on the destination system. Each public key is a line in that file, and without identifying comments, it's hard to tell them apart.

The -t dsa tells it to generate a key using the DSA encryption method, which is preferred over the RSA method by ssh protocol version 2 (which is the current standard). Most systems will allow either RSA or DSA, so this is also optional (it's just a good idea). If you run across a system that allows RSA but not DSA, it's probably an older, ssh v1-only system, and you can generate a separate RSA key for that one.

The ssh-keygen program will respond:

Generating public/private dsa key pair.
Enter file in which to save the key 
(/xx/xx/.ssh/id_dsa):

Choosing the default is generally the right thing to do. If you're generating multiple keys, they should all be in different files, but most people just generate one per system, or at most, one DSA key called id_dsa and one RSA key called id_rsa.

Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 

It is a good idea to put a passphrase on a key, but since most people use this key method to avoid having to type in a password, the way to do that is just to hit enter twice here, adding no passphrase.

The ssh-keygen program will run for awhile and then tell you:

Your identification has been saved in /xx/xx/.ssh/id_dsa.
Your public key has been saved in /xx/xx/.ssh/id_dsa.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx identifying comment

Now, scp the id_dsa.pub file to the destination system ("B" in the example above), preferably with another unique file name, to avoid overwriting any files with that name in your area of system B. For example:

scp id_dsa.pub user@B:.ssh/A-dsa-key.pub

System B will ask for your password here and then id_dsa.pub will be sent from your .ssh subdirectory on system A (where you are now) to your .ssh subdirectory on system B, and named A-dsa-key.pub there to distinguish it from any other system's public key files.

Now, ssh to your account on system B. (You'll still need to provide a password, as the last step in setting up the keyfile is yet to come.)

The most common versions of ssh (OpenSSH and variants of it) want you to do this:

cd .ssh
touch authorized_keys
cat A-dsa-key.pub >> authorized_keys

This adds the information in the A-dsa-key.pub file to the end of the authorized_keys file.

Note: on some systems, this file's name is something other than authorized_keys. The most common variant is authorized_keys2, sometimes found on systems which use (or used) separate ssh version 1 and ssh version 2 servers.

Note: Some versions of ssh server use a different scheme, where you keep the A-dsa-key.pub file as a separate file in the .ssh or .ssh2 subdirectory and you add the file's name to a file, often called authorization, which contains a list of public key file names. If the usual method described above does not work, consult the documentation for the system in question.