Kiosk Downloading

• The Tunnel Man Mac Os Sierra
• The Tunnel Man Mac Os 8

Leopard to Big Sur (Mac OS X)

Mac OS X, 10.5-10.11

File Sharing, Screen Sharing (or Remote Desktop)

Alicia Quatermain & The Stone of Fate for iPad, iPhone, Android, Mac & PC! Accompany Alicia Quatermain on her latest time-management adventure and help save the world and get the treasure!! Mac: Discontinue Application Filter (for Mac OS Big S) 3.9.0.2161 2020-07-11. New network driver for Windows: improves speeds for OpenVPN, Wireguard, OpenWeb significantly (700+ mbit/sec) support for PPPoE connection on linux; compatibility with upcoming Mac OS 11 for OpenVPN/Wireguard; windows installer ships 64-bit and 32-bit versions of software.

(-using zsh/bash Terminal commands, among other things)

-with thanks to Bob Harris, who generously and patiently helped me through this the first time, on Apple Discussions

I note that some of the details of menus and options vary as we progress through operating systems, but I believe that it's clear enough. Ask if anything is unclear.

What

This is to have Internet access to your base computer (home, office, etc.), one name for which is the 'server', from another computer at a different location (different room or different continent), the 'client'. (In my case, the server is an Apple desktop computer - an 'ordinary' desktop computer - and the client is a Mac laptop/notebook computer - which makes sense for me but is not otherwise relevant.)

This access is strongly and securely encrypted, so that no one eavesdropping on a router along the way can decipher your data, and apparently it will often 'tunnel' through otherwise difficult outgoing firewalls (from wherever you are with your 'client' computer), although I have seen this fail.

There are probably several approaches to this, but the one described here uses an 'SSH tunnel' ('SSH' meaning 'Secure Shell'), including its optional Public/Private Key feature. No one can reasonably infiltrate your tunnel without both keys, either of which is kept on only one of the two computers, and which are not reverse-decrypt-able in practical terms, and which themselves can be further password-protected for multiple layers of security.

And the wonderful thing about all of this is that it's included in Mac OS X at no extra charge; all you have to do is learn how to do it (which will however require some time)!

Alternatives: there are commercial software programs which will do this for you, but I didn't find them much easier than doing it this way. I have not looked at Apple's own 'Remote Desktop' program, which is a bit pricey. I haven't really looked at how iCloud might function in this context. Connecting to a non-Mac computer or to earlier versions of Mac OS X may be possible with further knowledge, which however I do not have. And so on; this is just one approach of many.

Usual disclaimers:

• you're on your own, and this is not my professional area;
• this method works starting with Leopard (Mac OS X 10.5 or above) to the best of my knowledge, at the time of writing.

Why

1. File Sharing over a 'VPN' ('virtual private network') - Use data files on your server from wherever else in the world you are. This is exactly like using files on another computer on your private network, except that you've securely extended your network over the Internet. Working while leaving your data on your server can be very convenient, in that you don't have to have multiple copies of files, or remember which one is the most recent, or somehow keep them synchronized. (Alternatively, especially for large files, you could copy a file to your client computer, and when done working with it, copy it back to your server; your call.)
2. Screen Sharing (aka 'Remote Desktop') - Control your server remotely, making keyboard and mouse inputs to it, over your network. You see a copy of your server's monitor on your client computer's monitor. Someone watching your server's monitor would see it doing what it would be doing if you were there, even though you could be half-way around the world (or only across the room). You may have:
   • very large files on your server which could be cumbersome to use over the relatively slow Internet, or
   • software not installed on your client computer, for valid reasons.
   With Screen Sharing, the data which you transmit over the network is usually not much more than just a compressed image of your server's monitor display, which may often be substantially less than actually transferring whole files. (Sound is not transmitted, so you won't hear your server's noises - alarms, music - nothing. [Is that information still correct?])
3. You can do other things, such as make your server into a private web server, although I have no experience with this.

Update!

Mac Mini 2019, OS X Catalina (10.15)

The following will make more sense perhaps after reading the 'How?' section below, but I want to state up here near the top that I have had recent troubles, and that I have solved them.

Upgrading in the Autumn of 2019 to a new Mac Mini, using OS X 10.15 (Catalina): the tunnel crumped. I changed many settings and spent too long peering into help files and user forums, without any joy. The local (client) computer said, 'connection refused' at the Remote Login port, and would not budge. This persisted over many days.

