Set up SSH Agent on Login

mpf writes "This is a simple procedure to allow you to be prompted at login for your SSH passphrase and have it optionally stored in your Mac OS X Keychain, so you'll never have to enter your passphrase again! It allows you to use ssh from AppleScripts and other non-interactive applications without entering your passphase." Nice idea. It combines two pieces of software, one that starts ssh-agent on login, and one that gets called to provide your ssh passphrase when needed (which can store/retrieve it in the Keychain). There's a small AppleScript to call ssh-add on login, to tie it all together.

Comments

secure shell?

[BigBir3d]

what is so secure about no password? this must be an idea of the US government...

Re:secure shell?

[Webmonger]

SSH can use several forms of authentication, including public key cryptography. You use a password to encrypt your private key, which you supply on login.

Once your private key is decrypted, SSH can use it to authenticate you on any site that uses your public key for authentication.

There is security at every step. You typically have to be logged in as yourself (or root) to read your private key, you have to supply a password to decrypt the key, and you can remove they key from memory at any time.

Re:secure shell?

[BigBir3d]

so what you are saying is when your laptop is stolen, you are completely covered? i think not.

Re:secure shell?

[Anonymous Coward]

so what you are saying is when your laptop is stolen, you are completely covered? i think not.

Erm, yes, dickhead. The public key is what's used to log into hosts. The public key is encrypted using a passphrase. The only way for somebody to be able to log into a host as you would be if they snatched it out of your hands when you were already in the system, and have authenticated yourself to ssh-agent.

Re:secure shell?

[Lazaru5]

He meant private key of course. The public key is readable by world and installed on the server side. It's the private key that's encrypted with your passphrase.

In response to BigBir3d:

He didn't say that at all.

In response to AC:

BigBir3d's point was that once someone gets ahold of your private - albeit encrypted - ssh key, they can bruteforce your passphrase. PKI is only as secure as your keys (length/phrase/security[ie, Do You Know Where Your Private Keys Are?])

Re:secure shell?

[scenic]

no, not completely covered. But, with proper management you can manage your risk. Just remove the key that got stolen from your remote hosts. The issue then becomes home many keys and where they are, and ancilliary issues like did you use the same passphrase on other keys on other computers (bad user, bad, bad).

At the end of the day, it's all about managing risk. So, you have to take the proper safeguards in order to balance your convenience.

Sujal

Re:secure shell?

[Webmonger]

Yes, you very well covered if your laptop gets stolen, as long as the power's off. The only copy of your private key is on the hard disk, and your passphrase is required to use it, because it's encrypted.

If your laptop is stolen while powered on with an active login session, you may be screwed.

Essentially it goes:

Remote machine: At the request of user bar, I will permit any machine that can prove it has private key foo to log in as user bar.

Local machine: If user bar (or baz) supplies the password for key foo, I can decrypt it. If I can decrypt key foo, I will use it to log into the remote machine.

So in fact, the remote machine doesn't trust your local machine, it trusts the key.

The only decrypted copy of the key is in memory. If you're really unlucky, it got swapped to disk, and was recovered by the person who stole your laptop. Recovering a key like this is nontrivial to do, but not impossible.

Re:secure shell?

[Webmonger]

Of course, some OSes support encrypted swap. . .

Security?

[Daniel Wood]

If an applescript calls the password, couldn't and applescript write the password to a file. If so, this brings up a physical security issue.

Re:Security?

[dragonfrog]

It could, if it weren't for the fact that that applescript reads like this:

do shell script "/usr/bin/ssh-add"

A worring idea.

[@madeus]

Hmm mostly *but not entirely* , a bad idea, IMO.

This is useful as long as you remeber to lock your screen when you are away from your keyboard.

But to be honest, I wouldn't count on that. (as even doing that is not sufficent)

If you store your passwords on your machine and permit programs to access your keychain (which stores them encrypted but *outputs* them as plain text), a malacious program could steal all your account passwords without you knowing (which is of course much worse than just stealing the password to your desktop).

If you make sure the Keychain prompted you before allowing applications to access the Keychain, then that would be all well and good, but then that would elimiate most of the useful functionality of this method (as it would be more annoying than simply having to type in a password in the first place, as it would involve a hand leaving the keyboard and going for the mouse/trackball to point and click).

