Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Remote connections without passwords Network
This may not be the most advanced tip in the world, but then again, it may not be obvious to everyone who uses OS X. I know it wasn't obvious to me, and an email exchange with Michael G. today convinced me that I was not alone in my confusion. Hence, this hint...please skip ahead if you're an advanced UNIX user; this is probably a "no brainer" to most of you in that demographic.

Everyone probably knows that OS X includes SSH, a secure remote connection command-line tool. If you have more than one Mac and want to securely connect from one to the other at the command line, SSH is the program of choice. You enable this in the GUI (in the Sharing prefs panel, Application tab, Allow Remote Login), and then connect at the command line with "ssh -l username hostname".

There are a number of authentication schemes to make sure you're who you say you are, and if you implement SSH correctly on both machines, you can connect from one OS X box to another without entering a password, but still have a totally secure connection.

If you don't yet know how to do this, and would like to learn (along with a bit of a primer on SSH's security system), read the rest of the article.

When you initiate an SSH connection, there's a bunch of stuff that goes on behind the scenes to make the connection. You can see this activity by using ssh -v -l username hostname, which invokes verbose mode. If you watch the verbose mode go by, you'll see that the last thing it resorts to is checking your password. We'll set it up so that it never reaches that stage.

The first degree of complexity in making this work is that there are two levels of SSH protocols -- SSH1 and SSH2. Both methods can connect via a number of authorization schemes. SSH1 can use a 'hosts.equiv' file, 'hosts.equiv' with RSA host authentication, RSA public-key cryptography, and (finally) simple password checking, although the passwords are encrypted in transmission. SSH2 can use public-key cryptography or password checking (the hosts.equiv methods apparently are security holes, so their use is strongly discouraged). Although SSH is set up to work out of the box on OS X, you still need to do some things to take full advantage of its power.

In order to connect without a password, using either SSH1 or SSH2, you need to establish a match between the public key of the "connecting" machine (stored on the "connect to" machine) and the "connecting" machine's private key. If the keys match, then SSH knows that the machine can be trusted, and there is no requirement for a password. What complicates matters somewhat is that SSH1 and SSH2 use different public keys, so you have to set them up twice. The following example assumes you wish to connect from your personal Mac (called HomeMac for this example) to your work Mac (called WorkMac), and that you'd like to enable both SSH1 and SSH2. Here's what you need to do.

Step One - Generate your public keys
The first step in the process is to create the public keys on HomeMac. Open a Terminal and type ssh-keygen. You'll see three prompts; you can hit return for the default save location, and leave the passphrase empty (we'll cover that a bit later). When it's done, you'll see some output like:
Your identification has been saved in /Users/username/.ssh/identity.
Your public key has been saved in /Users/username/.ssh/identity.pub.
The key fingerprint is:
5d:01:3f:4g:47:d9:a3:12:9c:f1:37:8a:1j:82:73:7e username@localhost
What you've just done is create your public SSH1 key. The passphrase can be used to add a layer of security to the process. If you enter one, you will be prompted for it each time you run an SSH connection. This sort of defeats the purpose of this hint, which is password-free remote connectivity! If only you have access to your machine, it's not a huge security exposure, but just remember that anyone will be able to connect to any of your remote hosts if they have access to your keyboard.

To generate the SSH2 key, the process is basically the same. Type ssh-keygen -t rsa to generate an RSA public key. Again, accept the default location for the save, and leave the passphrase empty. This time, the output will look something like:
Your identification has been saved in /Users/username/.ssh/id_rsa.
Your public key has been saved in /Users/username/.ssh/id_rsa.pub.
The key fingerprint is:
65:3c:9e:15:87:a6:14:4a:55:bf:e4:3e:ea:2c:22:ed username@localhost
You now have two public keys which you need for step two.