One day it suddenly worked again, and all has been well, and ... I'm not quite sure what I did. (Sorry!) Whether this has anything to do with the Mini's new hardware security chip, I do not know. Whether it relates to new features of 10.15, I also do not know. I am not alone in having access challenges, but was unable to locate any information on my exact scenario. But here are a few observations which may help you.

What I Did

The main thing seems to have been converting from AFP to SMB for file-sharing. (But I may be wrong about that.) Apple has recently 'deprecated' (what a word the geeks have chosen; dictionary definition: 'express disapproval of'!) file-sharing using the AFP protocol, and has joined much of the rest of the (computer) world, as I understand it, by using SMB, and: SMB uses a different port! So everywhere below where you see port 445 (SMB), it used to be 548 (AFP). (No matter that I had the Sharing settings configured to use both - my tunnel suddenly became happy soon after settling on SMB; it took me a while to wonder if that meant using a different port - it did.)

Now ... the 'connection refused' message referred to the Remote Login port, not the File Sharing port, so ... go figure.

In the Privacy panel of the Security & Privacy settings, I have added Terminal under Accessibility and under Full Disk Access. Here and there around yer InterWeb I have found suggestions for many other settings, none of which have been helpful nor necessary for me.

I adjusted users, in Sharing, under Screen Sharing, File Sharing, and Remote Login, first of all separating out another account so that I'm not logging into an administrator account (safer that way, apparently), but I don't think that's the answer. Nonetheless, both the 'Standard' and 'Admin' users are included. There is no way I found to include the user from the local client computer, and it is working without that. Specifying, where possible, 'All users' did not help, and I have reverted to 'Only these users:'.

It didn't appear to have anything to do with replacing the Airport Extreme Router - no longer available from Apple or from anyone - with a LinkSys router; that worked fine for months until I got the 2019 Mini with OS X 10.15. However, I did rearrange the order of port-forwardings to put 22 - Remote Login - first.

The old section on this page about how to configure an Airport Extreme has therefore been removed. Every router will be different. Read your help files. (If you can't read your help files, then you possibly shouldn't be reading this page.)

On my new Linksys, I needed to assign at least one permanent IP to the remote host, and that is at Connectivity, Local Network, DHCP Reservations. I put my static ports inside the dynamic range - a change from my older (now broken) Airport wireless router. I needed to forward three ports - more below - and that is at Security, Apps and Gaming, Single Port Forwarding.

During the somewhat random debugging of my SSH tunnel failure, I used a port-testing website to see what was open (and/or visible) and closed. I rather doubt that the resulting information contributed, but there it is in case you might find it helpful. The redirected ports, by the way, all seemed to be working as specified, and the native ports - 22, 445 and 5900 - could not even be seen (good!).

I tried disabling the Firewall on the remote host, and it didn't help. I have re-enabled it. All remains well. Under Advanced, I find that my three sharing services are there, as well as one other, and ... I didn't do any of that. The OS did it by itself. Obviously (I think), I have not selected 'Block all incoming connections', and I have not selected 'Enable stealth mode', and the other settings as found are fairly liberal.

OS X 10.15 in Terminal now uses, by default, zsh instead of bash. I have tried it using both, and that didn't seem to be a factor either.

At various points, if making substantial settings changes, then I of course rebooted both computers and the wireless router.

How?

For illustration purposes only:

