5 ms·

This also applies to those of you building "template" VMs in VMWare or Xen -- before you save that template please delete the SSH keys in /etc/sshd/ so they are

by feld 12y ago

This also applies to those of you building "template" VMs in VMWare or Xen -- before you save that template please delete the SSH keys in /etc/sshd/ so they are generated on first boot of the deployed template!

13 12y ago
> generated on first boot of the deployed template! I've always been uncomfortable about that. How much boot time entropy can a VM have?
- staunch 12y ago
  http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubuntu-1404-lts-cloud.html http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubunt...
- feld 12y ago
  Depends on your OS :-)
korethr 12y ago
It would not surprise me if there are other bits of unique info on the template VM that need to be cleared before freezing the image, e.g. hostnames. This is a solved problem in Windows. The sysprep tool wipes out the hostname, security keys, user accounts and a bunch of other things one can configure, so the image initializes properly the first time it's booted. I am curious if there are similar tools for Linux & Unix that the image builders simply failed to use here, or if this points to an opportunity to build a useful tool.
- mintplant 12y ago
  There's virt-sysprep [1] and sys-unconfig [2]. [1] http://libguestfs.org/virt-sysprep.1.html http://libguestfs.org/virt-sysprep.1.html [2] http://linux.die.net/man/8/sys-unconfig http://linux.die.net/man/8/sys-unconfig
- verbatim 12y ago
  virt-sysprep from libguestfs does this. http://libguestfs.org/virt-sysprep.1.html http://libguestfs.org/virt-sysprep.1.html
- pliu 12y ago
  cloud-init https://cloudinit.readthedocs.org/en/latest/ https://cloudinit.readthedocs.org/en/latest/
  - kordless 12y ago
    +1
- warrenm 12y ago
  in VMware, you use Customization Specifications to do the equivalent to sysprep for Linux (and sysprep on Windows VMs)
e12e 12y ago
With standard ssh-keys, you now have a new problem: how do you know the key of your new vm? Trust-on-first-use is one option -- but a better option would probably be to move to ssh server/user certificates, and generate and sign a new server cert outside the vm, as part of finalizing/readying it for deployment. Might not work well with elastic generation of vms based on load (not sure how well ssh deals with mulitple CAs -- one might imagine a structure with an ultimately trusted, possibly long-lived, off-line cert on the top, and the various sub-CAs organized based on security domains (eg: elastic vm, user auth etc)). Still doesn't exist any sane, open automation for that, as far as I know. Maybe we should be happy people use keys at all, never mind if the trust/validation is flawed... (not to mention keys never expire, and can only be revoked via a black-list).
- jamiesonbecker 12y ago
  I've been thinking about adding server key synchronization (optional, of course!) across a Userify server group (cluster) but it seems even riskier than trust-on-first-use. What are your thoughts? Userify is definitely getting expiring keys soon (tracking when the key was last updated).
  - e12e 12y ago
    To be perfectly honest, as I understand what userify does (I'm not a user) -- the whole platform would benefit [ed:from] transition[ing] to ssh certificates[1]. While key synchronization is better than doing... nothing (which a lot of people do, including me, from time to time :-). I think key management for public key authentication is pretty much a solved problem: run your own CA (or delegate to someone, like Userify). There are still real issues with managing root keys etc -- but with cert support in openssh (client and server) that provides a sane basis for trust management. For Userify, the service (as opposed to keys, auth, servers and users: the problem) -- I think spending some time on a UI to manage certs/ca for ssh, documenting how to use it for user-keys/certs -- and offering to run a CA per Userify-account (ie: generate/manage the root CA-cert, allowing "instant security" by deploying the Userify-user's CA root cert on servers, and having a service to sign public-keys with that key) could be one very sensible approach. There might be some added benefit with an "always on"-service, by issuing short-lived user certs (valid for, say 8 hours a la kerberos tickets) -- but for that to be useful, perhaps some work would be needed with forking putty for windows users and/or patching ssh-agent/ssh for nix/OS X users. The basic functionality is there, but the UI/UX is lacking. Note that a user can keep the secret key* for as long as he/she is comfortable -- it's only the signed public cert that needs to be updated (as the previous one expires). Not sure if that answers your question, but those are some of my thoughts on the matter :-) [1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh-keygen.1?query=ssh-keygen&sec=1#x434552544946494341544553 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...