Even making Terminal.app the only application which can access passwords on the Keychain without prompting does not work around this problem as it's trivial to call the Terminal and get it to do stuff (and, infact some installers do).

In my experience, I have enough problems convincing lusers not to save their passwords in clear text in CRT/SecureCRT login scripts.

I don't wish to detract from someone's work, but this seems like someone's excuse not to have to remeber passwords.

(If there are a lot of systems to look after and you can't possibly remeber the passwords for all of them (and your not able to use something like NIS/LDAP), a plain text/CSV and something like Cypher is probably a better bet.)

Re:A worring idea.

[Lazaru5]

All your points are mostly valid except for saying it's an excuse not to have to remember passwords. Why then do ssh-agent/ssh-add exist at all? Having all apps be able to access SSH_AUTH_SOCK and SSH_AGENT_PID is a good thing. It's ok to question this implementation, but the goal is a good one.

Re:A worring idea.

[daeley]

This is useful as long as you remeber to lock your screen when you are away from your keyboard.

In Mac OS X, under the Screen Saver System Preference, you can have it ask for a password before it lets you back in. You can also set a hot corner so that if you *do* remember, you can just shove your cursor into one corner and the screensaver turns on.

Re:A worring idea.

[usr122122121]

If you store your passwords on your machine and permit programs to access your keychain (which stores them encrypted but *outputs* them as plain text), a malacious program could steal all your account passwords without you knowing.

Your assumption that any program can access any keychain item at any time is false. Each keychain item has specific programs assigned to it with different realms. Take a look at your keychain program, and you'll see a section that restricts program access.
The real security risk that you should be worried about is the fact that if your keychain is unlocked, anyone can go into your keychain application and view in plaintext any of your passwords.

If you make sure the Keychain prompted you before allowing applications to access the Keychain, then that would be all well and good, but then that would elimiate most of the useful functionality of this method

There is an option that you're overlooking: in the keychain manager you can set programs to only prompt you once. Anytime the program itself is modified (if you make a new build, or if you install an update), you are presented with a dialog asking you if you want to allow the program to have access to the keychain item. you can say "deny", "allow", and "always allow"

I don't wish to detract from someone's work, but this seems like someone's excuse not to have to remeber passwords.

I believe that was the entire point!

I don't recommend doing this trick if you're going to leave your keychain unlocked all the time, but if you have it set up more securely it could prove to be a very helpful addition to your setup.

Re:A worring idea.

[macwhiz]

The real use of ssh-agent is more obvious when you consider that ssh was originally developed as a replacement for the hideously insecure "rsh."

The reason why one would want to use "rsh," back in the day, rather than telnet, would be if you wanted to write a script that would perform an action on a remote machine. This isn't something that your average end-user does often, but it's something that systems administrators in business environments find very useful.

Problem is, with SSH, you have to provide a password or pass phrase in order to complete the connection. If your goal is to write an automated system to do the work unattended, this is an issue! "rsh" didn't have the problem, because its idea of security was pretty much blind trust.

So, we have ssh-agent. It's a way that you can enter your passphrase once when you're at the computer, and have that authorization stick around while you go away.

An example: At my last job, at an ISP, our DNS was managed through a CVS repository. With thousands of zones, updating the entire repository was not always speedy. So, I set up a cron job to do the update overnight. Since our CVS only allowed ssh connections, I had to find some way to handle the authentication. Running ssh-agent solved this issue: Once I had given the authorization, it would stick around. Of course, if the workstation weren't located in a physically secured space, and equipped with a password locking screen saver set to a short timeout, I'm not sure I'd have taken the security risk.

Re:A worring idea.

[@madeus]

No my assumptions are NOT false.

I know exactly how the Keychain works, but as I went to great pains to point out, this program fails to save time effectively if you are still prompted for authorization each time and if you are not, then it is insecure, and that's why IMO it's a bad idea.

For some reason (because it didn't fit your argument) you selectively ommited that part of my post from your reply and chose instead to ignore it.

And yes, I also know how to lock the screen in Mac OS X (WOW you can lock the screen? Who would have thought! You must be a rocket scientist!)

As for your reply of "I believe that was the entire point!" when I stated "this seems like someone's excuse not to have to remeber passwords." you would seem to have little experience managing systems responsibly.

Quite frankly, if you can't even remeber your password for a host, you shouldn't not be messing around at the command line at all and are likely to break something quite badly.

Re:A worring idea.

[usr122122121]

Quite frankly, if you can't even remeber your password for a host, you shouldn't not be messing around at the command line at all and are likely to break something quite badly.

I agree.
The whole point of this article in the first place was to provide a way for lazy (or really crunched for time) people to bypass authentication for SSH.
I do not suggest using this method for many of the reasons that you said, as well as many that I said.

I know exactly how the Keychain works, but as I went to great pains to point out, this program fails to save time effectively if you are still prompted for authorization each time and if you are not, then it is insecure, and that's why IMO it's a bad idea. For some reason (because it didn't fit your argument) you selectively ommited that part of my post from your reply and chose instead to ignore it.

Cool it. I think that rather than attacking me, you should be thinking about what the keychain was originally intended for: Maintaining secure information in such a way that requiring one password could provide access to tons of info. In X, at login your keychain is unlocked.
If you're going to talk about security, remind people that you can have your keychain automatically lock after periods of time.

Sorry this seems to have hit a vein, but I'm really not disagreeing with you about the insecurity of the "SSH Agent on Login" post. I am just making it very clear that the Keychain is the weakest link here, not the programs that someone posted.

Take Care

Re:A worring idea.

[Lazaru5]

It wasn't a real question. I was hoping that my response would make the parent realize that the feature that ssh-agent provides is one that is needed.

Pattern of making OSX like OS 9

[Takeel]

Finding ways to make OS X more OS 9-like seems to be a pattern among users of OS X (especially among those graduating from OS 9).

Those using OS X who want to implement things such the password-free login method mentioned in this article may want to think twice. Defeating the need to enter a username and password removes a layer of security from an OS that is still ironing out the kinds of problems that we find in the youth of virtually every OS.

Re:Pattern of making OSX like OS 9

[jkujawa]

I don't think this is so much a password-free login as single sign-on. The keychain database is unlocked when the user logs in, and from then on, any applications which have been allowed to use it can get their registered passwords from the database, without having to ask the user.

Some people like single sign-on, others don't. Personally, I like its convenience. I think it should be done correctly, the database should, for instance, be relocked when the screen is locked, but it's a good solution for users, if used carefully.

Re:Pattern of making OSX like OS 9

[pudge]

Um ... actually, this is making it more Unix-like (as if Unix can be made more Unix-like) ... on Mac OS 9 I have no way to set up an ssh-agent (although NiftyTelnet does cache your ssh passphrase in memory, and MacSSH can cache it in the Keychain). On Linux, when I log in to my graphical UI, I set up one ssh-agent for all my terminals etc. to use. It's the same thing. ssh is made for this. All this does is make it so the ssh-agent is started automatically and your key is added to it automatically, by using the Keychain. Sure, the Keychain or SSH could have security flaws in them, but is that's the case, there are far bigger problems than merely this.

Re:Pattern of making OSX like OS 9

[phyxeld]

I think you are confused. The article wasn't about bypassing login to the mac itself (that can easily be done in the Login system pref panel, on any osx mac), but rather bypassing passwords for remote systems. There is no way (that I know of at least) to get ssh keys working this elgantly in OS9.

I'm in and out of a couple different shell servers all day, so this is a huge timesaver for me. And it is pretty secure, because every time I close the lid of my ibook the system sleeps, and everytime the system sleeps, my keychain is locked. And I've got a password on my screensaver too. And I don't have my actual remote passwords stored. It's beautiful.

Re:Pattern of making OSX like OS 9

[phyxeld]

OK, gotta revise that now that I've used the thing a bit. Locking the keychain doesn't stop me from being able to login to remote hosts password-free (!) but it does stop me from being able to view the stored passphrase in Keychain Access (without entering the keychain passowrd). This still sort of bugs me; I guess I'll just have to get religious about enabling the screensaver (by moving the mouse to a specified corner of the screen) whenever I'm away.

Hey... anyone know how secure the applescreensaver password lock is?

Re:Pattern of making OSX like OS 9

[phyxeld]

One more note:

To lock everything up, one can type "ssh-add -D" and disable the indentites that have been stored (until next login..). To re-enable it, you can use ssh-add again, but it prompts you for your passphrase in the shell (not in the pretty, aqua, keychain-aware SSHAskPass program) which sort of defeats the purpose. There's got to be a better way...

Keychain

[auferstehung]

The original sh compatible keychain tool for Linux (and Unix in general) mentioned in the referenced link can be found on the Gentoo Linux website here. There are links to IBM developerWorks articles describing the concepts behind the keychain scripts as well as how to set it up and use it.

Re:Keychain

[Lazaru5]

You Karma Whore. :) This would be useful if the link wasn't already available from the referenced link. :)

Is doing this like...

[yack0]

using keygen to generate a identity and identity.pub in your local .ssh directory, then copying that identity.pub to the remote server in a ~/.ssh/authorized_keys (perm 644) file?

While that method also assumes physical security, I don't really worry about that. My iBook secures the screen if I'm idle for more than 5 minutes and I have a sleep corner. I don't leave my desk without using the sleep corner to lock up.

I know a lot of people that use this, the trick is to keep the identity file secure. That's your private key and needs to be safe.

Re:Is doing this like...

[Lazaru5]

That's not what this is at all. You of course _do_ generate your keys like normal and distribute your .pub key to your server(s) of choice.

This is akin to starting X via "ssh-agent startx" (or your ~/.X* scripts if you use [x|g|k|w]dm, etc) so that all applications inherit the SSH_AUTH_SOCK and SSH_AGENT_PID environment variables.

This also provides an analog to the X based openssh-askpass dialog.

Finally, and this is the novel part...it adds it to MacOSX's KeyChain system so that all apps - not just Terminal.app and [x|a|e]term - can use it. Their example is Project Builder which can be set to use SSH to do CVS logins instead of the default (which is presumably pserver).

Re:Is doing this like...

[yack0]

Ahhhh.... ok.

I'll have to go back to the ssh book and read up on ssh agents then.

Thanks for the info. Sounds 'more nifty'. :)

My solution..

[lcracker]

I wrote a perl script that manages ssh-agent processes that gets executed in the .login. Basically the way it works is that whenever I start a terminal session it sets the proper environment variables if ssh-agent is running, otherwise, it starts ssh-agent (therefore asking for password). I also wrote some scripts to add my public key to remote hosts. I use SSHPassKey for ProjectBuilder, which seems to integrate with my system pretty well.

---

#!/usr/bin/perl
sub findpid {
$addkeys = shift;
open FILE,"$ENV{HOME}/.ssh/.ssh-agent.csh";
$sock = ;
$pid = ;
close FILE;
$sock =~ s/^.*?\ .*?\ (.*?);\n$/$1/;
$pid =~ s/^.*?\ .*?\ (.*?);\n$/$1/;
$lines = 0;
if ($pid) {
open PS,"/bin/ps -p $pid|";
;
while () { ++$lines; }
close PS;
}
if ($lines) {
$ENV{'SSH_AUTH_SOCK'} = $sock;
$ENV{'SSH_AGENT_PID'} = $pid;
if ($addkeys) {`ssh-add $ENV{HOME}/.ssh/identity $ENV{HOME}/.ssh/id_dsa`;}
} else {
print "Starting ssh-agent...\n";
`ssh-agent > $ENV{HOME}/.ssh/.ssh-agent.csh`;
findpid(1);
}
}
findpid();

Why not just use Public Keys?

[Anonymous Coward]

All of my UNIX machines have my public key, I use my key set to log in, no pasword needed.

This software seems to be a lot more of a hassle to save you a few keystrokes.

Tim

Re:Why not just use Public Keys?

[mpf]

This is using Public keys. It is just providing the glue to allow MacOS X applications to take advantage of them.

SSH Agent, near you

[Anonymous Coward]

I just stumbled upon a truly great Cocoa app, SSH Agent.

It provides a global ssh-agent environment, manages keys on the agent, auto-adds them if so requested, generates keypairs, and so on. And it's stunningly well executed. A must-have!