1. Let's give the server (the 'remote') a computer name of 'YourServer', with a user-account which you wish to access called 'ServerAcct'.
2. We'll call the client ('local') computer 'YourClient', with an account called 'ClientAcct'.
3. For many of us, our server's address, its 'IP', changes from time to time, under the control of our ISP ('Internet Service Provider'). This makes the server impossible to find over the Internet, so to get around this we need a 'Dynamic Domain Name Server' service (DDNS) .
   • I was using Dyn, formerly free, and as the price went up I have switched to Dynu (but there are others), which as of January of 2021 is working well and required very little re-configuration.
   • At whatever DDNS you have chosen, create a hostname (I'll use 'soulmate' only for purposes of illustration), and follow the instructions, and you'll end up with an address such as 'soulmate.ddnsservice.yup'.
   • Download their 'DNS Updater' app (from your server, not from your client computer), install and run it. I believe that it needs to be running on your server all the time when you're using your SSH connection.
   This means that wherever you are, you can use that address to find your server, even if the server's address (its 'IP') changes. (Don't worry - your computer will still be 'closed' for all practical purposes to the outside world, presuming that you have a login password and don't go around advertising your 'soulmate' name.) The Updater on your server keeps the DDNS server aware of your server's current IP and translates your 'soulmate' address into that IP.
4. To make things more stable, I assign static network IPs to both computers. This is done on your router, and the details vary.
   • Find and note the 'DHCP Beginning Address' and the 'DHCP Ending Address' - you'll need this 'dynamic address range' in a moment.
   • I reserve these IPs by MAC Address', and I find the MAC address by ...
   • ... (and this has varied a bit as the OS updates over the years) opening About This Mac from the Apple menu (upper left), go to System Report, Network, Wi-Fi, and in there is 'MAC Address'. It uses a format like this: 10:AB:23:DE:45:F6.
   • In the router's DHCP Static IP settings, enter that MAC number, and choose an IP address. It will usually be 10.0.1.x (or 192.168.1.x), and choose a number for 'x'. See the 'Update!' section above. Let's similarly call the client computer's address 10.0.1.y. (Doing this for both computers makes things easier for one step coming up.)
   • You may close System Information.
5. For added security, here is an optional step to reassign your SSH-Login port number, so that hackers going around looking for 'standard' ports won't find yours in the usual place, and are unlikely to go looking any further. This done in your router settings - see again the 'Update!' section above. (Don't worry about what 'ports' are - just carry on.)
   • Port 22 is the Remote Login port, used by the SSH function. Forward port 22 to a 5-digit port, not over 65535(?). Five-digit ports are generally unassigned as defaults for anything, so are safe to use. (Some rare exceptions may apply.) In the examples below, I use '12345'. (Don't use that!) The IP you will associate with this MAC number is the private IP which you assigned to the remote host above ('x'). Keep a record of these numbers in some secure place.
   • Similarly forward port 445 (SMB File-sharing) and 5900 (screen-sharing); the examples below use '23456' and '34567', but choose something more random of your own. These will also both go to IP 'x'.
6. We're going to set certain settings in System Preferences, under Sharing.
   • On your server, make sure that you turn on 'Remote Login', 'File Sharing', and 'Screen Sharing'. (And leave them on forever - or at least when you're going to be away, if you can organize that.)
   • Similarly, on your client computer, make sure that 'File Sharing' and 'Remote Login' are turned on. There, you'll be able to turn them both off later.
7. Now we're going to generate our 'keys' - the things which give us encrypted security.
   • On the 'client' computer, open a program called 'Terminal'. This provides a 'command line' interface which can do many things not possible otherwise. The 'command prompt' will look something like: You're going to type (or safer would be to copy and paste) this command, then press the Enter key: You will be asked for a password, so as usual it should be a strong password, and something which you can remember. (Again, by using a password here, you foil someone even if they somehow stole both of your keys.) You will then see a 'key fingerprint' and 'randomart' which I store somewhere secure (in an encrypted text file), but I'm not sure that I will ever need them.
     This command also creates a new folder in your home folder (which is 'ClientAcct') called '.ssh' (the period starting a file or folder name means that it's invisible, or 'hidden' to use Mac OS X terminology, so you can't see them in Finder), with two files inside it, id_rsa and id_rsa.pub. These are the private and 'pub'-lic keys.
     
   • You can check this at the Terminal command prompt by looking inside the .ssh folder for files, and the command line for that could look like this:

8. scp ('Secure Copy') command

   N.B. I have trouble getting the 'scp' command to work consistently. Recently I first connected the two computers, just on the same private network, using Finder, so that ClientAcct shows up on ServerAcct and vice versa, and then the 'scp' command worked. There are several ways to do this connection, and most readers of this page will already know how: 'File Sharing' is already enabled (above). Find 'Network' or 'Shared' in Finder and go from there. You'll need to know the name and passwords for what we're calling here 'ClientAcct' and 'ServerAcct'. Terminal's 'scp' command (from ClientAcct) will also then ask you for the ServerAcct password - not your 'SSH key' password' - in order to perform its function. 'ssh' will ask for the same type of information, in the next step.

   Now, the private key stays on the client computer, but we've got to move the public key to the server. The command line for that will look like this: (You will of course throughout the following instructions substitute your own names and numbers for 'ServerAcct', 'x', 'ClientAcct', 'y', 'soulmate.ddnsservice.yup', etc.) This command copies the public file to the server's account's 'Home' folder (i.e. 'ServerAcct'), plainly visible (temporarily). On the server, you'll be able to see it in Finder. At this point or later, if you're sure that the file transfer worked, delete the public key from the client computer. The command will be: Check it again as above with the 'ls .ssh' command - it should be gone. It's important to delete it or someone stealing your laptop could figure out how to access your home computer (although the key itself is also password-protected).
9. Switch to working on the server. Open Terminal. The command prompt, using our illustration-names, will be: The first command will look like this: This creates a hidden folder (.ssh) on the server (like the one we made earlier on the client computer), inside your home folder (ServerAcct). (At this point, Terminal, despite that we're still working on the server, switches to a prompt indicating that it's working on the client. I just close the Terminal window and open a new one to get back to the server prompt.) Now, still on the server, we are going to insert or add the public key into a file called 'authorized_keys', which will be created or appended to, and which resides inside the .ssh folder. Be very careful about the exact command, without altering the spacing, etc. It can be copied and pasted from here into Terminal. Then, if you wish to be really compulsive, you can check this process by looking at the key itself and then at the authorized_keys file and see if they look the same, or at least if authorized_keys contains the same character sequence.
10. Delete the file on the server, id_rsa.pub. You can do this from Finder (or from Terminal, using 'rm id_rsa.pub', which does not put it in the Trash, but deletes it immediately). Empty the Trash; you need to make that public key as hard to find as possible. The only copy of it now resides inside the 'authorized_keys' file, inside the hidden folder '.ssh'.
11. We're close to being able to use our encrypted SSH tunnel.
    • Make sure that the server won't go to sleep or that if it does it can be awakened by 'network access' (System Preferences -> Energy Saver). Have the DDNS Updater or facsimile running properly.
12. Here we go.
    • From the client computer - and you can test this even if you're at your home or office, on the same private network with your server (although then make sure that each computer has 'ejected' the others 'account' so that you're sure that it's going to be the SSH tunnel which you're tesing) - open the Terminal program. Presuming that both computers have network connections of some kind, including Internet connections, type a command like this (substituting your own data, of course): When you do this, you may be asked on occasion for your key's password. You may occasionally get notices about 'authorized keys' and such, but they don't seem to disturb the process.
      You'll notice the '12345' from resetting the SSH Login port in your router earlier. The SSH 'request' comes in from the client computer on that port number, and is then sent from the router to the server with the standard number. (Don't worry; it just works.) With the other numbers, '23456' and '34567' (examples only - use other 'random' numbers when you do this yourself!), you're doing something similar for the standard ports for File Sharing and Screen Sharing, for added security.
    • And we get at those ports like this:
      From the client (local) computer, when the active menu is 'Finder', type 'Command-K' to get the 'Connect to Server' function (or get it from the Go menu).
    • For File sharing, enter: substituting whatever you chose for your port number. (Thereafter, 'Connect to Server' can save and remember your command so you can reuse it without typing.) For Screen Sharing, type: again substituting your own number.
      You may be asked each time for your SSH key password and/or your server's account name and password; or you may not be! (One of them echoes in the Terminal window, and one does not, i.e. you will not see your typing as you do it.)

