Cannot override default ssh port forwarding

[abarani]

The following configuration does not work anymore on Vagrant 1.5.1.
(Tested 1.5.1 and 1.5.0)

config.vm.network :forwarded_port, guest: 22, host: 2222, disabled: true
config.vm.network :forwarded_port, guest: 22, host: 2230, id: "ssh"

vm:
* Forwarded port '2222' (host port) is declared multiple times
with the protocol 'tcp'.

Also tried using the last line alone:

config.vm.network :forwarded_port, guest: 22, host: 2230, id: "ssh"

results in Vagrant using the default port 2222 and ignoring the defined 2230.

==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...

The disabled: true setting is working as expected on vagrant 1.4.3.

[kikitux]

i did comment in the other issue.. what works for me on 1.5.x

[mstoltenburg]

I followed @kikitux example in mitchellh#1922 and it worked for me too in 1.5.1 (with OS X version 10.9.2). The difference to the above configuration is that the port forwarding with the ID ssh gets disabled. This syntax feels kind of ill but at least it works.

config.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", disabled: true
config.vm.network :forwarded_port, guest: 22, host: 2230, auto_correct: true

this is not working for me in 1.5.1, but it did in 1.4.3

config.vm.network :forwarded_port, guest: 22, host: 2230, id: "ssh", auto_correct: true

[abarani]

I confirm, it works with id: "ssh" on the disabled: true line.
Thanks @kikitux and @mstoltenburg!

By the way I think this should be placed somewhere in the docs... it's not so straightforward.

[Taytay]

Thanks for the help here @kikitux and @mstoltenburg. I was bitten by this as well in the upgrade to 1.5+, and the workaround of disabling ssh and then mapping it manually does work.

It would have been a bit easier to detect if my previous method gave an error or warning of some sort.

[xaniasd]

I'm having trouble changing the ssh port on the guest machine. I tried the suggestions above

config.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", disabled: true
config.vm.network :forwarded_port, guest: 2716, host: 2222, auto_correct: true

but I still get the error message (multiple declarations) on vagrant v1.5.1, ubuntu 12.04

It works if I use another host port (say 2223), e.g.:

config.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", disabled: true
config.vm.network :forwarded_port, guest: 2716, host: 2223, auto_correct: true
config.ssh.port = 2223

[kikitux]

you actually have the guest ssh port on 2716 ?

On Fri, Mar 21, 2014 at 12:41 AM, xaniasd notifications@github.com wrote:

I'm having trouble changing the ssh port on the guest machine. I tried the
suggestions above

config.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", disabled: trueconfig.vm.network :forwarded_port, guest: 2716, host: 2222, auto_correct: true

but I still get the error message (multiple declarations) on vagrant
v1.5.1, ubuntu 12.04

Reply to this email directly or view it on GitHubhttps://github.com//issues/3232#issuecomment-38157449
.

[xaniasd]

in this case yes, sshd is listening to port 2716. Is it a bad idea?

[kikitux]

in the sshd add an extra line,
Port 22
Port 2716

from what I know, vagrant WILL ssh into the first interface 22 hardcoded
you can use iptables to protect the port 22 in the other nics, like ! -i
eth0

Full Vagrantfile that you can use, is here:

https://groups.google.com/d/msg/vagrant-up/mkHSTiKnBpM/Gl9pl_g6JYsJ

any question, please send an email to the mailing list

Alvaro.

On Sun, Mar 23, 2014 at 9:14 PM, xaniasd notifications@github.com wrote:

in this case yes, sshd is listening to port 2716. Is it a bad idea?

Reply to this email directly or view it on GitHubhttps://github.com//issues/3232#issuecomment-38376681
.

[xaniasd]

Hey Alvaro, thanks for the help. Using another host port (2223 instead of 2222) works without problems with a custom guest port, meaning that vagrant uses port 2716 to log into the first interface. I don't need to enable Port 22 any longer.

cheers

[mitchellh]

This is likely a docs issue. You must specify the ID when overriding. I'll make note of this.

[Taytay]

@mitchellh, when you say it's a docs issue, I want to make sure I understand:
Specifying the id in order to override does not work in 1.5.1, as it did in previous (1.4.x) versions.

