SSH authorized_keys file

[Robert True]

While doing some research on a problem, I discovered my authorized_keys files are likly not built correctly. The Definitive Guide book does not have concrete examples of the structure of the file that I can find. Does anyone know where I can get more / better examples on the file?

Thanks,
Rt.

[Steven E. Protter]

This is not something you build manually.

If its corrupt, erase it and it will be rebuilt correctly as you do ssh connections to other systems.

The word doc I'm attaching briefly discusses a proceess that builds them.

SEP

[Zeev Schultz]

"The authorized_keys file contains the public keys from other user accounts.
The user must put their public key in this authorization file. Only add the
public key of other user accounts that you want to be able to access your
account. Typically you are only adding your own public key from another
system. A user could copy the file over and rename, but be careful as this
file may contain multiple public keys, in which case you would want to
append to the file.
In HP-SSH the default name for the authorized_keys file can be found in the
sshd_config file:
#AuthorizedKeysFile .ssh/authorized_keys
In some implementations the name authorized_keys2 is used for the SSH-2
protocol." (from Chris Wong's ssh explained)

I'd attach the whole pdf but it goes for 2Mb.
Pick one here : http://www.newfdawg.com/docs/HP-SSH_Explained.PDF

[Kevin Wright]

copy your .pub files you create on other systems to the .ssh/authorized_keys file. This will allow you to use your passphrases you entered when you ran ssh-keygen on the client. This file is very picky on syntax, make sure there are no extra spaces at the end of your keys.

[Robert True]

Steven: I think you were thinking of the known_hosts file, which does get generated automaticly (or at least semi-automaticly: on my system it is set to ask). I hope an authorized_keys file will not be generated automaticly!

The doc you pointed to, while confusing and hard to read, does discribe a method of building an authorized_keys file, but not exactly what I am looking for.

Zeev: The newfldawg pdf doc you pointed to does contain some interesting view graphs. Thanks.

To clarify, what I am looking for is: the syntax of the optional authorization entries for a key, such as allowing port-forwarding, restricting to a specific host, subnet,domain, etc. The above mentioned Def. Guide is confusing me as to the syntax for HP's version of the file.

Rt.

[Steven E. Protter]

You were right.

In actuality, the document I provided was much more relavent.

Rebuild your known_hosts public key files according to Chris Vail's doc. I don't use xwindows any more, I just use the cat command, but that will rebuild the file for you.

You have to have the known_hosts built up to get useful public keys in authorized_keys

Once authorized_keys is messed up there is no point in trying to edit or recovery, just do it over.

SEP

[James A. Donovan]

I've seen authorized_keys files corrupted when public keys are copy/pasted into them. Each key should be a single continuous line. Copying and pasting can insert unwanted CR-LF's into these files.

[James A. Donovan]

port forwarding, host, subnet, domain restrictions, etc. are all controlled by the settings in the sshd_config file, not the authorized_keys file.

Take a look at the man page for sshd_config:

http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5&arch=&apropos=0&manpath=OpenBSD+Current

[Hemanth Gurunath Basrur]

Hello Robert,

Refer to the foll. links for info.

http://www.lbl.gov/ITSD/CIS/faqs/SOFTWARE_Data_Communications/2.html

http://newfdawg.com/SHP-SSHpart4.htm

http://www.trustix.org/pipermail/tsl-discuss/2001-October/001398.html

HTH.

Regards,
Hemanth

[Robert True]

Thanks everyone, but my keys are working fine, nothing is corrupted, I use ssh only for all communication between systems I administer.

I am trying to do some fine tuning on individual accounts as OReilly's Def. Guide seems to imply can be done for various situations, ie: run single commands, restrict to defined locations, etc.

The last link supplied to newfdawg makes me think I should spend some more time there, as I have not been on there much in a long while.

Thanks again,
Rt.