Actually you have to disable the custom ssh host & port, as with the private networking and custom ssh, the default ssh port-forwading doesn't run, and the box is inaccessible...
On Saturday, February 8, 2014 10:11:11 PM UTC-5, Alan Pinstein wrote: > > 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.
