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 username@yourdomainname.ext 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.
Next Time
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
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 17 of 17.
-
Tiger's Broke?
2005-05-12 15:08:29 rbannon@mac.com [Reply | View]
-
Tiger's Broke?
2005-05-12 15:31:05 FJ de Kermadec |
[Reply | View]
Hi!
First of all, thank you very much for taking the time to contact me and for your kind words, I really do appreciate them! :^)
What do you mean by your machines being under attack? Did someone try to exploit any SSH weakness or was it more of a brute-force password attack? In any case, you might want to ensure that no issue you are encountering is due to a potentially successful intrusion.
This being said, the "Permission denied" message you see is usually the result of a key mismatch or of a configuration error. Basically, SSH tells you that it tried every method to authenticate and that all of them failed in a row, leaving it unable to ascertain who you really are. A good way to see what really is at play is to run SSH in a verbose fashion by adding a "-vvv" flag to the command and reading the error messages that appear. That will allow you to see which of the 3 authentication methods should work and why it is failing.
Let me know if this helps!
FJ
-
Does Finder do ssh correctly?
2004-08-02 10:30:31 kao [Reply | View]
Does Finder do ssh correctly? Or have I missed something? Following François' article I have ssh working fine from the shell but when I try to connect to the server from a Finder network browse I get a message that the server does not support secure connections through ssh. -K -
Does Finder do ssh correctly?
2004-08-02 12:44:57 FJ de Kermadec |
[Reply | View]
Hi !
SSH, as a command-line tool, requires that you use the Terminal in order to connect to a remote server. In order to transfer data through SSH by using a GUI, you may want to look at third-party applications like Fugu (http://rsug.itd.umich.edu/).
The message you see is likely to appear when you use the "Connect to server" menu, available through the Finder. However, by using it, you are establishing an AFP connection : the Finder is merely informing you that the computer to which you are connecting does not support SSH tunneling for the AFP connection. Unless you are establishing a connection to a specially configured AFP server, this is expected behavior and does not indicate an issue.
Let me know if this helps!
F.J. -
Does Finder do ssh correctly?
2004-08-02 13:44:41 kao [Reply | View]
François - thanks for the prompt reply! Yep, I leaped to the conclusion that because the Finder supports ssh (under Options on the Connect to Server window is a preference that says "Allow secure connections using SSH") the native AFP server would. Thanks for clearing that up. Regards, -K -
Does Finder do ssh correctly?
2004-08-02 13:51:31 FJ de Kermadec |
[Reply | View]
Hi again !
You're very welcome! :-)
F.J.
-
SSH Jail?
2004-07-22 11:31:44 Sébastien [Reply | View]
Great article!
It would have been nice to detail though how to get SSH configured into a root jail, in case you want to give somebody else access to your mac remotely to drop some files securely let's say. The jail setup would ensure they can only see the content of their home directory and not your whole system!
Maybe for next article? ;) -
SSH Jail?
2004-07-22 12:01:40 FJ de Kermadec |
[Reply | View]
Hi !
Thank you very much for your kind words, I really do appreciate it!
The fourth part of this series is, as you can imagine, already completed. However, I always welcome your suggestions and will be sure to look into the issue should I publish about SSH again in the future :-)
Meanwhile, you can have a look into the O'Reilly book I suggested, "SSH the secure shell".
Thanks again!
F.J. -
SSH Jail?
2004-07-27 10:36:08 machinemen [Reply | View]
I would second this question - we would love to be able to allow users to SSH into the server and permit
1) a limited set of commands (gzip, tar, etc)
2) no access to any other user's documents
Is this something that can be covered in an email, if not in the article? Are there any definitive resources for this on the web?
Thanks for any pointers you can provide!
Bill
-
Great Article...
2004-07-21 18:02:55 spalmer [Reply | View]
though I wish you would have written this about a year ago since it would have saved me a ton of research.
I also found some settings that you didn't mention in your article, AllowGroups and DenyGroups, which are similar to AllowUsers and DenyUsers except for groups.
Something you didn't mention for AllowUsers is that you can use wildcards in the host part, and you can use actual IP numbers. I set mine up to similar to the following example:
AllowUsers *@192.168.1.*
AllowGroups admin
These two lines combined will only allow admin users from the 192.168.1 subnet of my example network.
I had one question about public keys as well. If you plan on covering this in the next article I can wait to read it there. If I create my public/private key pair with a password on the private key and get these keys distributed to the correct locations can I then change the password on my private key after everything is correctly set up or will I have to create a new key pair with a new password?
Thanks -
Great Article...
2004-07-22 08:57:23 FJ de Kermadec |
[Reply | View]
Hi !
First of all, thank you very much for your kind words, I really do appreciate them ! :-)
Also, thanks for sharing these tips of us : they will be of great help!
You can change the password on the private key without having to delete the keys and therefore re-create a key pair. The ssh-keygen command can take care of this for you.
Let me know if this helps !
F.J.
-
gssapi error
2004-07-20 19:09:59 jonbreitenbucher [Reply | View]
I have changed the configuration files as indicated and now I get
Permission denied (gssapi).
when I try and login. I haven't tried restarting the server from System Preferences. Instead I tried sending
killall -HUP sshd
while I was logged into the remote server. The server closed the connection and seemed to do what I expected, and then this message. Any thoughts? Obviously I'll try restarting the server when I get in tomorrow, but I'm just curious as to what could have happened. -
gssapi error
2004-07-20 19:27:50 FJ de Kermadec |
[Reply | View]
Hi !
First of all, thank you very much for taking the time to post, I really do appreciate it ! :-)
Usually, this message means that the SSH server went through all the authentication methods allowed by the configuration files and could not find a match with what the client suggests.
In order to see more about the process you can add the "-v" switch to the ssh command : this will show you at which point the connection attempt fails.
Usually, going through the configuration files again and making sure that what should be left on is on solves the issue.
Let me know if this helps !
F.J. -
gssapi error
2004-07-21 08:29:49 jonbreitenbucher [Reply | View]
Is there a typo in the sshd_config or in the article? sshd_config has
#PubkeyAuthentication yes
instead of
#PubKeyAuthentication yes.
I haven't gotten a chance to access the server yet to test.
J.B. -
gssapi error
2004-07-21 08:42:12 FJ de Kermadec |
[Reply | View]
Hi !
Keywords in the sshd_config file are normally case-insensitive.
F.J. -
gssapi error
2004-07-21 08:17:23 jonbreitenbucher [Reply | View]
F.J.,
This has been a great series and you have done a fantastic job. I'm sure I've messed up the sshd_config somehow. Can't wait for the last installment.
J.B. -
gssapi error
2004-07-21 08:40:35 FJ de Kermadec |
[Reply | View]
Hi !
Thank you very much for your kind words, I really do appreciate them !
I can very well make mistakes too so it's always good to take the time to see where an issue lies :-)
F.J.






< strong >Permission denied (gssapi-with-mic,publickey,gssapi).
Do you have any suggestions?
Sincerely, Ron Bannon