We're (almost) done!

And that's it! Your encrypted SSH tunnel is up and functioning, and you can use File Sharing and Screen Sharing immediately.

It won't be as nearly fast over the Internet as on a private network, but it will work.

Sometimes, however, my tunnel collapses and I have to restart it. Rarely, it just doesn't work, and then two hours later, it may suddenly cooperate. If the server locks up, you're out of luck. I have mine to set to power back on automatically after a power failure (cool!).

Screen Sharing is faster if you 'Turn Scaling On' (View menu) and also use 'Adaptive' video resolution. You can copy and paste back and forth between the server and client computer from the Screen Sharing Edit menu, or from buttons in the Screen Sharing Toolbar.

Things which you will need to remember:

1. your key's password;
2. Your SSH 'Public TCP Port' number ('12345' in this example);
3. the internal network address of your server ('10.0.1.x' in this example);
4. the port you've chosen for File Sharing ('23456' in this example), the port you've chosen for Screen Sharing ('34567' in this example), and ports for other functions which you may use such as 'Web server';
5. your 'Account' name on your server ('ServerAcct' in this example) and its password (the same one you use for a usual, local login);
6. your DDNS address ('soulmate.ddnsservice.yup' in this example);
7. ensure that your server won't 'sleep' or that it awakes properly from sleep;
8. leave the DDNS Updater (or equivalent) running on the server.

