I have a MacBook Pro 64 bit Version: 10.8.5 .
I installed VirtualBox 4.3.4 on it.
I used to install Debian Guest OSs.
I used under Network 'NAT' with Port Forwarding
There I mapped the Port 22 of the Guest OS with 60xx Ports.
Then I opened the shell on my Mac and did a ssh connection for example in the following way:
ssh -p 6011 root@localhost
And it worked always fine.
Then I installed Oracle Linux6 on my VirtualBox.
And I did a Port Mapping: Port 22 on Oracle Linux with 6017 on my Mac.
When I do
ssh -p 6017 root@localhost
ssh_exchange_identification: Connection closed by remote host
I think that has anything to do with the configuration of /etc/ssh/sshd_config?!
Can anybody show me how this file should look like?
Or do I have another problem?
Thanks for any help!
Why do you bother with the NAT adapter? The NAT adapter is designed to make connections on behalf of the host (Macbook) network adapter and TCP/IP address, but shielding the virtual machine from incoming network connections. If you setup port forwarding there are also limits.
It will be a lot easier if you configure your VM to use the bridged network adapter instead and forget about the port forwarding thing. As such the problem is not SSH or Oracle Linux, but Virtualbox, which actually has its own forum at virtualbox.org.
To make port forwarding work with NAT you need to create the right port forwarding rule in the VBox VM configuration: For instance:
Host (Macbook): 10.0.0.1 Port 6000
Guest (OL) 10.0.3.15 (depends on your NAT DHCP) Port 22.
Then you can establish a connection to the guest OS by connecting to the Host OS at the named port, e.g.
ssh -p 6000 firstname.lastname@example.org
Because of the NAT port forwarding setup, this will connect to 10.0.3.15 port 22.
You may have to disable your local IP firewall (System Preferences/Security/Firewall)
To troubleshoot the connection you can add the -vvv parameter to the ssh command.
I would expect to see a man-in-the-middle-attack warning on the client (Mac side) as both attempts use localhost (single hostname) to connect (via different ports) to different servers (VMs).
The client should store the signature of the server against the hostname (or IP) used for the ssh connection - in file $HOME/.ssh/known_hosts. If localhost is used for a ssh connection to server1, then server1's signature should reside in that file as a known host signature for localhost. Attempting to use localhost again for server2, should fail with a man-in-the-middle-attack as the ssh client will detect that server2's signature (supplied for localhost) does not match the known host signature (of server1) for localhost.
Thanks for your comments!
I use 'bridged network adapter' if I want to connect from my 'Guest'-OS to the Internet.
In my case I want to configure my Mac with its OSes as a 'Stand-Alone' Machine
(I live in Mexiko on the Countryside and often I don't have connection to the Internet).
That means, that my Mac is my Client and my Host-Server at the same time.
I install a database on my 'Guest OS', start my 'Guest OS' and that all.
All the rest I want to do, is to access to my 'Guest OS' from my Mac.
I do all my SQL, PL/SQL and DBA stuff from Oracle SQL Developer installed on my Mac.
I work with APEX and I access to the Database installed on my OS via my Browser installed on my Mac.
And for any work on my Guest Linux OS, I do that with my Mac Shell.
I did the same for many time with my Linux Guest OSes Debian and Ubuntu.
And it worked always fine.
But I never tried it with RedHat Systems.
I compared my /etc/ssh/sshd_config of my Oracle Linux OS with /etc/ssh/sshd_config of my Debian OS.
And the configuration is very different.
So I don't think, that it is a problem of my VirtualBox Network Configuration.
If it would be a problem of my VirtualBox Network Configuration, why does it run with my Debian OSes without problems?
Thanks for any help!
Debian based systems like Ubuntu and Red Hat Enterprise systems like Oracle Linux are very different. The fundamentals of the VirtualBox network adapter however remain the same.
The NAT adapter is the default adapter because it allows people to connect to the Internet on behalf of the host network and provides DHCP. It pretty much works out of the box and does not require to have a clue about networking or routing, or how to configure the network adapter. However is is only good for outgoing connections on behalf of the host network. It does not communicate between virtual machines and requires DHCP. It is definitely the wrong choice of adapter for your purpose. Why would you want to use Network Address Translation to connect from your host OS to the guest system? Sure you can configure NAT with port forwarding, but sorry, its nonsense. Please check the VirtualBox documentation.
The Bridged Adapter will be you best option. Just configure all you virtual machines to use the same network than your host system and you are good to go in any direction. You can also create a virtual network adapter, if necessary, in Mac OS X easily.
Perhaps the difference between your Ubuntu systems and OL is that you have forgotten to select the checkbox to connect the network adapter during system startup. You can check your configuration file /etc/sysconfig/network-scripts/ifcfg-eth0 and verify ONBOOT=yes.
Thanks for your answer!
I installed all my Linux Guest OSes on my Mac only for developing and testing issues and no productive issues!
And NAT with Port Forwarding is an easy way to connect from my Mac to the Guest OS.
And it works well with DHCP, what I'm using!
But, as you said, it it not the ideal way!
So, as you proposed, I will read first the VirtualBox Documentation!
I will inform you how it worked!
The bridged network adapter uses a kernel driver on the host system site (Mac) to intercept and inject network traffic of the virtual machine using the host network. It will certainly work. DHCP is not a suitable network configuration for a server. I use Mac OS X myself and have meanwhile accumulated over 60 virtual machines of all kinds and releases. I always use the bridged adapter. Just create your own network, which you most likely have already. You can also combine several adapters, e.g. bridged for your internal access (eth0) and add NAT for VM Internet access (eth1).