Excerpts from Jon's message of Tue Oct 18 19:10:18 UTC 2011: > Hello Clint, > > >> No, upstart jobs are designed to be short and pointed ways to define how > >> a daemon starts and stops. /etc/init.d is only for backward compatibility > >> in an upstart system. The ssh init.d script was left the way it is because > >> of chroot jails for sshd, but it is not necessary for normal operation. > > OOOHHHH! *Light Bulb*! this makes sense. Thanks for setting me > straight. > > >> Yeah, thats probably better. What was I thinking? ;) > Sometimes it's more fun to do things the hard way. :) > > >> Not sure why this isn't scalable... its not that heavy of a command and > >> it should be idempotent. > > I can't automate it. If I Can't automate it, can't scale it well. > The problem is, for every new VM, to enable SSH this requires the SysOp to: > -- Log into the Host Machine, > -- Determine the VNC port > -- VNC to the the VM, > -- Run the command. > > With enough volume, these four steps could make for a full time job. > It's not the command itself, but the work surrounding the command.
I think you mean you don't know how to auotmate it. :) Several ideas: * pre-boot, Mount each VM's filesystem, chroot into it and run dpkg-reconfigure openssh-server. * Use cloud-init's 'nocloud' feature to seed this reconfigure in on first boot. > > >> I do think its a bit odd that they are generated at install time rather > >> than whenever they are missing, > I'm glad, I thought I was having a derp moment. Also, checking for these > files at startup adds fault tolerance, would you agree? > I suppose that is one way to look at it. SSH is critical enough that I'd consider pushing for this behavior. Maybe there's a reason that the maintainers diverted from the standard behavior though. > >> but either way, its a well defined > >> behavior and so can be worked with fairly easily by removing and > >> regenerating the keys at first boot. An upstart job like this > >> would probably work: > > >> start on starting ssh > >> task > >> exec [ -f /etc/ssh/ssh_host_dsa_key ] || ssh-keygen -t dsa -b 4096 -f > >> /etc/ssh/ssh_host_dsa_key -q > > Is this supposed to be all on one line? Causes ssh to hang when calling: > start ssh > Maybe not, possibly try removing the exec and doing script ... end script > Also, is there a variable that tells Ubuntu if it is first boot? This > could potentially solve the problem since the .qcow2 will overwrite this > variable. > cloud-init is useful for doing things on first boot in a structured, repeatable way. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/876910 Title: When starting open ssh server without host keys in /etc/ssh/, the keys are not automatically generated. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/876910/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
