(Policy page .. add some light Bug policy) |
(→SSH Keys) |
||
| (One intermediate revision not shown) | |||
| Line 7: | Line 7: | ||
There are multiple levels of trust: | There are multiple levels of trust: | ||
* No shell access : This is the norm. Very few people have shell accounts to any systems. There must be an '''extremely''' compelling reason to provide shell access. | * No shell access : This is the norm. Very few people have shell accounts to any systems. There must be an '''extremely''' compelling reason to provide shell access. | ||
| - | * Shell user : When granted, access will normally be at this level | + | * Shell user : When granted, access will normally be at this level. |
* VM root : In exceptional cases for highly trusted people with significant sysadmin knowledge we will provide root access to a virtual machine. Having root access means you take direct responsibility for the security of the machine. | * VM root : In exceptional cases for highly trusted people with significant sysadmin knowledge we will provide root access to a virtual machine. Having root access means you take direct responsibility for the security of the machine. | ||
| - | * Superadmin : The superadmin team is the core IT team - invitation only :) | + | * Superadmin : The superadmin team is the core IT team - invitation only :) These users are given access to IT Private bugs. |
== SSH Keys == | == SSH Keys == | ||
| Line 31: | Line 31: | ||
If you think you need an exception to a rule (eg group access, password access, unattended/cron access etc) then we'll be glad to help solve the problem you face. It's much better to get help to implement a secure solution than to "just" do something to make it work. | If you think you need an exception to a rule (eg group access, password access, unattended/cron access etc) then we'll be glad to help solve the problem you face. It's much better to get help to implement a secure solution than to "just" do something to make it work. | ||
| - | The following snippet can be usefully added to your .ssh/config | + | The following snippet can be usefully added to your .ssh/config (note you need to change the <USER> to your meego.com shell account name) |
Host *.meego.com | Host *.meego.com | ||
User <USER> | User <USER> | ||
The policies on this page are aimed at administrative use of the system.
There are no firm guidelines for access to infrastructure systems. We operate a validated trust approach and require consensus from a number of members of the IT team to grant access.
There are multiple levels of trust:
Access is provided via ssh keys and not passwords.
Users are expected to take security of ssh private keys very seriously.
If you have any problems with implementing any of these rules then please talk to one of the IT team - they want you to get it right and will do their best to help you. (And it may help to know that they too will have struggled with ssh once upon a time!)
If you think you need an exception to a rule (eg group access, password access, unattended/cron access etc) then we'll be glad to help solve the problem you face. It's much better to get help to implement a secure solution than to "just" do something to make it work.
The following snippet can be usefully added to your .ssh/config (note you need to change the <USER> to your meego.com shell account name)
Host *.meego.com
User <USER>
IdentityFile ~/.ssh/id_rsa_meego
ServerAliveInterval 60
ForwardAgent no
Host access.meego.com
ProxyCommand none
Host *.in.meego.com
ProxyCommand ssh -q access.meego.com netcat %h 22
Notes:
(repeated from IT team contact section).
The MeeGo IT team have 2 bug products: MeeGo IT Private and MeeGo IT. We use the private one for bugs which discuss secure or confidential information; sometimes we'll make a public bug private or a private bug public. The criteria are not well defined but in general we don't discuss specifics of our installation in public. Whilst we do not operate "security through obscurity", nor do we claim to be infallible - limiting information means that when we make errors, the information is less likely to leak and the window that we have to rectify the error without discovery should be larger.