Step Two - Set up the remote machine
This is the "chicken and the egg" portion of the problem. You need to connect to the remote host at some point, so hopefully you already are using SSH with a password. If not, enable SSH now (as explained earlier) and make sure you can connect with a password. Since we're assuming WorkMac also runs OS X, we'll need an SSH2 key (as that's the default in OS X). On HomeMac, type cat ~/.ssh/id_rsa.pub. This will output your public key. Use the mouse to select and copy the whole thing (from 'ssh-rsa' through and including the username bit at the end). Now use SSH to connect to WorkMac. We're going to create a file to hold your public key. Type cd ~/.ssh and then pico authorized_keys2. This will open a text editor on a new file in the .ssh directory. Paste in the text you copied from the 'cat' command, and save the file and quit the editor. Disconnect from WorkMac by typing exit.

Step Three - There is no step three
That should do it. If you now type your "ssh -l username WorkMac" command, it should simply connect. To see what it's doing, add the "-v" option just after the "ssh" bit to use verbose mode. On my machine, I've also set up an alias called "work", which contains the full SSH line. So to connect to the office, I just type "work" and I'm connected.

Other bits...
If the host you're connecting to uses SSH1, then "cat" the file named "identity.pub" (and copy the output) on the HomeMac, then create a file named authorized_keys in the .ssh directory on the remote machine and paste the data. This should allow a password-free connection via SSH1. You can also force a connection via either protocol by using the "-1" or "-2" switch on the ssh command line. It's my understanding that SSH2 is much more secure than SSH1, so it's use is preferred if possible.

And I'll close this hint with another warning/disclaimer: By not using a passphrase, anyone that has access to your keyboard also has access to any hosts you've set up with this nice password-free access. You need to decide if the convenience is worth the risk in your particular environment. Finally, I am not an SSH expert by any measure! What you've read here just about covers the extent of my knowledge on the subject. If I've made any mistakes, hopefully someone with more expertise than I will post corrections or clarifications ... it's also late at night, so I apologize in advance if there are any typos that break this hint -- please post a comment if you have troubles!

For more detail on all things SSH related, try man ssh, man ssh-keygen, and man ssh-agent (a way to only enter passphrases once, apparently, but I've never tried to use it) in the Terminal.
    •    
  • Currently 3.67 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (3 votes cast)
 
[55,722 views]  

Remote connections without passwords | 13 comments | Create New Account
Click here to return to the 'Remote connections without passwords' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Better security
Authored by: Anonymous on Dec 07, '01 04:19:52AM
By not using a passphrase, anyone that has access to your keyboard also has access to any hosts you've set up with this nice password-free access.


Access to your filesystem is enough unfortunately. Security wise this is not a god solution. In my hint "Secure and easy OpenSSH key management" you hava a solution that is secure and almost as easy.



[ Reply to This | # ]
Better security
Authored by: r0adrage on Dec 08, '01 04:20:51AM

ironically, by using keychain you are still susceptible to anyone with access to your file system. any use who would be able to compromise your ssh identity files would also be able to compromise your .ssh-agent file that keychain creates, thus being able to ssh as you using your instance of ssh-agent by simply "source ~you/.ssh-agent" in their shell.

Permissions for ssh keys are, by default, only readable by the owner, so anyone who can read your ssh key would also be able to read your .ssh-agent file.

I'm still looking for a way to get ssh-agent to start up as the parent of my OSX login session.



[ Reply to This | # ]
Re: Better security
Authored by: Anonymous on Dec 08, '01 09:30:05AM

You are right that the security with Keychain/ssh-agent is not fullproof, but I think it's a magnitud better than to use no password at all for your SSH-key.

If you use a key with no password and someone break in to your computer they can take your SSH-key and use it as they like from any computer. Breaking in could be as trivial as walking up to your computer when you are away for a minut and copy the key.

With a good password on the SSH-key you raise the threshold *considerably*. Keychain/ssh-agent make it possible to have a password without having to type the it all the time.



[ Reply to This | # ]
re: Better security
Authored by: lone mac on Mar 01, '02 11:57:41PM
> I'm still looking for a way to get ssh-agent to start up as the parent of my > OSX login session. Actually, Kevin Van Vechten wrote a tool that does exactly what you ask for: SSHAgentServices for Mac OS X I just discovered it recently and have been very pleased with it.

[ Reply to This | # ]
Re: Remote connections...
Authored by: sfn on Dec 07, '01 08:42:19AM

I'd love to try this but I can't seem to get SSH to work on my OS X Server box. Verbose mode shows a successful authentication using a password. I get the "Welcome to Darwin" greeting and then the connection closes immediately.

I can SSH to my local machine successfully. I can access the server via Server Admin and mount the disk using afp.

Any ideas?



[ Reply to This | # ]
Re: Remote connections...
Authored by: jamesworourke on Aug 16, '04 01:06:00PM

Hi, I have the same problem but not with a OS X Server install, simply 10.3.4. Did you manage to track down the solution for this?



[ Reply to This | # ]
Re: Remote connections...
Authored by: overrider on Oct 16, '04 05:47:16AM

i had a similar problem, my connection used to close immediately. i then remove the authorized_keys2 file on the to be connteced to server, and transfered it via scp like this

scp id_rsa.pub admin@apex:~/.ssh/authorized_keys2

then it worked



[ Reply to This | # ]
Can this work going to a UNIX server?
Authored by: jprickitt on Apr 07, '03 08:11:20AM

I work on a Mac but my website is hosted on a unix system. Can I use
authorized_keys with the unix server?



[ Reply to This | # ]
Can this work going to a UNIX server?
Authored by: ctierney on Jan 24, '07 11:19:54AM

As long as you have shell access, you should be able to. It's how I administer our company's offsite linux server. Just create the hidden .ssh folder in your home directory and follow the same steps.

(TIP: If you ssh into multiple machines you might consider using a differently colored terminal window for each. The visual indicator will help you remember where you are. ;-)



[ Reply to This | # ]
ssh-keygen
Authored by: jprickitt on Apr 07, '03 08:17:29AM
On the first step, running ssh-keygen the first time, I got a reply: You must specify a key type (-t). So it didn't generate an SSH1 key, I think. What arguments should I use?

[ Reply to This | # ]
ssh-keygen
Authored by: englabenny on Apr 21, '03 05:27:47PM

To generate a ssh1 key, you have to specify -t rsa1. but i have it not working.



[ Reply to This | # ]
Remote connections without passwords
Authored by: cheesesnake on Jan 24, '07 10:28:16AM

Yes, that scp tip worked for me as well. FANTASTIC



[ Reply to This | # ]
disable password logins
Authored by: ctierney on Jan 24, '07 11:08:56AM
Hello,

After you've confirmed that you can login without a password, you may want to consider disabling password authentication. Sounds counter intuitive, but this will require the use of public/private key pairs. This'll discourage brute force login attemps which has become common. The setting is in /etc/ssh_config and is called PasswordAuthentication. Uncomment that line and change yes to no. Then restart the ssh deamon. Use either kill -s HUP or just turn off remote login in the sharing preferences then turn it back on.

If you're really paranoid, you can also make sshd listen on a non standard port.

--
Cole



[ Reply to This | # ]