#Does not work:
config.vm.network :forwarded_port, guest: 22, host: 2230, id: "ssh"

#You have to disable the default port first instead: 
config.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", disabled: true
config.vm.network :forwarded_port, guest: 22, host: 2230, auto_correct: true

Is that what you intend to clarify in the docs? it's cool if that's what the intention is. I was just surprised at the change in behavior, as well as needing two lines in order to do this now.

[olimoth]

I'm seeing this issue too, even when specifying the id, on version 1.5.1 (posting because I can't see this defect linked in the changelogs of 1.5.2 or 1.5.3).

[Taytay]

I can report that this does indeed seem to work now, at least as of Vagrant 1.6+ (It might have worked before too - I just hadn't tested past 1.5.1)

config.vm.network :forwarded_port, guest: 22, host: 2522, auto_correct: false, id: "ssh"

Thanks @mitchellh! 👍

[lsaffie]

What worked for me was the following as per @xaniasd 's comment

config.vm.network :forwarded_port, guest: 22, host: 2222, id: "ssh", disabled: true
config.vm.network :forwarded_port, guest: 22022, host: 22022, auto_correct: true
config.ssh.port = 22022

ssh in my vagrant box is listening in 22022

[SebAshton]

+1 👍 on @Taytay's one liner working in 1.6+

[hardbap]

On 1.6.3 I needed to use the workaround from @xaniasd because the one liner from @Taytay didn't do the trick. Thanks y'all!

[coloraggio]

@mitchellh is right, it's a docs issue.

Just do this and it will use 9980 instead of default 2222:
config.vm.network :forwarded_port, guest: 22, host: 9980, id: "ssh"

[rvangundy]

@lsaffie, in your configuration you are permitting auto_correct: true, but you set the config.ssh.port to a specific port. If the port corrected due to a collision, this will break SSH access. Did you manage to find a solution to assigning the SSH port based on the auto-corrected port?

Does Vagrant function by defaulting the SSH port to the one specified with id: "ssh"?

[lsaffie]

@rvangundy, this configuration worked for me. In fact, I use it on a daily basis.
With this config, I can do vagrant ssh and get console access (ssh is listening on port 22022 in the vagrant box)

[rvangundy]

@lsaffie, it works even if the port is auto-corrected? Would it work if the port was corrected to something other than 22022?

[dragon788]

@rvangundy 'vagrant ssh' should work because the vagrant up should have recorded the running config for the vm. If you have multiple vms in the same file you can 'vagrant ssh $NAME' and even if they were all initially configured for port 2222, each successive machine if the auto_correct=true should have its own port, and vagrant keeps track of them. If this isn't the case, there is definitely a hole in the testing cases. In the case of multiple vms in different directories, the same logic should apply. You can run a vagrant global-status to see all the running VMs, which means it keeps track of their states and probably ports somewhere.

[jsanders]

By the way, this is probably obvious, but it stumped me for awhile: if it is an existing machine, you have to do vagrant reload because vagrant up will use the existing port forwarding configuration.

[tetherit]

Just doing this worked for me, thank you!

config.vm.network :forwarded_port, guest: 22, host: 12345, id: 'ssh'

[m11y]

@Hackeron it also worked for me. Vagrant version is '1.7.2'.

[joequery]

hackeron's comment worked for me as well. Vagrant version is 1.7.2.

[bluebiu]

@Hackeron it also worked for me too!! Vagrant version is '1.7.4'.

[ascotan]

@dragon788 I think that @rvangundy is correct. When you deconflict a port using auto_correct and then set the port in config.ssh.host, this will break if the port is actually changed.

In my case I have 2 Vagrantfiles that need to do this and when you launch both vagrant's, one of the two will become deconflicted, but when you run ssh, both terminals will ssh into the same box.

If you run with VAGRANT_LOG=INFO you'll see that the 'undeconflicted' port is being used via vagrant ssh in both Vagrantfiles.

I'm not sure how to get around this. It looks like the problem is that the 'deconfliction' algorithm is a runtime-only feature. When you run 'vagrant ssh' it re-evaluates the Vagrantfile and pulls the 'undeconflicted' port out of the config. (makes sense because there is no way to determine the port collision mapping after the fact...)

I added this:
config.vm.network "forwarded_port", id: "ssh", guest: 22, host: 2222, auto_correct: true config.vm.networks.each do |type, options| if type == :forwarded_port print options[:host] end end
To verify that even after port deconfliction, the wrong port is used for doing ssh. Again, this is because the config is re-evaluated on a 'vagrant ssh' after a runtime port re-mapping has occured.

I'm going to say that this is a different issue than 'Cannot override default ssh port forwarding'. This has to do with the fact that config.ssh.port should pickup on the deconflicted port change when you have overridden the ssh port.

The workaround for this currently is simply to hardcode the host port and not use auto_correct when you are overriding the ssh port. Every thing that needs ssh port forwarding you must simply manually ensure they don't conflict.

[dragon788]

Interesting, this could definitely be a bug. You can also run vagrant port after you VM is running to see what ports are forwarded and vagrant ssh-config to see the ports it think it will be using and the username/key
information.

Can you try this and paste back the results to see if it is indeed showing
one thing but using another?

On Mon, Sep 26, 2016 at 4:40 PM, Joseph Gilbert notifications@github.com
wrote:

@dragon788 https://github.com/dragon788 I think that @rvangundy
https://github.com/rvangundy is correct. When you deconflict a port
using auto_correct and then set the port in config.ssh.host, this will
break if the port is actually changed.

In my case I have 2 Vagrantfiles that need to do this and when you launch
both vagrant's, one of the two will become deconflicted, but when you run
ssh, both terminals will ssh into the same box.

If you run with VAGRANT_LOG=INFO you'll see that the 'undeconflicted' port
is being used via vagrant ssh in both Vagrantfiles.

I'm not sure how to get around this. It looks like the problem is that the
'deconfliction' algorithm is a runtime-only feature. When you run 'vagrant
ssh' it re-evaluates the Vagrantfile and pulls the 'undeconflicted' port
out of the config. (makes sense because there is no way to determine the
port collision mapping after the fact...)

I added this:

config.vm.network "forwarded_port", id: "ssh", guest: 22, host: 2222,
auto_correct: true
config.vm.networks.each do |type, options|
if type == :forwarded_port
print options[:host]
end
end

To verify that even after port deconfliction, the wrong port is used for
doing ssh. Again, this is because the config is re-evaluated on a 'vagrant
ssh'.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3232 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdxXvCe4AzPlM6xstnPuhD6YIE8bvCRks5quDvEgaJpZM4Bp86c
.

[ascotan]

I can't do a 'vagrant port' because I'm using the docker provider and it apparently doesn't support that. However:

---

....
default: Successfully built b03e6dcb7030
default:
default: Image: b03e6dcb7030
==> default: Creating the container...
default: Name: yyyy
default: Image: b03e6dcb7030
default: Volume: /Users/name/Desktop/code/gitlab/yyyy:/vagrant
default: Port: 2222:22
default:
default: Container created: a7c7353b87ac8d7e
==> default: Starting container...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: localhost:2222
default: SSH username: vagrant
default: SSH auth method: password
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Running provisioner: ansible_local...
default: Running ansible-playbook...

....

....
default: Successfully built b03e6dcb7030
default:
default: Image: b03e6dcb7030
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Creating the container...
default: Name: xxx
default: Image: b03e6dcb7030
default: Volume: /Users/name/Desktop/code/gitlab/xxx:/vagrant
default: Port: 2200:22
default:
default: Container created: 6a38003c3d824346
==> default: Starting container...
==> default: Waiting for machine to boot. This may take a few minutes...
default: SSH address: localhost:2222
default: SSH username: vagrant
default: SSH auth method: password
default:
default: Inserting generated public key within guest...
default: Removing insecure key from the guest if it's present...
default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Running provisioner: ansible_local...
default: Running ansible-playbook...
blah blah blah

....

....
name ~/Desktop/code/gitlab/yyy (develop) $ vagrant ssh-config
Host default
HostName localhost
User vagrant
Port 2222
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile /Users/name/Desktop/code/gitlab/yyy/.vagrant/machines/default/docker/private_key
IdentitiesOnly yes
LogLevel FATAL

....

....
name ~/Desktop/code/gitlab/xxx (develop) $ vagrant ssh-config
Host default
HostName localhost
User vagrant
Port 2222
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile /Users/name/Desktop/code/gitlab/xxx/.vagrant/machines/default/docker/private_key
IdentitiesOnly yes
LogLevel FATAL

[ascotan]

Both Vagrantfiles have the following:

config.vm.network "forwarded_port", id: "ssh", guest: 22, host: 2222, auto_correct: true config.ssh.host = "localhost" config.ssh.port = 2222

[dragon788]

Since you've already given it a tagged name of SSH which should set a flag
for vagrant to follow, is there any reason you are providing the additional
specific ssh port configuration?

On Sep 26, 2016 5:01 PM, "Joseph Gilbert" notifications@github.com wrote:

Both Vagrantfiles have the following:

config.vm.network "forwarded_port", id: "ssh", guest: 22, host: 2222,
auto_correct: true
config.ssh.host = "localhost"
config.ssh.port = 2222

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3232 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdxXnuLWQBttYXilT1IsHRTAl-erAHjks5quEDOgaJpZM4Bp86c
.

[dragon788]

So looking at the documentation the official way to pull this off is not to
set the config.ssh.port but to set config.ssh.guest_port.

config.ssh.guest_port - The port on the guest that SSH is running on. This
is used by some providers to detect forwarded ports for SSH. For example,
if this is set to 22 (the default), and Vagrant detects a forwarded port to
port 22 on the guest from port 4567 on the host, Vagrant will attempt to
use port 4567 to talk to the guest if there is no other option.

That way it doesn't matter which port it ends up on outside the VM, it will
examine the port forward config and anything forwarded to port 22 on the
guest will be assumed to be the SSH server.

On Sep 26, 2016 6:01 PM, "dragon788" wrote:

Since you've already given it a tagged name of SSH which should set a flag
for vagrant to follow, is there any reason you are providing the additional
specific ssh port configuration?

On Sep 26, 2016 5:01 PM, "Joseph Gilbert" notifications@github.com
wrote:

Both Vagrantfiles have the following:

config.vm.network "forwarded_port", id: "ssh", guest: 22, host: 2222,
auto_correct: true
config.ssh.host = "localhost"
config.ssh.port = 2222

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3232 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAdxXnuLWQBttYXilT1IsHRTAl-erAHjks5quEDOgaJpZM4Bp86c
.

[ascotan]

Sadly this does not appear to solve the problem. I wish it did. I've tried various permutations of guest_port/port and no go. If a port re-mapping occurs during the creation of the forwarded port, config.ssh appears to not be aware of the change and ssh connections fail. This only occurs when another Vagrantfile launches something with the exact same port forwards for ssh.

For now I'm using something like:
unique_host_port = 2300
config.vm.network "forwarded_port", id: "ssh", guest: 22, host: unique_host_port
config.ssh.host = "localhost"
config.ssh.port = unique_host_port

[ascotan]

@dragon788 Yea in answer to your question. The reason I was doing it this way is that I'm running docker for mac and they currently have a terrible limitation that there is no docker0 network native on the system. Because of that, 172.17.x.x address are not resolvable. Therefore, if I leave off the config.ssh.xxx stuff, vagrant attempts to ssh into the actual IPV4 address of the container (which is unreachable).

Therefore, if you use the docker provider for vagrant (as opposed to docker compose...) and you want to use native docker, you end up here - overriding the ssh port on the container - and discovering that the host ports must be set manually for every container you launch :(

[andkirby]

Yeah, it would be great at least to keep config.ssh forwarding to IP 127.0.0.1, at least.
Could you please implement this?
Just to avoid global 0.0.0.0:22 in guest machine.

This construction is prohibited:

config.ssh.guest = '127.0.0.1'

Result after vagrant up:

SSH:
* The following settings shouldn't exist: guest

It'd be great to have it.

I don't know, maybe SSH service can listen globally only.

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.