On 8/22/07, Kim Goldenberg <[EMAIL PROTECTED]> wrote: > I don't just blindly remove security functions just because it "gets in > the way". Ive even set up ssh keys with non-null passphrases as well as > ssh-agent, to verify it's me and not someone who scarfed up my key > without my knowledge.
:soapbox. This is not a matter of getting in the way. What does get in the way is a root password that is known by some people and can be used beyond their original need to know. If you have 100 Linux virtual machines used by various people, it just does not work well to invent 100 good passwords every month to give each team the proper access. Acceptance by others gets very low when they cannot have a root password, but you can... and they will come up with a manager to approve that they put the root password in some silly automated ftp that copies data from one system to the other... Not having a root password is the best way to get out of that. We've used this and it really works. We did have a server virtual machine play SCIF (with logging and auditing and access control) for when no ssh login was possible, or for automation things. The good thing about cryptic keys is that you separate authentication and access control, which we believe is a good thing to do. It provides granularity and ease of use. When you already have your workstation protected well enough, ssh-agent makes it very easy indeed (and secure because people don't see you type in a password). Even if you have to type your passphrase each time, that's probably more secure against people reading it over your shoulder (because it's the same for all systems and you can probably type it very fast). Way better than having to look up the root password for server #86 when someone is watching you... And non-encrypted private keys (null passphrase) are evil. Except for cold bodies (i.e. not warm bodies, so machines or automated processes. And obviously you make sure that such a key only gives access to what that process must do.. The authorized_keys file for root on that server gives full access control. And it does auditing too. You can also use this for db2inst1 or whatever functional accounts you have. And it does not have to be the same list of users who have access. If you want to go fancy, you move the authorized_keys into LDAP and get the ability to build groups and update access without messing with individual systems. PS I believe we were eventually forced to have a root password because corporate standards dictate that you change it every nn days, and if you don't have one you cannot check that it expires every nn days :-( So I think we eventually set random passwords that nobody knew. Rob ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
