I should add.. I'm not really concerned about security with VirtualBox provider, but we wanted to start trying out Vagrant to bootstrap our cloud instances, and thus I wanted to automate moving of the ssh port.
That said, is there a place/way to put a block code that only runs on certain providers? So that way I could locate the code that kills port 22 ssh in certain providers. My concern here is that even if I could do this, wouldn't I still have the same problem but just on that provider? I really think the fix here is to make vagrant's network munging much more robust. Change config then restart, and optionally maybe skip all of that if the config doesn't change... Thoughts? On Thursday, February 6, 2014 7:12:02 PM UTC-5, Alvaro Miranda Aguilera wrote: > > For the ssh port issue, I have to change your Vagrantfile a bit. > > As you are concerned of the security reasons, I did add a rule in iptables > that will allow only connections from interface eth0, that is nat, so > nothing bad will happen > > I add port 22 and 1855 to sshd, but 22 is protected by the iptables > firewall. > > A. On the first run, the normal portforwarded for ssh is [default] -- 22 > => 2222 (adapter 1), so the normal behaviour will fail on the 2nd run, as > ssh won't be on port 22 anymore > > So, we need to fix that for the 2nd and next runs > > *AND* > > on each run, on top, remember this happen: > > [default] Clearing any previously set forwarded ports... > > > [default] Clearing any previously set network interfaces... > > > > B. so, you won't be able to connect over the network that is not yet > created, that's why the ssh on the 2nd run fail. > > Please try this on your Vagrantfile > > if !::File.exists? ".vagrant/machines/default/virtualbox/id" # first-time > bootstrapping -- this is the best approximation of once-per-setup that can be > done, even mitchellh says so. > puts "NOTICE: Detected first-run of instance. Will connect localhost/2222 > and run first-time-only script." > # security configuration > config.vm.provision :shell, :inline => 'grep "root.*NOPASSWD" > /etc/sudoers || echo "root ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers' > config.vm.provision :shell, :inline => 'grep "SSH_AUTH_SOCK" /etc/sudoers > || echo "Defaults env_keep+=SSH_AUTH_SOCK" >> /etc/sudoers' > > > # configure iptables for our custom > port > > # install basic ssh port 22 rule if there is no existing iptables config > > > config.vm.provision :shell, :inline => "grep 'dport 22 ' > /etc/sysconfig/iptables 2>/dev/null || ( iptables -A INPUT -p tcp -m tcp > --dport 22 -j ACCEPT && service iptables save)" > > > # configure ssh for our custom port > > > config.vm.provision :shell, :inline => "grep '^Port 1855$' || echo 'Port > 1855' >> /etc/ssh/sshd_config && service sshd restart" > > config.vm.provision :shell, :inline => "grep '^Port 22$' || echo 'Port > 22' >> /etc/ssh/sshd_config && service sshd restart" > > config.vm.provision :shell, :inline => "sed -i 's/--dport 22 /--dport > 1855 /gi' /etc/sysconfig/iptables && service iptables restart" > > config.vm.provision :shell, :inline => "grep 'dport 22 ' > /etc/sysconfig/iptables 2>/dev/null || ( iptables -A INPUT -i eth0 -p tcp -m > tcp --dport 22 -j ACCEPT && service iptables save)" > else > > > # once we're on our custom port, disable the built-in host -> guest:22 > forwarding so that we can spin up multiple vagrants without incident. > > # https://github.com/mitchellh/vagrant/issues/1922 > > > # > https://github.com/mitchellh/vagrant/search?q=collision&ref=cmdform&type=Issues > > > #config.vm.network :forwarded_port, guest: 1855, host: 2222, > id: "ssh", auto_correct: true, disabled: true > > > > > > > > end > > > > > > > > > > On Thu, Feb 6, 2014 at 5:19 PM, Alan Pinstein <[email protected]<javascript:> > > wrote: > >> Alvaro asked me to move this discussion to the ML: >> https://github.com/mitchellh/vagrant/issues/2881#issuecomment-34147376 >> >> In summary I see a few issues: >> >> - As a user I don't expect placing network config to be handled >> differently when placed in a global config block vs a provider config >> block, esp since vagrant seems to be heading in a direction where one >> would >> use it to configure the same box across different providers (dev on VBox, >> prod on AWS for instance), being able to have per-provider network config >> work gracefully would seem to be the goal. >> - The way vagrant handles "re-configuring" the network is fragile; it >> stops the network, re-generates some temp files, ssh's them over, then >> re-starts the network. You can easily see how this would break if ssh >> only >> listens on the port that is being taken down, as the subsequent >> config/ifup >> commands will not succeed. It would seem that the config files should be >> pre-generated, copied over in a single ssh request, and ifdown/ifup in a >> single request to eliminate the network suicide problem currently >> exhibited. >> >> I think in the end those are the major issues that I feel exist after >> working through this particular issue. >> >> Thoughts? >> Alan >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Vagrant" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> > > -- You received this message because you are subscribed to the Google Groups "Vagrant" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