(I remember all of the numbers by keeping them in a password-protected virtual disk on my computer[s], but that's another story.)

Prevent Tunnel Collapse

This didn't seem to happen as often in the past as it does now, that the tunnel collapses, with the message: 'Write failed: Broken pipe'. Sometimes that's because the server times out after some undetermined period of inactivity. There are several places around the Web which discuss options to tame this behaviour, but the best option for me seemed to be to place a file called 'config' (with very restrictive permissions) inside the .ssh folder on the client. That file on my client computer contains exactly this:

Apparently, indenting the second line matters(?!). Anyway, this sends a tiny confirmation (i.e. low overhead) every 300 seconds to the server, more or less saying, 'I'm still here. Keep the tunnel open!' You'll need to know how to use the move ('mv') or copy ('cp') command if you use TextEdit to make the file, and how to do the addressing. For example, from your client account 'Home' folder, presuming that you've created 'config' there:

The restrictive permissions could be like this:

These five commands i) change to the .ssh folder, ii) remove 'ACL permissions' (if any), iii) limit use of the config file to the owner only, iv) show the permissions of all the files in the folder, and v) change back to the 'Home' folder. The listing for the config file on my computer looks like this:

The Tunnel Man Mac Os Sierra

I like lots of password protection, but haven't quite deduced why, when I occasionally have to re-initialize my SSH files, they vary. Recently, I was asked for no passwords at all. Using this commands on the client, starting from the home folder:

resulting in being asked for the private (client) key password (but I had to reboot the computer first before that happened).

Interesting: having redone the entire procedure from scratch (because replaced internal hard drive), all of the permissions presumably went back to default, and my Client now logs in with no password requests. So, will update the permissions of course (on both computers?).

Addendum

A few things have come up, as of 2015 February, so here they are:

• Recently, Screen Sharing failed on my host/server (remote) computer. I was thousands of light-years away (might as well have been). I could still File Share, and clearly the SSH tunnel was still functioning. I rebooted my local (client) computer, to no avail. So I took a chance and rebooted the remote/host/server computer, which I was able to do with a Terminal command I found on the Net. Caution: this is a 'sudo' command so be very careful what you're doing using those, and don't blame me if things go south. Note also that this works only if your SSH tunnel is still running, the 'command prompt' showing that you're effectively working on your server (remote), not the (right-in-front-of-you) client (local).The command is:and that did work. The remote computer did an emergency, save-nothing, take-no-prisoners reboot, and it reappeared a few minutes later, when I opened a new SSH tunnel, with File Sharing and Screen Sharing features both working perfectly. (Whew!)

Conclusion

So, having written it down, no wonder it took a while the first time. There's a lot to it.

Enjoy! Questions, comments and suggestions always welcome, but remember that this isn't my 'area'.

Charles T. Low

So far in this series of posts on ssh on macOS:

• SSH Tunnels (this post)

The Tunnel Man Mac Os 8

Please consider supporting Scripting OS X by buying one of my books!

We have learned so far that ssh is a really useful and flexible protocol. It can be used to connect securely to a remote shell, or to transfer files securely.

Rather than providing the shell itself, ssh provides a secure way to transmit data to and from the remote shell. In a similar way, ssh can be used to provide access to other remote services as well.

SSH Tunnels with Two Computers

Access to important services are usually blocked behind a firewall or router. Since ssh, when setup correctly, is quite secure, you can usually get access to a server with ssh even when other protocols are blocked. (Though some administrators move ssh access to a different port than the default 22.)

You can use ssh port forwarding or ‘tunneling’ to gain access to other services through ssh.

Imagine you want to use Screen Sharing to connect to a remote Mac (remote.example.com). Screen Sharing on macOS uses the VNC port 5900 to connect to a remote Mac. Since VNC itself is inherently insecure, (mac Screen Sharing adds a few things to make it more secure) this port is blocked by many firewalls.

However, I do have ssh access to remote.example.com. So, how do I tell both systems to ‘tunnel’ the screen sharing traffic through ssh?

(When you test this, remember to enable either ‘Screen Sharing’ or ‘Remote Management’ (i.e Apple Remote Desktop) access in the ‘Sharing’ pane in System Preferences on the remote Mac.)

The tunnel starts on my local machine and ends on remote.example.com at port 5900 (where the screen sharing service is listening on the remote Mac.)

