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 <apinst...@mac.com> 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 vagrant-up+unsubscr...@googlegroups.com.
> 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 vagrant-up+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to