joelthelion 12y ago
I believe Vagrant takes care of that for you.

by feld 12y ago

13 12y ago

> generated on first boot of the deployed template! I've always been uncomfortable about that. How much boot time entropy can a VM have?

staunch 12y ago
http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubuntu-1404-lts-cloud.html http://blog.dustinkirkland.com/2014/02/random-seeds-in-ubunt...
feld 12y ago
Depends on your OS :-)

korethr 12y ago

It would not surprise me if there are other bits of unique info on the template VM that need to be cleared before freezing the image, e.g. hostnames. This is a solved problem in Windows. The sysprep tool wipes out the hostname, security keys, user accounts and a bunch of other things one can configure, so the image initializes properly the first time it's booted. I am curious if there are similar tools for Linux & Unix that the image builders simply failed to use here, or if this points to an opportunity to build a useful tool.

mintplant 12y ago
There's virt-sysprep [1] and sys-unconfig [2]. [1] http://libguestfs.org/virt-sysprep.1.html http://libguestfs.org/virt-sysprep.1.html [2] http://linux.die.net/man/8/sys-unconfig http://linux.die.net/man/8/sys-unconfig
verbatim 12y ago
virt-sysprep from libguestfs does this. http://libguestfs.org/virt-sysprep.1.html http://libguestfs.org/virt-sysprep.1.html
pliu 12y ago
cloud-init https://cloudinit.readthedocs.org/en/latest/ https://cloudinit.readthedocs.org/en/latest/
- kordless 12y ago
  +1
warrenm 12y ago
in VMware, you use Customization Specifications to do the equivalent to sysprep for Linux (and sysprep on Windows VMs)

e12e 12y ago

With standard ssh-keys, you now have a new problem: how do you know the key of your new vm? Trust-on-first-use is one option -- but a better option would probably be to move to ssh server/user certificates, and generate and sign a new server cert outside the vm, as part of finalizing/readying it for deployment. Might not work well with elastic generation of vms based on load (not sure how well ssh deals with mulitple CAs -- one might imagine a structure with an ultimately trusted, possibly long-lived, off-line cert on the top, and the various sub-CAs organized based on security domains (eg: elastic vm, user auth etc)). Still doesn't exist any sane, open automation for that, as far as I know. Maybe we should be happy people use keys at all, never mind if the trust/validation is flawed... (not to mention keys never expire, and can only be revoked via a black-list).

jamiesonbecker 12y ago
I've been thinking about adding server key synchronization (optional, of course!) across a Userify server group (cluster) but it seems even riskier than trust-on-first-use. What are your thoughts? Userify is definitely getting expiring keys soon (tracking when the key was last updated).
- e12e 12y ago
  To be perfectly honest, as I understand what userify does (I'm not a user) -- the whole platform would benefit [ed:from] transition[ing] to ssh certificates[1]. While key synchronization is better than doing... nothing (which a lot of people do, including me, from time to time :-). I think key management for public key authentication is pretty much a solved problem: run your own CA (or delegate to someone, like Userify). There are still real issues with managing root keys etc -- but with cert support in openssh (client and server) that provides a sane basis for trust management. For Userify, the service (as opposed to keys, auth, servers and users: the problem) -- I think spending some time on a UI to manage certs/ca for ssh, documenting how to use it for user-keys/certs -- and offering to run a CA per Userify-account (ie: generate/manage the root CA-cert, allowing "instant security" by deploying the Userify-user's CA root cert on servers, and having a service to sign public-keys with that key) could be one very sensible approach. There might be some added benefit with an "always on"-service, by issuing short-lived user certs (valid for, say 8 hours a la kerberos tickets) -- but for that to be useful, perhaps some work would be needed with forking putty for windows users and/or patching ssh-agent/ssh for nix/OS X users. The basic functionality is there, but the UI/UX is lacking. Note that a user can keep the secret key* for as long as he/she is comfortable -- it's only the signed public cert that needs to be updated (as the previous one expires). Not sure if that answers your question, but those are some of my thoughts on the matter :-) [1] http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/ssh-keygen.1?query=ssh-keygen&sec=1#x434552544946494341544553 http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/...

joelthelion 12y ago

I believe Vagrant takes care of that for you.