Actually, now that I try it with a real setup, I don't see how using: config.ssh.host = [private network ip]
ever works... because in this situation, vagrant will always kill the private network on all runs 2..n trying to re-configure the network... see log below. INFO ssh: Attempting SSH connnection... INFO ssh: Attempting to connect to SSH... INFO ssh: - Host: 33.33.33.50 INFO ssh: - Port: 1855 INFO ssh: - Username: vagrant INFO ssh: - Key Path: ["/Users/apinstein/.vagrant.d/insecure_private_key"] INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "9e49fd36-ef99-49df-9219-b1b867e2ee64", "--machinereadable"] INFO ssh: SSH is ready! INFO interface: info: Machine booted and ready! [default] Machine booted and ready! INFO warden: Calling IN action: #<VagrantPlugins::ProviderVirtualBox::Action::CheckGuestAdditions:0x00000100f8a0d8> INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "guestproperty", "get", "9e49fd36-ef99-49df-9219-b1b867e2ee64", "/VirtualBox/GuestAdd/Version"] INFO warden: Calling OUT action: #<VagrantPlugins::ProviderVirtualBox::Action::CheckGuestAdditions:0x00000100f8a0d8> INFO warden: Calling OUT action: #<Vagrant::Action::Builtin::WaitForCommunicator:0x00000100f880a8> INFO warden: Calling OUT action: #<VagrantPlugins::ProviderVirtualBox::Action::Customize:0x00000100f80060> INFO warden: Calling OUT action: #<VagrantPlugins::ProviderVirtualBox::Action::Boot:0x00000100f800b0> INFO warden: Calling OUT action: #<VagrantPlugins::ProviderVirtualBox::Action::Customize:0x00000100f80178> INFO warden: Calling OUT action: #<VagrantPlugins::ProviderVirtualBox::Action::SaneDefaults:0x00000100ed1100> INFO warden: Calling OUT action: #<Vagrant::Action::Builtin::SetHostname:0x00000100ed1150> INFO warden: Calling OUT action: #<VagrantPlugins::ProviderVirtualBox::Action::ForwardPorts:0x00000100ed12e0> INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "9e49fd36-ef99-49df-9219-b1b867e2ee64", "--machinereadable"] INFO interface: info: Configuring and enabling network interfaces... [default] Configuring and enabling network interfaces... INFO ssh: SSH is ready! INFO guest: Execute capability: configure_networks (redhat) INFO ssh: SSH is ready! INFO guest: Execute capability: network_scripts_dir (redhat) INFO ssh: Execute: /sbin/ifdown eth1 2> /dev/null (sudo=true) INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "9e49fd36-ef99-49df-9219-b1b867e2ee64", "--machinereadable"] INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "9e49fd36-ef99-49df-9219-b1b867e2ee64", "--machinereadable"] INFO ssh: Execute: echo; printf $SSH_AUTH_SOCK (sudo=false) INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "9e49fd36-ef99-49df-9219-b1b867e2ee64", "--machinereadable"] INFO subprocess: Starting process: ["/usr/bin/VBoxManage", "showvminfo", "9e49fd36-ef99-49df-9219-b1b867e2ee64", "--machinereadable"] INFO ssh: Setting SSH_AUTH_SOCK remotely: /tmp/ssh-UqBfSa1371/agent.1371 [hangs.... ssh [email protected] will never work b/c vagrant just ran `/sbin/ifdown eth1` ] Right? On Saturday, February 8, 2014 9:47:43 PM UTC-5, Alan Pinstein wrote: > 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]> 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]. >>> 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.
