Hi,
Vagrant Image version 1607.01 introduced a nice fix for a security issue with default password for a Vagrant user.
I understand that this is important, however I wanted to ask if it is possible to switch it off? I couldn't figure out a way it was introduced.
I was using first ansible login via password to configure my vms and then switching that option off by myself anyway.
Cheers, Rafal
Hi Rafal,
On 06/10/16 15:42, Rafal Skolasinski wrote:
Vagrant Image version 1607.01 introduced a nice fix for a security issue with default password for a Vagrant user.
I understand that this is important, however I wanted to ask if it is possible to switch it off? I couldn't figure out a way it was introduced.
If you want to reenable it, set PasswordAuthentication to no in /etc/ssh/sshd_config, then reload sshd. I wouldn't recommend that, since the system is fully usable with passwords disabled.
I was using first ansible login via password to configure my vms and then switching that option off by myself anyway.
You can still do this without enabling password authentication. If you use Vagrant's Ansible provisioner, things will just work without doing anything special (this is how I work). [1]
Alternatively, configure Ansible to connect using the private key that Vagrant generates (e.g. .vagrant/machines/default/virtualbox/private_key); if you'd like to use your own key for all boxes, add 'config.ssh.insert_key = false' to your Vagrantfile, and replace the insecure key from your playbook.
Another way is to generate a ssh configuration file locally, via 'vagrant ssh-config > my_ssh_config', and use Ansible's --ssh-common-args option to pass "-F my_ssh_cfg" to ssh.
Best regards, Laurențiu
[1] https://www.vagrantup.com/docs/provisioning/ansible.html
Hi Laurențiu,
Thanks for detailed information! I am using playbooks to create vms on a remote host and then I want to run another playbook to configure them. I want to enable password authentication only for a moment of initial configuration and then disable it again - I believe this should cause any security risk.
Thanks, Rafal
On 6 October 2016 at 17:42, Laurentiu Pancescu lpancescu@gmail.com wrote:
Hi Rafal,
On 06/10/16 15:42, Rafal Skolasinski wrote:
Vagrant Image version 1607.01 introduced a nice fix for a security issue with default password for a Vagrant user.
I understand that this is important, however I wanted to ask if it is possible to switch it off? I couldn't figure out a way it was introduced.
If you want to reenable it, set PasswordAuthentication to no in /etc/ssh/sshd_config, then reload sshd. I wouldn't recommend that, since the system is fully usable with passwords disabled.
I was using first ansible login via password to configure my vms and then
switching that option off by myself anyway.
You can still do this without enabling password authentication. If you use Vagrant's Ansible provisioner, things will just work without doing anything special (this is how I work). [1]
Alternatively, configure Ansible to connect using the private key that Vagrant generates (e.g. .vagrant/machines/default/virtualbox/private_key); if you'd like to use your own key for all boxes, add 'config.ssh.insert_key = false' to your Vagrantfile, and replace the insecure key from your playbook.
Another way is to generate a ssh configuration file locally, via 'vagrant ssh-config > my_ssh_config', and use Ansible's --ssh-common-args option to pass "-F my_ssh_cfg" to ssh.
Best regards, Laurențiu
[1] https://www.vagrantup.com/docs/provisioning/ansible.html _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
*shouldn't ;)
On 6 October 2016 at 17:57, Rafal Skolasinski r.j.skolasinski@gmail.com wrote:
Hi Laurențiu,
Thanks for detailed information! I am using playbooks to create vms on a remote host and then I want to run another playbook to configure them. I want to enable password authentication only for a moment of initial configuration and then disable it again - I believe this should cause any security risk.
Thanks, Rafal
On 6 October 2016 at 17:42, Laurentiu Pancescu lpancescu@gmail.com wrote:
Hi Rafal,
On 06/10/16 15:42, Rafal Skolasinski wrote:
Vagrant Image version 1607.01 introduced a nice fix for a security issue with default password for a Vagrant user.
I understand that this is important, however I wanted to ask if it is possible to switch it off? I couldn't figure out a way it was introduced.
If you want to reenable it, set PasswordAuthentication to no in /etc/ssh/sshd_config, then reload sshd. I wouldn't recommend that, since the system is fully usable with passwords disabled.
I was using first ansible login via password to configure my vms and then
switching that option off by myself anyway.
You can still do this without enabling password authentication. If you use Vagrant's Ansible provisioner, things will just work without doing anything special (this is how I work). [1]
Alternatively, configure Ansible to connect using the private key that Vagrant generates (e.g. .vagrant/machines/default/virtualbox/private_key); if you'd like to use your own key for all boxes, add 'config.ssh.insert_key = false' to your Vagrantfile, and replace the insecure key from your playbook.
Another way is to generate a ssh configuration file locally, via 'vagrant ssh-config > my_ssh_config', and use Ansible's --ssh-common-args option to pass "-F my_ssh_cfg" to ssh.
Best regards, Laurențiu
[1] https://www.vagrantup.com/docs/provisioning/ansible.html _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Ssh keys not work? I try not to use passwords when I can avoid it.
-----Original Message----- From: centos-devel-bounces@centos.org [mailto:centos-devel-bounces@centos.org] On Behalf Of Rafal Skolasinski Sent: Thursday, October 06, 2016 12:01 PM To: The CentOS developers mailing list. Subject: [Non-DoD Source] Re: [CentOS-devel] password ssh-ing in Centos/7 Vagrant box
*shouldn't ;)
On 6 October 2016 at 17:57, Rafal Skolasinski r.j.skolasinski@gmail.com wrote:
Hi Laurențiu, Thanks for detailed information! I am using playbooks to create vms on a remote host and then I want to run another playbook to configure them. I want to enable password authentication only for a moment of initial configuration and then disable it again - I believe this should cause any security risk. Thanks, Rafal
On 6 October 2016 at 17:42, Laurentiu Pancescu lpancescu@gmail.com wrote:
Hi Rafal, On 06/10/16 15:42, Rafal Skolasinski wrote:
Vagrant Image version 1607.01 introduced a nice fix for a security issue with default password for a Vagrant user. I understand that this is important, however I wanted to ask if it is possible to switch it off? I couldn't figure out a way it was introduced.
If you want to reenable it, set PasswordAuthentication to no in /etc/ssh/sshd_config, then reload sshd. I wouldn't recommend that, since the system is fully usable with passwords disabled.
I was using first ansible login via password to configure my vms and then switching that option off by myself anyway.
You can still do this without enabling password authentication. If you use Vagrant's Ansible provisioner, things will just work without doing anything special (this is how I work). [1] Alternatively, configure Ansible to connect using the private key that Vagrant generates (e.g. .vagrant/machines/default/virtualbox/private_key); if you'd like to use your own key for all boxes, add 'config.ssh.insert_key = false' to your Vagrantfile, and replace the insecure key from your playbook. Another way is to generate a ssh configuration file locally, via 'vagrant ssh-config > my_ssh_config', and use Ansible's --ssh-common-args option to pass "-F my_ssh_cfg" to ssh. Best regards, Laurențiu [1] https://www.vagrantup.com/docs/provisioning/ansible.html https://www.vagrantup.com/docs/provisioning/ansible.html _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel https://lists.centos.org/mailman/listinfo/centos-devel
Hi Rafal,
On Thu, Oct 6, 2016 at 5:57 PM, Rafal Skolasinski <r.j.skolasinski@gmail.com
wrote:
Thanks for detailed information! I am using playbooks to create vms on a remote host and then I want to run another playbook to configure them.
For me, the most amazing feature of Vagrant was to be able to use just one Vagrantfile to control both local development VMs, to production servers, and to change from one to the other with just one command. There are Vagrant plugins for pretty much every provider with an API: big "cloud" providers like AWS, Google Cloud or Azure, VPS hosters like Digital Ocean, Vultr or Linode, and also other cloud solutions like OpenShift, OpenStack and CloudStack. You can also use the libvirt plugin with both local and remote servers, it comes with plugins for most virtualization providers and Docker, and there's even a plugin for dedicated servers (when there's no API for controlling their creation and destruction). Being able to do:
vagrant up --provider virtualbox vagrant up --provider aws vagrant up --provider digitalocean
and move seamlessly between providers, provisioning everything with Ansible, is just priceless. I wouldn't go back to plain Ansible and writing dynamic inventory scripts.
I want to enable password authentication only for a moment of initial configuration and then disable it again - I believe this should[n't] cause any security risk.
The risk is small, but not zero. If someone's script hits your server in a critical moment, your server becomes his. This is not just theoretical: during Blaster (a Windows worm), a former colleague had installed Windows 2000 more than 12 times, and went directly to download the hotfix from Microsoft, which took less than a minute - and got infected every single time. And I've heard people complaining about getting hacked in the first 5 minutes after imaging a new Linux VPS, before they had the time to disable password logins (they had chosen their own passwords - apparently not that unique). But that's for you to decide - good luck! :)
Best regards, Laurențiu
Thanks!
BTW. I just noticed that every user on vms created with Vagrant is in fact admin... one can always ``` su - vagrant ```
On 6 October 2016 at 20:30, Laurențiu Păncescu lpancescu@gmail.com wrote:
Hi Rafal,
On Thu, Oct 6, 2016 at 5:57 PM, Rafal Skolasinski < r.j.skolasinski@gmail.com> wrote:
Thanks for detailed information! I am using playbooks to create vms on a remote host and then I want to run another playbook to configure them.
For me, the most amazing feature of Vagrant was to be able to use just one Vagrantfile to control both local development VMs, to production servers, and to change from one to the other with just one command. There are Vagrant plugins for pretty much every provider with an API: big "cloud" providers like AWS, Google Cloud or Azure, VPS hosters like Digital Ocean, Vultr or Linode, and also other cloud solutions like OpenShift, OpenStack and CloudStack. You can also use the libvirt plugin with both local and remote servers, it comes with plugins for most virtualization providers and Docker, and there's even a plugin for dedicated servers (when there's no API for controlling their creation and destruction). Being able to do:
vagrant up --provider virtualbox vagrant up --provider aws vagrant up --provider digitalocean
and move seamlessly between providers, provisioning everything with Ansible, is just priceless. I wouldn't go back to plain Ansible and writing dynamic inventory scripts.
I want to enable password authentication only for a moment of initial configuration and then disable it again - I believe this should[n't] cause any security risk.
The risk is small, but not zero. If someone's script hits your server in a critical moment, your server becomes his. This is not just theoretical: during Blaster (a Windows worm), a former colleague had installed Windows 2000 more than 12 times, and went directly to download the hotfix from Microsoft, which took less than a minute - and got infected every single time. And I've heard people complaining about getting hacked in the first 5 minutes after imaging a new Linux VPS, before they had the time to disable password logins (they had chosen their own passwords - apparently not that unique). But that's for you to decide - good luck! :)
Best regards, Laurențiu
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On 07/10/16 13:00, Rafal Skolasinski wrote:
BTW. I just noticed that every user on vms created with Vagrant is in fact admin... one can always
su - vagrant
I never thought of Vagrant images as a multi-user system, but you're of course right. I'll fix this for the next release, and add it to the release notes as a known issue. Thanks for reporting it!
Laurențiu
On Sat, Oct 8, 2016 at 4:22 PM, Laurentiu Pancescu lpancescu@gmail.com wrote:
On 07/10/16 13:00, Rafal Skolasinski wrote:
BTW. I just noticed that every user on vms created with Vagrant is in fact admin... one can always
su - vagrantI never thought of Vagrant images as a multi-user system, but you're of course right. I'll fix this for the next release, and add it to the release notes as a known issue. Thanks for reporting it!
Do you mind letting us know how the configuration would be fixed to address this? For what it's worth, in my opinion it would be more surprising for this behaviour to change. I think a Vagrant box is assumed to be a 'disposable', single user environment as you mentioned. Things like the well known insecure passwords and ssh key contribute to a standard Vagrant experience across boxes from different distributions.
Apologies if I've misunderstood what you mean.
Michael
On 10/10/16 14:08, Michael Vermaes wrote:
On Sat, Oct 8, 2016 at 4:22 PM, Laurentiu Pancescu lpancescu@gmail.com wrote:
Do you mind letting us know how the configuration would be fixed to address this? For what it's worth, in my opinion it would be more surprising for this behaviour to change. I think a Vagrant box is assumed to be a 'disposable', single user environment as you mentioned. Things like the well known insecure passwords and ssh key contribute to a standard Vagrant experience across boxes from different distributions.
The images would still follow the upstream recommendations, I have no intention of changing the default SSH key or password. In my local implementation:
- vagrant and root can use su and sudo without limitations (no change) - other users can't use sudo... (no change) - ...but can still su to any accounts except root or vagrant
This matches the sudo configuration pretty closely. An alternative would be to add vagrant to the wheel group, and allow anyone in the wheel group to use su (with password) or sudo (without password). You could add your own users to the wheel group if you wanted to, but it would be a conscientious decision to give someone admin privileges, rather than the default when calling useradd. If you didn't create additional users, you wouldn't be affected in either scenario.
The intention is just to prevent beginners from shooting themselves in the foot when sharing a box with a public IP. I'm open to arguments for either solution, as well as other alternatives.
Laurențiu
On Monday, 10 October 2016, Laurentiu Pancescu lpancescu@gmail.com wrote:
The images would still follow the upstream recommendations, I have no intention of changing the default SSH key or password. In my local implementation:
- vagrant and root can use su and sudo without limitations (no change)
- other users can't use sudo... (no change)
- ...but can still su to any accounts except root or vagrant
This matches the sudo configuration pretty closely. [...]
Sorry, I did misunderstand - I thought you would need to change the passwords. I realise now you're talking about using pam to just limit access to su. That makes sense. Sorry for the noise.
-
Conley, Matthew M CTR GXM -
Laurentiu Pancescu -
Michael Vermaes -
Rafal Skolasinski