`chmod 600` is for the benefit of ssh client, which will otherwise spew:
```
chmod 600 image/insecure_key.pub
SSHing into 172.17.0.2
Warning: Permanently added '172.17.0.2' (ECDSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0664 for 'image/insecure_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
bad permissions: ignore key: image/insecure_key
```
As you can see though, the wrong file is `chmod`'ed -- it's the private key that SSH will insist should be protected with a more restrictive mode.
After this, `CMD ["/sbin/my_init", "--enable-insecure-key"]` works as expected.
Currently when you ssh to host you will not see ENV variables set. This was mentioned earlier in #54 and solution is tested.
Additional rationale: currently you can't see docker link ENV variables inside ssh, so you need to load this file every time you connect to container. I would say that expected behavior is to preserve them in services that are provided at default (cron/ssh)
The system() source in the default syslog-ng config file does
not work in Docker because it tries to access /proc/kmsg,
which is not allowed due to Docker's privileges. We replace
it by a source that only reads from /dev/log.
Many editors add a trailing newline to files. This can result in
slightly unexpected values for environment variables read from
/etc/container_environment.
Currently there is a symlink at /usr/lib/sftp-server to /usr/lib/openssh/sftp-server in the image. That seems to give trouble with packages like the rssh restricted shell, which will not follow a symlink to the sftp server binary for security reasons. So currently it is not possible to use this image as a basis for scp/sftp only access over ssh.
* All synced_folders are included.
* Vagrantfile of baseimage and passenger are nearly identical now. (I got to that when wanting to try passenger. But already had a vagrant box started from baseimage, there was no need to dup the effort, just reuse the existing single box for all. Then in end of day, may not need multiple Vagrantfiles. Passenger is a simple structure/process for managing dockers, but only needing to use baseimage once and have one VM up)
