SSH to guest Debian stretch on a VirtualBox Windows 7 host from LAN, howto

Suppose you have a virtual machine (or VM), in which you have installed a guest operating system: e.g., Debian stretch. And, it's running under a (physical) Windows 7 (Home Premium SP1) host operating system (by means of Oracle's VirtualBox software developed by wholly-owned Innotek GmbH).

You might wish to access that Debian guest from another box on your host's LAN. Here's how to do so with SSH. (If you're on Windows, you can do this IMO most enjoyably from Git Bash or Cygwin, although SSHing more directly from Windows is also possible.)

These instructions should work just as well with Debian's jessie or wheezy releases (in all likelihood). One caveat: Debian normally disallows SSH access as root. Instead, log in as a regular user and do 'sudo' (or 'su') if you wish to be root.

GUEST

In your guest Debian operating system, install the software to accept your inbound SSH connection:

sudo apt-get install openssh-server

HOST

I. For the desired VM, adjust its VirtualBox settings:

1. Choose network type NAT.
2. Forward some inbound port on the host to inbound port 22 on the guest.

Here are the details on how to accomplish this:

1. To provide an additional layer of security, pick a number between 1024 and 49151 (inclusive and random) to be the inbound local port ('host port') on your physical VirtualBox host.
2. In VirtualBox Manager, select your desired VM (it can be running).
3. In the VirtualBox Manager menu, click Machine–Settings–Network.
4. Ensure the 'Adapter 1' tab is selected.
5. Ensure 'Enable Network Adapter' is checked.
6. You'll see the words 'Attached to'. There, select 'NAT'.
7. Ensure that the blue, drop-down arrow by the word 'Advanced' has dropped down to show you the advanced settings.
8. Click the 'Port Forwarding' button.
9. Click the green icon, bearing a plus sign, whose tooltip is 'Adds new port forwarding rule'.
10. Find and select the newly-created row.
11. In the 'Name' column, type 'guestssh'.
12. Ensure 'Protocol' is 'TCP'.
13. In the 'Host Port' column, type your inbound local port.
14. In the 'Guest Port' column, type '22'.

II. Set up Windows Firewall to allow the desired SSH connection, by following the steps in this post to create the new firewall rule. In particular:

• Name it 'VirtualBoxSSHInPort' followed by the port number.
• Under 'Edge traversal', ensure 'Block edge traversal' is selected.
• For the path to the receiving program, use the path to the VirtualBox executable (on your host system).

III. Determine the Internet Protocol (IP) address of your VirtualBox host as viewed by its active router. Here's how:

1. In your VirtualBox host's system tray, click the icon of the active router.
2. Make sure the drop-down arrow by the words 'Wireless Network Connection' is selected, so you see a list of routers.
3. Find the name of your active router in the list.
4. Right-click that name.
5. Click on 'Status'.
6. Click the 'Details' button.
7. In the 'Property' column, find the words 'IPv4 Address'.
8. Read across to the 'Value' column.
9. Note its four, dot-separated numbers. That's the IP address of your VirtualBox host, in the LAN provided by its active router. And for your SSH connection command it will be your target IP address.

In order to allow SSH connections to your VirtualBox guest, the VirtualBox software does Network Address Translation (NAT). So, BTW, your VirtualBox guest will report that you are logged in from some other LAN (with another IP address), not from your active router's LAN. The foreign port number will be different, as well.

IV. Now you can test the availability of your inbound SSH connection.

By default, to log in, SSH detects your local username and tries to use it.

Typical Windows usernames begin with a capital letter, yet typical GNU/Linux usernames begin with a lower-case letter. Therefore SSH's default username likely will fail. So instead (from Windows), the SSH command to access your VirtualBox VM is:

$ ssh {lowercase username}@{target IP address} -p {host port}

Since my name (and Windows username) is Mark, I enter:

$ ssh mark@{target IP address} -p {host port}

Alternatively, instead of logging in, you can run a single command (per these tutorials) and retrieve its output to your local, non-SSH computer—e.g.:

$ ssh mark@{target IP address} -p {host port} cat some-file > here

Or, you can use SCP.

Copyright (c) 2015 Mark D. Blackwell.

Cygwin, Git Bash and native Windows apps, howto

I use Debian and Windows XP — the latter sometimes on a netbook, but principally on a fast desktop computer (it has a nice monitor). On Debian, I develop software in the normal way. But, when I'm on Windows, I have to resort to a variety of techniques.

On a fast desktop computer, I use many native Windows apps (e.g. 7-Zip instead of Tar with compression; in the Windows way). I use Cygwin apps where a good native Windows version is lacking.

For example, previously I ran Cygwin's LilyPond till I noticed the niceness of the Windows version.

But mostly on Cygwin I enjoy the Bash command line interface and its filesystem.

My desktop's Git is through Cygwin, but the netbook has msysGit (with its own version of Bash). (Msysgit is also known as Git Bash.)

Within msysGit, so far, Bash's symbolic links aren't good — if you make one, it actually copies the whole folder!

I could try alternatives (suggested on MinGW's MSYS page) such as Interix (also known as Microsoft's SFU or SUA).

Paths

In order to maintain only one copy on the desktop of things like SSH keys (used by Git) I followed instructions to move my Cygwin user home directory to the same place as my Windows user home directory — which worked just fine! (Additionally, I set LANG to en_US.UTF-8, as suggested.)

Now, this command works just fine for me:

ruby app/hello.rb

I seem to recall that, for a while, it gave me an error, 'no such file'. Perhaps when I cleaned and upgraded my Cygwin installation (including my .bash* files) and then did a couple of reboots, the problem went away. (Don't you hate that?)

Cygwin can run both Cygwin apps, and native Windows apps. For speed and maintainability reasons, it's good to minimize the programs installed into Cygwin, doing so only if no native Windows version will succeed there (or can conveniently be run outside it). For example, my RubyGems installation is a native Windows one.

In Cygwin, the command, 'rake' (e.g.) might give you:

No such file or directory -- /cygdrive/c/progra/ruby/1.8.7-p352/bin/rake (LoadError)

even though it is found by, 'which rake':

/cygdrive/c/progra/ruby/1.8.7-p352/bin/rake

The solution (in Cygwin) is to type, 'rake.bat' (gem.bat, irb.bat, pik.bat, etc.).

If desired, you can alias rake, gem, irb and pik as with Robert Wahler's Stack Overflow answer, but just on the command line — it doesn't normally work in Bash scripts. (E.g., 'alias rake=rake.bat' — to reverse it: 'unalias rake'.)

If you are having problems with native Windows programs still not finding files in Cygwin, you might want to look at one aspect of Cygwin filesystems (some sources say) which requires special handling.

The documentation says passing filesystem paths (in Cygwin Bash) to native Windows apps (such as Ruby) is done (although sometimes I need to) in one of two ways:

One is to use native 'Win32' paths — two examples follow, for which I made a Ruby test program ('app/hello.rb' containing only, 'p __FILE__'). They require at least one, escaped backslash:

In (Cygwin's) current directory (using native Win32 paths):

ruby '.\hello.rb'
ruby .\\hello.rb

Or in 'app', relative to the current directory:

ruby 'app\hello.rb'
ruby app\\hello.rb

The other is to use cygpath:

In the current directory (add, '-a' for the full path):

ruby "`cygpath -m hello.rb`"

Or in the relative directory, 'app' (recently, with one long path, I had to do it this way):

ruby "`cygpath -m app/hello.rb`"

Permissions

Developing with both msysGit and Cygwin normally generates Unix permissions problems. Their Gits flip-flop the permission bits between '100777' (Cygwin) and '100644' (msysGit) on most files! Those with certain typically-executable extensions like .exe and .bat alternate between '100777' (Cygwin) and '100755' (msysGit).

To avoid most of this problem, you can mount your Cygwin user home directory in a way close to the msysGit method:

/cygdrive/c/Documents\040and\040Settings/[user name] /home/[user name] ntfs binary,noacl,bind 0 0

'noacl' tells Cygwin not to use the Access Control Lists found in Microsoft's NT tree. (BTW, as of Cygwin 1.7.9-1, 'posix=1' and 'nouser' are ignored here.)

The exception is that Cygwin will look for '#!' at the beginning of files to set the executable bit; msysGit, as mentioned above, will look at extensions like .exe and .bat.

In a development project, it might be useful to set write- and execute-permissions (at least the 'user' bits). If you want to manipulate permission bits further in your repository, you can tell msysGit (or even Cygwin Git) to ignore permission bit differences. Then you can set (see Jakub Narębski's answer) the (user?) execute bits:

git update-index --chmod=+x [file paths]

and reset them:

git update-index --chmod=-x [file paths]

before you do, 'git commit'.

(Tested with Ruby 1.8.7 (2011-06-30 patchlevel 352) [i386-mingw32], Cygwin 1.7.9-1.)

BTW, to see what Cygwin version you are running:

cygcheck -c cygwin

References

file modes - Cygwin
NT Security - Cygwin
file modes - msysGit
discussion

Copyright (c) 2011, 2015 Mark D. Blackwell.