Mac OS X 10.11 El CapitanのPublic Betaも出てしばらくするのにこういう話で恐縮するわけですが，数日前に半日無駄につぶしたのが残念なので，同じ轍を踏む人がいないよう記しておくことにします。
まずみんなが困っていることが，Mac OS X Yosemite 10.10.4のOpenSSHは6.2p2であり，楕円曲線暗号を用いるECDSA対応がありそう（stringsするとecdsaの語は出てくる）けれど，鍵交換アルゴリズムにECDSA対応が入っていないためHost KeyにECDSAを使ったサイトに接続できないというところでありまして，結局使えない，ということであります。El Capitanは試していないので現状どうなっているのかわかりませんが，Beta 3のユーザがHomebrewしているところをみると，状況はかわっていないのかなと思われるところです（ここの末尾）。
ちなみに，Mac OS Xのsshのありがたいのは，launchdがログイン時に起動するssh-agentがパスフレーズをOSの「キーチェーンアクセス」により自動送信してくれることでありまして，通常ssh-addで明示的にパスフレーズを教えこむような手間を，ログインごとではなく，暗号鍵を作成し，最初に使うとき一回だけで終わらせてくれることにあります。とはいえ，そのコードは本家OpenSSHに反映される様子がなく，MacPortsでメンテナンスされているパッチを使って最新（に近い）OpenSSHを使うということになっておりました。
というわけで，MacPortsを使っている限りは，インストール時に+gsskexを指定することによって，Kerberos 5認証とセットでキーチェーンアクセス対応になるので，ssh-agentが/opt/local/bin以下にあるものを起動するよう，/System/Library/LaunchAgents/org.openbsd.ssh-agent.plist を書き換えて，そのあとログインしなおせばよい，ということでありました。
で，数日前に出た7.0p1に対してMacPortsでは，現状Kerberosはだめということで，キーチェーンアクセス対応パッチも通らない状況であるようです。いずれ誰かが調整してくれるのを待つしかない。
一方，Homebrewは哲学として，OSにあるものを極力使うという方針があり，OpenSSHもhomebrew-dupsをtapしてやらないと入らないようになっておりました。つまり，手順としては（7.0p1対応の現在）
- brew tap homebrew/dupes
- brew install openssh
以上，ということでして，いっとき存在した「OpenSSL 1.x系にするための--with-brewed-openssl」とか「キーチェーン対応のための--with-keychain-support」などのオプションはすべて外されており，逆に，「LibreSSLを使う--with-libressl」だけが唯一存在するオプションであります。とはいえ，上の手順でopenssl-1.0.2dも同時に入るので，OSの0.9.8zfを使うわけではないようです。
（ちなみにopensslとlibressl混在問題というのがあるらしく，まだ「混ぜるな危険」のようなので，libresslを入れるのは自己責任ということです）
これは要するに，10.10.4のssh使わないならMac OS Xと同等の動きを期待するなということでありまして，一般的なUNIXの流儀で使いなさいね，という判断であります。
かわりに，Funtoo Linux由来らしい，コマンドラインのkeychainというのがssh-agentの面倒をみるらしく，それ使えというコメントがあったり，解説している人もいますが，あんまり幸せになる感じがしませんでした。普通にssh-addしてるほうが安全な気がします。
ただ，Homebrewでキーチェーンアクセス対応しなくちゃやだ，という人は，6.2用に自作Formulaを公開している人もいるので，それをtapしてください。使いかたは，そこのREADME.mdにかかれている通り。入れ替えが終わったら，再起動して数分ほっとくのがよいようです（再起動後，launchdが出すエラーが/var/log/syslogにしばらく出ているけれど，そのうち落ち着くので）。落ち着くとlaunchdがキーチェーン機能つきのssh-agentを自動で起動してくれるようになります。
ただ，README.mdの末尾に書かれているスクリプトはあちこちで孫引きされてますが，全く意味がないので無視してください。
というのは，$(ssh-agent)と変数を参照してますがどこにも定義がないからexecしてもなにも起きないし，shellを落とすときにkillが走るようにtrapつけてますが，ssh-agentはlaunchdが管理しているので，shellには期待している環境変数SSH_AGENT_PIDがありませんから，killしたくても引数が空なのでなにも起きません。実害はないけれど全く無駄な処理が動く分だけ資源の無駄なんではないかと思います。
これに意味があるのはキーチェーンを使わない，つまり自分でssh-agentを立ち上げて，ssh-addで鍵を覚えてもらうときに意味がある記述です。ただ，いつ書かれたものかわからないけれど，いまならもっと簡単に書けます。bash前提にすると，
exec `ssh-agent -s`
function cleanup {
ssh-agent -k
}
trap cleanup EXIT
が妥当ではないでしょうか。ただこれだとshellの数だけssh-agentが生まれてそれぞれ別のソケットを作るので，ターミナルを複数開くとshellごとにssh-addする形になってうれしくない。それよりは，最初にUNIXソケット決め打ちで-aオプションから指定することにしてそれを共通の環境変数SSH_AGENT_SOCKに持ち，一度起動したら，以後はssh-agentを起動しないほうがいいんではないかと思うところ。複数ユーザがいるなら，ユーザ名をソケット名に入れるのが妥当なんではと思ったり。
GNU screenやtmux使う人で，再接続したときに環境変数失ってssh-agentとお話できないのをごりごりする人がいるようですが，この考え方でスマートに解決できるんではないかとも思いますがどうでしょうか。