The starting point also needs a port number, and I can basically choose freely. Port numbers under 1000 and over 49000 are reserved for the system and require root privileges. There are also many numbers that are commonly used by certain services (such as 5900 for VNC/Screen Sharing) and may already be in use. I will choose 5901 for the local port.

To connect the local port 5901 to port 5900 on the remote Mac use the following command:

(You can just try this with a second Mac or virtual machine in your network, even without a firewall.)

The syntax of this command is less than obvious. Let’s break it into pieces:

The -N option tells ssh that we do not want to invoke a remote shell or run a remote command.

The -L option creates a local port forwarding setup. This option takes a parameter with three or four parts, separated by colons :. The first pair (localhost:5901) are the tunnel start point. The second pair (localhost:5900) are the remote end point of the tunnel.

The second localhost is resolved on the remote host, so this means port 5900 on the remote host.

The last parameter states the remote host, to connect to, remote.example.com.

This commands tell ssh to connect to remote.example.com and establish a tunnel that transfers traffic from port 5901 on my computer to port 5900 on the remote computer.

Since the origin of my tunnel is usually on my local computer, the first localhost can be omitted, so you only see the origin port.

When you execute the command nothing will happen. You will not even get a new prompt, because the ssh process is running until you cancel it with ctrl-C. Don’t cancel it yet, however, since it needs to run to provide the tunnel.

So, when you open the Screen Sharing application (from /System/Library/CoreServices/Applications/) and connect to localhost:5901 all traffic will be forwarded by sshto port 5900 on the remote Mac.

You can also use the open command to connect with Screen Sharing:

You should be able connect with Screen Sharing, even when port 5900 is blocked by a Firewall.

When you are done with the Screen Sharing session, you can end the ssh tunnel process in Terminal with ctrl-C.

You can also use ssh port to use the remote host as a gateway or ‘jump host’ to a third computer. Imagine you want to use Screen Sharing to connect to secundus.example.com behind a firewall and you only have ssh connection to primus.example.com available. You can tell primus to point the endpoint of an ssh tunnel at secundus with:

Note: secundus.example.com or whatever host or IP address you enter there will be resolved on the remote host. So you can use NAT IP addresses or .local host names here, even if they do not make sense in the network your work Mac is in. (They do have to make sense on the remote host, though, otherwise you will get an error.)

In the following examples the local IP address 192.168.1.200 or the Bonjour hostname Secundus.local will be resolved on the remote host, even if they don’t work on my local computer:

Either way, you can then point Screen Sharing at localhost:5902 and it will connect through primus to Screen Sharing on secundus.

Keep in mind, that while the connection from the start point (on your Mac) to the host primus is secured by ssh the connection from primus to secundus is not.

Stumbling over HTTP hosts

In general you can use ssh port forwarding (or tunnels) for any service. Some services however, may introduce extra pitfalls.

For example, I wanted to use ssh port forwarding to gain access to my home router’s web interface. I can use ‘Back to My Mac’ to ssh into one of the iMacs at home, and thought it should be easy to connect to the router with an ssh tunnel:

This seemed to work, but whenever I tried to point a browser to localhost:8080 it couldn’t connect to the web page. The problem here is not the ssh tunnel but the the web server on the router. As part of the http request, the browser sends the name of the domain requested to the web server. This allows web servers to host different pages for different domains. With this request, the browser told the router it wanted the web page for localhost and the router replied with “I don’t serve pages for that host”… (Your router might behave differently.)

With curl I could convince the router to serve me the page with:

However, since navigating the web interface of the router with curl is out of the question I had to find a different solution.

Tunnel All the Things!

What if I could send all traffic through the iMac at home?

With the command

I can create a tunnel from my computer (on port 9001) to the remote Mac that acts as a SOCKS proxy. Then I can set the Socks proxy to localhost:9001 in the proxy tab in the Network pane in System Preferences. You probably want to create a new network location for this setup. Then all network traffic will be securely routed through the ssh tunnel to my Mac at home where it can connect to the router.

This can also serve as a temporary VPN solution.

However it is somewhat painful to set up and maintain, so if you start using this more frequently, you probably need to look into a proper VPN service solution (some routers, ironically, provide one…).

Summary

• you can bypass firewalls and other network blocks by tunnel traffic for any service through a ssh tunnel
• the command describes which local port to connect to which port on the remote host
• you can even tell the remote host to connect the end point to a third computer, behind the firewall
• you can also create a SOCKS proxy with ssh to tunnel all traffic

Previous Post: Transferring Files with ssh