XS Blueprints:OTP root passwords: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
When deploying a large number of XS systems, root password management becomes an issue. While in many cases adminstration will be performed via automated scripts delivered through the network or other media, the need of ad-hoc maintenance in the field by technicians / sysadmins when things go wrong remains. |
|||
TODO: A complete description of what we are tryign to achieve |
|||
In other words, in the "things have gone wrong" - hardware issues, network issues or admin scripts that have broken the system, having the root password is important. |
|||
At the same time, having a common root password across a large number of XSs is a significant security risk. Even having a single unchanged root password for a single system is a security risk. This plan uses One Time Password lists - one for each XS - to manage these risks. |
|||
For now, random notes on OTP... |
|||
= Scenarios = |
|||
| ⚫ | |||
* The NOC team in the country of Rodrigombia - which has deployed 4 000 XSs to go with 60 000 XOs - needs to send a technician to resolve a problem with an XS in the village of Zernambuco. They want to give him root access that is valid only for this specific server, and for the time of this job, and the XS is not connected to the Internet or WAN. They do not want to risk the password to be stolen, lost or reused later. |
|||
* The Rodrigombia Technician is at the Zernambuco school. He needs to use the root password possibly several times as the fix may require reboots or login/logout cycles. A single-use OTP will not help. |
|||
* The NOC team of Sorialand is installing the software on 500 XSs and needs to collect the new OTPs as they are created in a safe way. So that misplacing the media (USB keys for example) does not risk the OTPs. |
|||
* The NOC team of Rodrigombia lost the OTP of a specific server and needs to recover it somehow. |
|||
= Implementation Plan = |
|||
| ⚫ | |||
* We can easily produce an OTP per server |
|||
* Each password can be valid for a period of time |
|||
== Alternative solutions == |
|||
| ⚫ | |||
* OPIE on F7 notes http://administratosphere.wordpress.com/2007/12/13/using-opie-on-fedora-7/ http://administratosphere.wordpress.com/2007/12/12/using-opie/ |
* OPIE on F7 notes http://administratosphere.wordpress.com/2007/12/13/using-opie-on-fedora-7/ http://administratosphere.wordpress.com/2007/12/12/using-opie/ |
||
| Line 10: | Line 30: | ||
* Some OPIE notes in spanish http://mitago.net/archives/2006/01/23/T03_51_24/ |
* Some OPIE notes in spanish http://mitago.net/archives/2006/01/23/T03_51_24/ |
||
PAM SOTP seems closer to what we want... |
|||
= Walkthrough = |
|||
| ⚫ | |||
= TODOs and future work = |
|||
Revision as of 01:33, 23 July 2008
When deploying a large number of XS systems, root password management becomes an issue. While in many cases adminstration will be performed via automated scripts delivered through the network or other media, the need of ad-hoc maintenance in the field by technicians / sysadmins when things go wrong remains.
In other words, in the "things have gone wrong" - hardware issues, network issues or admin scripts that have broken the system, having the root password is important.
At the same time, having a common root password across a large number of XSs is a significant security risk. Even having a single unchanged root password for a single system is a security risk. This plan uses One Time Password lists - one for each XS - to manage these risks.
Scenarios
- The NOC team in the country of Rodrigombia - which has deployed 4 000 XSs to go with 60 000 XOs - needs to send a technician to resolve a problem with an XS in the village of Zernambuco. They want to give him root access that is valid only for this specific server, and for the time of this job, and the XS is not connected to the Internet or WAN. They do not want to risk the password to be stolen, lost or reused later.
- The Rodrigombia Technician is at the Zernambuco school. He needs to use the root password possibly several times as the fix may require reboots or login/logout cycles. A single-use OTP will not help.
- The NOC team of Sorialand is installing the software on 500 XSs and needs to collect the new OTPs as they are created in a safe way. So that misplacing the media (USB keys for example) does not risk the OTPs.
- The NOC team of Rodrigombia lost the OTP of a specific server and needs to recover it somehow.
Implementation Plan
The PAM SOTP library meets our requirements for the core usage:
- We can easily produce an OTP per server
- Each password can be valid for a period of time
Alternative solutions
I spent a bit of time reading the doco on OPIE, but it is mainly about keeping a single password secure from eavesdroppers. See
- OPIE on F7 notes http://administratosphere.wordpress.com/2007/12/13/using-opie-on-fedora-7/ http://administratosphere.wordpress.com/2007/12/12/using-opie/
- Sample OPIE workflow... http://michele.pupazzo.org/diary/?p=203
- Some OPIE notes in spanish http://mitago.net/archives/2006/01/23/T03_51_24/