Open konklone opened 10 years ago
One complication that comes to mind is whether $HOME
will resolve to the right place during sudo. In my case, I'm logging in to my DO box as root, so I'm not using sudo, and $HOME
is where the heart is. Not sure about other situations.
Not sure if this is a good idea. Every additional prompt during setup takes you one step further from a "one-click, easy-to-deploy" mail server, and should be weighed carefully.
I don't know any major cloud providers that provision VMs with a system account that can be remotely logged in to with a password, and Mailinabox doesn't create such a user, so as a security measure it's unlikely to make a difference.
Perhaps a "Disable Password-based Logins" action can be added to one of the tools/*
scripts, so the whats_next.py
instructions can be simplified to running a single command. It could guide the user through setting up an SSH public key. What tools/*
script it belongs in, I'm not sure.
Not sure if this is a good idea. Every additional prompt during setup takes you one step further from a "one-click, easy-to-deploy" mail server, and should be weighed carefully.
Definitely - and this would only appear as a prompt if $HOME/.ssh/authorized_keys
existed. But yeah, it depends on how important mailinabox's recommendation to not use passwords is.
I don't know any major cloud providers that provision VMs with a system account that can be remotely logged in to with a password, and Mailinabox doesn't create such a user, so as a security measure it's unlikely to make a difference.
Digital Ocean (which I'm using, and which the mailinabox site recommends) provisions VMs with password-enabled root accounts, unless you chose to create a keypair in advance and to select it during creation of the VM (it's not selected by default).
Perhaps a "Disable Password-based Logins" action can be added to one of the tools/* scripts, so the whats_next.py instructions can be simplified to running a single command. It could guide the user through setting up an SSH public key. What tools/* script it belongs in, I'm not sure.
Good call, in any case.
Since
whats_next.py
complains about it, and it's easy enough to modify (append a line to the sshd config file), the setup script could:$HOME/.ssh/authorized_keys
, and if present:I'm not good enough with bash to do this as a PR, unfortunately.