(Difference between revisions)
Revision as of 22:51, 17 August 2011
The policies on this page are aimed at administrative use of the system.
Shell Access
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:
- 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.
- 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 :)
SSH Keys
Access is provided via ssh keys and not passwords.
Users are expected to take security of ssh private keys very seriously.
- Private keys are strictly private to an individual. If they are disclosed to anyone, under any circumstances please let IT know AT ONCE. It's easy to change them.
- You should have a dedicated ssh key for use for meego.com access
- ssh keys must be protected by a strong pass phrase (ssh-agent and ssh-add makes this un-noticeable)
- ssh keys use must be confirmed before every use (ssh-add -c). This is usually a simple pop-up from ssh-askpass
- Onward access from the jump host is by tunnel - no ssh or agent-forwarding
- You'll be told the
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
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:
- The strong passphrase means that if your computer is stolen then the attacker won't be able to use your key to access your account.
- The askpass confirmation means that if a man-in-the-middle attack is attempted then your agent should prompt you when you didn't just establish a connection. If this happens then refuse the request.
- Agent forwarding means a compromised jump host would be able to spoof an onward connection as your account