Tag Archives: OSX

Permanently adding SSH private key to OSX keychain

It’s been bugging me for quite a while, but never enough to go and find a solution – until now.

Shamelessly re-posting a perfect guidance from https://apple.stackexchange.com/questions/48502/how-can-i-permanently-add-my-ssh-private-key-to-keychain-so-it-is-automatically:

On OSX, the native ssh-add client has a special argument to save the private key’s passphrase in the OSX keychain, which means that your normal login will unlock it for use with ssh. On OSX Sierra and later, you also need to configure SSH to always use the keychain (see Step 2 below).

Alternatively you can use a key without a passphrase, but if you prefer the security that’s certainly acceptable with this workflow.

Step 1 – Store the key in the keychain

Just do this once:

ssh-add -K ~/.ssh/[your-private-key]

Enter your key passphrase, and you won’t be asked for it again.

(If you’re on a pre-Sierra version of OSX, you’re done, Step 2 is not required.)

Step 2 – Configure SSH to always use the keychain

It seems that OSX Sierra removed the convenient behavior of persisting your keys between logins, and the update to ssh no longer uses the keychain by default. Because of this, you will get prompted to enter the passphrase for a key after you upgrade, and again after each restart.

The solution is fairly simple, and is outlined in this github thread comment. Here’s how you set it up:

  1. Ensure you’ve completed Step 1 above to store the key in the keychain.
  2. If you haven’t already, create an ~/.ssh/config file. In other words, in the .ssh directory in your home dir, make a file called config.
  3. In that .ssh/config file, add the following lines:Host * UseKeychain yes AddKeysToAgent yes IdentityFile ~/.ssh/id_rsa Change ~/.ssh/id_rsa to the actual filename of your private key. If you have other private keys in your ~.ssh directory, also add an IdentityFile line for each of them. For example, I have one additional line that reads IdentityFile ~/.ssh/id_ed25519 for a 2nd private key.The UseKeychain yes is the key part, which tells SSH to look in your OSX keychain for the key passphrase.
  4. That’s it! Next time you load any ssh connection, it will try the private keys you’ve specified, and it will look for their passphrase in the OSX keychain. No passphrase typing required.

Web server in OSX (Apache2, dammit!)

There’s an Apache2 in OSX!!!

Apache2! It’s been awhile since I touched httpd.conf… so many memories… ūüėČ

It’s all described in this tutorial:¬†http://osxdaily.com/2012/09/02/start-apache-web-server-mac-os-x/

It’s dead simple – see/edit¬†/etc/apache2/httpd.conf to find or set DirectoryRoot (mind directory access rights) and run “sudo apachectl start” (stop, restart).

To enable user websites, add following to etc/apache2/users/USERNAME.conf :

<Directory "/Users/USERNAME/Sites/">
Options Indexes Multiviews
AllowOverride AuthConfig Limit
Order allow,deny
Allow from all
</Directory>

and then it’d be served as¬†http://127.0.0.1/~USERNAME/

Also, generating self-signed certificates: https://devcenter.heroku.com/articles/ssl-certificate-self

And adding them to OSX keychain: https://tosbourn.com/getting-os-x-to-trust-self-signed-ssl-certificates/

And you’d need to put them into¬†/private/etc/apache2/ssl/ and (potentially) edit¬†/private/etc/apache2/extra/httpd-ssl.conf and enable (uncomment)

Include /private/etc/apache2/extra/httpd-ssl.conf

and

LoadModule ssl_module libexec/apache2/mod_ssl.so

in /etc/apache2/httpd.conf

and run “apachectl restart” as root.

Champagne for all!

  _
 {_}
 |(|
 |=|
/   \
|.--|
||  |
||  |    .    ' .
|'--|  '     \~~~/
'-=-' \~~~/   \_/
       \_/     Y
        Y     _|_
       _|_

Disable OSX Mail app from popping up on calendar events

As (I believe) many OSX fellas, I connect my Google calendar with OSX calendar to receive all the notification in pop-up form – and just to have all the event a tap away. However when event reminder fires, OSX Mail app starts jumping in anxiety, yelling “Oh! Oh! You forgot to add your email! Do it, do it now!” – and that’s annoying because, well, I don’t use that app and I have no intention to.

The solution is simple (for a downside, read on):

sudo chmod 000 /Applications/Mail.app/Contents/MacOS/Mail

that’d just disable Mail app from being able to launch. It’s dirty, yes – but it’s that famous “good enough” kung-fu. If you need to get Mail app back to launchable state, well, just undo the spell with 755 permissions.

Now on that downside: you have to do this with each system update, because either app access rules or file itself get restored on update – that’s how I got to writing this, because I faced the problem again after an update. How to cope with it? Well, just do it again – updates are seldom enough. That’s how I’m gonna deal with it anyway.