Inside SSH, Part 3
Pages: 1, 2
Testing the New, Secure Configuration
Now that you have modified the SSH configuration files, you need to tell the server that it needs to reread it--otherwise your settings will not take effect. The easiest way to do this is to use the Sharing preferences pane to disable Remote Login and enable it again.
Also, restart your administrative machine as an added security, to make sure that any changes you have made are taken into account. This restart is also a good time to make sure that automatic log in is turned off, if applicable, and that your log-in window does not give away the name of your account--Mike's computer, for example, is not a great idea if your account name is mike. On the other hand, it would be OK if your account name is john. Of course, this is applicable only if users are required to type in both their username and password to access their account.
Then, try to SSH in to the usual account and, in order to test the reaction of the SSH server, do not provide your key's password. If everything goes well, it should immediately close the connection. On the other hand, the key password alone should let you in without a hitch. Note that the first connection to a host may fail if you have set up a log-in time limit, because more processing takes place behind the scenes and it may exceed the log-in time limit. In that case, simply try again.
Outside the Firewall
Until now, we have seen how to leverage the power of SSH to remotely log in to a machine over your LAN.
Remote logging wouldn't really be remote if you couldn't reach a computer over the Internet, would it? However, doing so requires punching a hole through your firewall in order to allow incoming SSH connections.
While many firewalls now feature complex inbound rules that will let you limit the number of people who can go through the hole you have punched (depending on their IP address, for example), you may not be able to use them, for various reasons. Some ISPs have an unpredictable addressing scheme and operate in various IP ranges. Also, IP-based controls are never really secure and should therefore not be considered too reliable. They are a deterrent at most, and probably a good one.
Before you read further and enable true remote logging, I strongly urge you to weigh the pros and cons of doing so. Is your LAN secure enough? Should a computer on your LAN be compromised; will the incident be noticed in a short time frame? Would it affect other computers on the LAN? Can you afford to take this risk?
If you're willing to go further, we're now going to see how to remotely log in to your Mac, regardless of where you are located and what IP addressing your Internet service provider uses.
A Brief Introduction to DNS
As an experienced Internet user, you're probably familiar with the concept of IP addresses: strings of numbers that uniquely identify a host. However, you never have to type IP addresses in your web browser's address field, even though you could if you wanted to.
How's this possible? Roughly speaking, this is due to the wonders of DNS, the Internet equivalent of the phone book, which translates domain names into IP addresses so that your computer can contact the appropriate server. When your computer requests a specific URL, a chain of queries begins, from DNS server to DNS server, in order to find the matching IP address.
Most sites have a fixed IP address or a range of addresses. Once and for all, the DNS records are set and, unless something big happens to the servers of this company--they may be moved, for example--they are likely to stay the same indefinitely.
However, the DNS service is extremely flexible, and nothing prevents it from linking a domain name to a new IP address every day, if it were needed. The services handling these frequently changing records are typically called Dynamic DNS or DDNS.
OK, enough of that. Let's get back to work.
Accessing Your Router
Since the Mac you are trying to remotely log in to is located behind a router/firewall, we first need to know how we are going to reach it. We'll worry about how to get through it in a moment.
Like any other device connected to the Internet, your router has an IP address assigned to it by your Internet service provider. In some cases, IP addresses are fixed, while in others they are rotated every few hours.
If you're one of the lucky owners of a static IP address, you don't need to worry about finding your router on the Internet. Simply use the same address again and again, knowing that your router is the one who stands behind it.
Unfortunately, most users are not that lucky, and even expensive broadband subscriptions often come with a dynamic IP address that randomly changes every few hours. What's the solution, then? You're right, Dynamic DNS!
Indeed, a good workaround is to set up a domain name and have a special software update the DNS records associated to it every time your IP changes. Therefore, you don't need to worry about addresses anymore. Just type the domain, knowing that it will automatically translate into the address that your router has been assigned at the very moment you type it.
Contrary to what it may seem at first sight, updating the DNS records on a regular basis is not too complex a task. Indeed, many home routers and firewalls now feature a built-in application that will take care of this by itself. As soon as the router detects an IP change, it alerts your DDNS provider. This requires that your DDNS provider be known enough so that the engineers who built the router included a specific function for it in their firmware.
If you don't own such a router, you can install a specific client on your server that will take care of it. You should just make sure that the client you install launches itself automatically at log in and fetches the router's IP address reliably.
Getting a DDNS Account
One of the leaders in DDNS services is a company called DynDNS. You can learn more about its services here. It has earned the trust of many web users over the years with some excellent services and great customer service.
Because the company is widely popular, I'm going to show you how to set up a DDNS account by using its site. Feel free to rely on the company that best suits your needs; make sure, however, that you read all the help pages posted on DynDNS's web site. It will help you avoid many potential surprises.
In order to create an account, simply use the Create Account page, and remember to visit it securely. Make sure that you agree to the terms and conditions and fill in the required information.
If you already have an account at the company you pick, it's a good idea to create a separate one for DDNS services. Indeed, most DDNS software (either clients or the ones built into routers) sends your authentication information in the clear when it updates the DNS records. While this is acceptable for an account that does not hold any critical or banking-related information, you don't want someone to be able to access your domain names, mail settings, and banking numbers by simply sniffing a password.
The account creation procedure is quite straightforward. To activate your account, you may need to follow further instructions that you receive by email.
Once you've created your account, simply log in and click on the Services tab to display the various services offered by DynDNS. In the left column, pick Dynamic DNS and Add Host.
In the form that appears, you will be asked to pick a domain name. Don't hesitate to use the pop-up menu on the right to find a domain name that fits your needs and taste. The custom part should be simple enough for you to remember--though the simpler it is, the greater the chances that it has already been taken. Also, keep in mind that you may need to give this domain name to someone; picking a neutral one will make things easier.
The I.P. address field contains your current IP address, as detected by your browser. You can change it if it's not accurate.
Although extremely useful, the other options are outside the scope of our discussion. You may want to refer to the documentation for more information of what the options do and how they perform their magic. Paid accounts can set up an offline redirection page that will appear when your Mac or router goes offline. While this can be convenient, it is up to you to decide whether you need it--also, keep in mind that entering banking information into the account raises a risk.
Once you've set up the account, you can safely log out. Then, immediately set up your router or software client so that it automatically takes care of keeping the DNS records up-to-date. Make sure that your client does not unknowingly violate DynDNS's abuse policy, which could cause you trouble.
It's also a good idea to monitor the DDNS setup for a few days, making sure that it works as expected.
Going Through Your Firewall
For now, typing this newly creating domain name into a web browser's address field, pinging it through a terminal, or attempting to establish an SSH connection to it will automatically fail.
Why? Because your firewall is blocking any connection attempts that were not requested from the inside of the network--at least, that's what any good, self-respecting firewall should do.
Therefore, it will be necessary to punch a hole through your firewall and specify the computer on the network to which to forward requests sent to a particular port. This method is called, unsurprisingly, port forwarding. Most firewalls and routers now include this option.
In fact, this method is a bit more secure than simply opening a port in your firewall. Indeed, in addition to accepting incoming connections and letting them reach any computer on the network, it reroutes them so that they all hit the same server. That way, the other computers located on the LAN are somehow better protected--although to a certain extent the whole LAN is at risk, since a compromised server can be used in turn to compromise other hosts on the LAN.
Once you have set up your firewall, make sure that remote administration is properly shut down and secured, should your device include this option. Indeed, such firewalls make a tempting target for hackers--own the main networking device of a network, and you own the whole network.
DHCP Is Our Enemy
Most routers or firewalls allocate IP addresses to the various hosts on the network on a dynamic basis, meaning that the same computer won't have the same address every time that the device is turned on or the network is reconfigured.
You should therefore configure your firewall so that it always assigns the same IP address to the same Mac--leaving the other computers on the network with dynamic addressing if you like. Often this is possible by instructing the device to associate a NAT address to an IP one. You could otherwise use static IPs for all the computers on your network, but keep in mind that this requires more precise maintenance and may raise security issues in the long term.
The Big Test
Then, open your terminal, enter ssh firstname.lastname@example.org and see what happens. On some LANs, you will immediately get an Access Denied message because your firewall does not understand what is going on--you are inside the network and attempting to use a WAN domain name. Therefore, it's a good idea to test this setup while using another, independent connection to the Internet. It will also make for a much better simulation of real-world conditions, when you will be miles away from the server.
If everything goes well, both of your Macs should behave exactly as if they were both on the LAN.
You've made it three-quarters of the way through this series! Next week we wrap up with a little Terminal application work (so you can tap all of the power available to you), a look at updating your Mac remotely, and a few other goodies too. See you then.
FJ de Kermadec is an author, stylist and entrepreneur in Paris, France.
Return to the Mac DevCenter
- Trackback from http://www.icedtrip.net/archives/2004/07/tired_but_ssh.html
tired but ssh
2005-07-08 15:37:25 [View]
2005-05-12 15:08:29 email@example.com [View]
2004-08-02 10:30:31 kao [View]
Does Finder do ssh correctly?
2004-08-02 12:44:57 FJ de Kermadec | [View]
2004-07-22 11:31:44 Sébastien [View]
2004-07-22 12:01:40 FJ de Kermadec | [View]
2004-07-27 10:36:08 machinemen [View]
Inside SSH, Part 3
2004-07-21 20:54:53 [View]
2004-07-21 18:02:55 spalmer [View]
Inside SSH, Part 3
2004-07-21 16:19:03 [View]
Inside SSH, Part 3
2004-07-21 09:51:29 [View]
Sicherheit und SSH unter Mac OS X
2004-07-20 22:51:10 [View]
2004-07-20 19:09:59 jonbreitenbucher [View]
2004-07-20 19:27:50 FJ de Kermadec | [View]