2015年11月15日日曜日

NTTフレッツ光のCTU設定変更(結局フレッツ光ネクストに契約切り替えたので意味なしエントリになりました:2015-12-15)

(追記:2015-12-15)フレッツ光プレミアムは新規契約打ち切り、フレッツ光ネクストというCTUいらない子な契約に切り替えていくようで、自宅もそうしたらとても快適になりました。

それから、以下の記述は10年ほど前に契約した当時の、住友電工のCTUにのみ該当するようで、クレーム後いったん予防交換といって工事屋さんが置いていった日立のCTUでは、デフォルトのパケットフィルタ設定は入っていないようでした。

CTUにつないでいたBuffaloのWi-Fiルータはフレッツ光のPPPoEリンク設定がデフォルトで入っていたようで、ほとんど何も考えずにISPのログイン設定するだけで終わったので、フレッツな人はみんなネクストに契約切り替えたほうがいいと思います。うちは集合住宅で光ケーブルが部屋まできていないので上限100Mbpsのままですけど、いままでがひどすぎたので劇的な改善であります。

工事料金無料、契約は「隼」(最大1Gbps)ではないので料金同じ、2年縛り割引もそのまま引き継ぐということで、特にこちらから申込書を書くこともなく、ただ契約変更通知が郵送されてきただけでした。工事屋さんは管理人室内の終端ボックスの配線付け替えとCTUの引取り、データリンクの確認と伝票の印刷だけしてお帰りになられました。簡単。

ひかり電話とかフレッツ・テレビ(スカパーHDとかがフレッツIPv6網で観られる)を契約するとそういう機能つきのNTTご提供ルータに交換するみたいですが、うちはシンプルにやっております。


自宅はNTT西のフレッツ光を使っていますが、どうも最近つながらない、よく切れるという症状で悩んでおりました。

困るのは、SSH接続がブツブツ切れることでして、これではサーバのメンテナンスもできません。コンパイル途中で切れるとか、インデックス作成中に切れるとかすると、shellが子プロセスもろとも落ちるので、ちっとも作業が進みません。

NTT西に電話して、機器や配線の電気的な点検を依頼するとか、週末なので問い合わせフォームしかなかったけれど某ISPのカスタマサポートに通信制限状況の問い合わせを投げてみるとかしてみましたが、そうしている間、瞬間的にIPアドレス重複のメッセージが現れたのをみつけて、どうもDHCPサーバになっているCTU(NTT用語で要するにPPPoEルータ)が怪しいと思い、設定を見なおしてみました。

まず、自分のMacのIPアドレスが使われるのはたまらないので、MACアドレス指定でスタティックなIPアドレス設定に変更。

そのあと、ログをみるわけですが、「不正アクセスログ」という画面ぐらいしかまともに時系列のログがないので開いてみたところ、「つながらない」と思っていた相手への接続をCTUが切断していました。現員は「SPIによる破棄」。へえ、そんな立派なものがと思いつつ、「なんで捨てるんだよ」という怒りにも似たやるせなさが。

検索すると、CTUのWAN側IPv4アドレスが「123から125の間で始まる場合」、つまり上から8bitが123-125のブロックの場合、一部のIPアドレスに対するパケット送信をSPIが破棄するという問題がある、という古い記事(しばらく前にファームウェアの更新があったけれど、それより古いという意味)がいくつか見つかり、「ファイアーウォールをオフにしてください」と書かれているサイトが複数ありました。

CTUの設定画面上、たしかにオフが誰でもわかる選択項目だけれど、それは乱暴ではないかと思いつつ。
CTUログイン直後の画面左にファイアウォール設定項目がある

とはいえ、「制限なし」は乱暴ではないかと思う。SPIは「詳細設定」のなか

ということで、SYN Flooding対策にはSPIほしい気もするけどどうなんだと思いながらも、現実にいまつながらない相手があり、家人のスマホらしきIPアドレスでも破棄されているので、これは手元のMacだけの問題ではないと思い、SPIを停止して様子をみることにしました。

ただ、SPIを止めるためには、「ファイアウォール詳細設定」という別立ての項目を設定して、とパケットフィルタリングのルールを自分で書く画面と同じところに入らなければならないわけです。
「詳細設定」画面の上にSPIの項目があるけれど、「編集」を押さなければならない仕様

ここでようやく選択できる。OKで前の画面に戻る
こうなると、普通のルータ同様に細かくルールを書かないとフィルタリングなしになるような気がするのですが、結論からいうとそうでもないようです。でも、ルールの書き方の規則がわかったので、以下続けます。

ルールは先頭(若い番号)から順に評価されます。なので、「全部閉じて開くものを指定する」か「全部開いておき、閉じるものを指定する」か、どちらかを最初に決めなければなりません。

それで、後者を選んだ場合、デフォルトは「全部閉じている」になります。よって、先頭に、全てを「許可」するルールを置かなければなりません。ルール番号は1がいいでしょうか。「IPバージョン」に「IPv4・IPv6」を選び、「プロトコル」を「すべてのプロトコル」に変更するのを忘れないでください。初期値は「IPv6」「TCP」です。

そのあと、Windowsのファイル共有関係の137-139と445を書いておけば十分なようです。念のため、以下の図では53/TCPと53/UDP(DNS)を拒否するルールを書いていますが、「不正アクセスログ」をみると、特にルールを書かなくても「NATによる破棄」を理由として、たいていの試みは失敗するような動作をするようです。少なくともWell Knownなポートに関してはSYNの時点で捨ててくれますし、そうでない怪しい443(HTTPS)からの接続とかは、宛先ポートによらずESTABLISHEDのところで捨ててくれます。したがって、ルールがなくてもそれなりにうまく制限してくれるのかもしれない。

しかし、443や53から接続する攻撃があるのに驚きました。ルールの書き間違いを期待しているんでしょうか。あるいは、送信元が80や443だと通してしまう誤ったフィルタが設定された商品があるんでしょうか。
特定のポートを制限するなら、先頭に「全部通過する」ルールを置く必要があるので注意
いずれにせよセッション有効時間が短いので、調べ物に時間をかけていると、せっかく入力したルールを保存できないまま、最初からやりなおしになるので、最小限の設定からはじめるのがいいと思います。

この画面には「戻る」ボタンしかありませんが、変更内容はメモリに保持されています。これを保存するには、「戻る」で現れたトップ画面の画面左にある「設定反映」ボタンを押さなければなりません。すると、いったん確認画面を経由したあと、再起動が必要な選択をしたから再起動してくださいというメッセージとともに、「再起動」ボタンが配置された画面に遷移します。再起動は1分ぐらいだと思います。ときどき適当なサイトにpingでも打ちながら待っていると、そのうち反応があります。いつまでたってもunreachableな場合は、おそらく1番ルールの「最初にすべての通信を許可する」ときに「すべてのプロトコル」を選ぶのを忘れていて、ICMPが通らなくなっています。

あとはお好みで調整してください。再起動の時点で「不正アクセスログ」を開くと、早くも多数の怪しいパケットを捨てたことがみてとれます。

ひとまずこれで様子見です。

2015年11月5日木曜日

Mac OS XのKeychainに対応するOpenSSHパッチがGiHubにありました

以前、Mac OS Xのキーチェーンアクセスに対応したOpenSSHのパッチについてのエントリを書きました。

El Capitanになり、入っていたMacPortsの全リコンパイルをなんとか終えてしばらくしてから、port -uv upgrade outdatedしたら、MacPortsのOpenSSHが7.1p1になりました。

Homebrewのほうはどうだろうと思ったら、メンテナンスされているパッチのリポジトリをGitHubで見つけました。

https://github.com/zoltansx/openssh-keychain

Homebrewの場合は、dups/opensshのkegをeditしろとのことで、追加すべきコードを含め、手順がReadme.mdに書かれております。

気になる方は、上記URLを参照してみてはいかがでしょうか。

当方で試してみたところ、無事7.0p1がコンパイルでき、キーチェーンアクセスに保存されたpassphraseを用いてssh接続できました。ありがたや。

2015年11月1日日曜日

Yosemite以後のMac OSでJavaインストールのダイアログを消すにはJDKを入れる

そのまんまですが、El CapitanでJava6を入れないで、やむなくOracle JREを入れたけれど、いつまでもインストールしろとうるさいので調べたら、こんなFAQがOracleにありました。

After I updated to Mac OS X 10.10 (Yosemite), why am I told to install Java after I already installed the latest Java?

回答は、「full JDKを入れろ」でありました。Java SEですね。見つかりにくいですが、たぶんこのへんからたどるとよいのでは。

たしかに、JREだけだと空のディレクトリがあちこちにあって、なんか変だなと思っておりました。環境変数JAVA_HOMEを設定すればjavaコマンドは動きますが、ダイアログはシステムが出しているわけで、ユーザ側の環境変数は関係ないはずで。

それで、Java SE入れて再起動すると、あたりまえですが特に環境変数JAVA_HOMEを設定しなくてもOracle Java 8が動きました。まあ、しのごの考えないで、さっさと再起動するのがいいような気がします。

一方、検索してみると、El Capitanのrootlessを解除してApple Java 6を入れる手順が説明されていますが、気持ちはわかりますがやめたほうがいいんではないかと思う次第。

AppleのJava 6サポートはEl Capitanが最後なんだそうです。Java 6依存のコードは、Oracle Javaの新しいコード(Java 8とか)で警告なくコンパイルできるよう、リファクタリングしなければいけませんね。いろいろめんどくさいですが。

2015年10月27日火曜日

GoPiGoとは

Raspberry Piでロボットカー制御、というので話題らしい、「GoPiGo」のサイトをみてみました。
GoPiGo Base Kit

とても見覚えのある感じのモータとタイヤ(ちっちゃいものくらぶの通販サイト参照)でありまして、いつのまにか欧州サイト他でも見かけるようになったので、さすがともんさんお目が高いと思うわけですが、それにレーザーカットした木製もしくはアクリル筐体、そしてRaspberry Piに載せるボードなんですが、なんとArduinoでした.

GitHubに回路以外の一式が掲載されているのですが、FirmwareのなかみはArduinoのスケッチです。しかも、GPIO上のシリアルポートで通信しておりまして、おんなじこと考える人はいるもんだなあと思った次第。

セットアップはGertboard使っておりまして、これはアナログはSPIでRaspberry Piに渡すので、そのへんの違いや、モータをドライブできる回路も乗っているので、わたくしが作成した簡易基板よりは豪華。
"Red Board"
GoPiGoは、電力が必要なのは車輪のモータだけのようなので、Gertboardの簡略版と思われる一方、赤外線リモコン対応などの追加もあるようです。でもまあ、がっつりと DIP版のATmega384Pが存在感を放っているあたり、好感がもてますね:)
Base Kitのパーツ一覧
上図はBase Kitですが、車輪にとりつけるロータリエンコーダ相当の溝を切った円盤もあり、対応言語によってはエンコーダの値をみてフィードバック制御可能なようにもなっているようです。PythonだとBluez使ってBluetooth接続したPS3リモコンにも対応している模様。サンプルもたくさんありますが、個人的にはJavaやNode.jsに対応したのがえらいなと思った次第。Pythonの簡単なソケット通信サンプルもあって、ソケットからロボットカーの操作もできるようです。
Starter Kit
Starter Kitだと、超音波距離センサとその首をふるサーボモータがついてくるようです。

あとオプションでRaspberry Pi純正カメラをつけてビデオストリーミングするようなPythonスクリプトがあり、PC側でモニタしたり、Raspberry PiでOpenCVを動かして画像認識するようなデモがあったりと、PythonではI2Cインタフェースを含めていろいろな材料を提供しているようです。

YouTube動画をみる限り、なかなかきびきびと動きますね。開発はVNCとファイル共有を併用し、PC側で編集したプログラムをファイル共有でRaspberry PiのPythonで実行するのをVNCの画面から操作しています。Avahi(mDNS)も動かして、IPアドレスでなく、名前で接続できるようなこともしています。

材料は特別なものはとくにないので、Arduinoやモータドライバを含めてある程度の材料が手元にあれば、GitHubのレポジトリからほぼ同様のものを作っていけるように思いました。

ゼロから工作していく感じが学習向けだと思うのですが、日本語対応という点ではScratchがありますが、Pythonほど情報提供されていないので、Python怖くない中高生や大学生にはおすすめできるけれど、そうでない人にはまだ敷居が高いのかもしれません。

2015年9月21日月曜日

いわゆるXcodeGhostについて

iPad AirをiOS 9にアップデートしようと久しぶりに電源を入れたら,iCloudやiMessageへのログインを繰り返し要求される事態が発生し,うんざりしておりました。公開初日だったのでAppleがとんでもなく混雑しているのは,iOS 9のダウンロード前の認証に10分ぐらいかかった時点で覚悟したわけですが,iCloudやiMessageの認証失敗もその関係かなと思っていたわけです。

日中のダウンロードを諦めて帰宅後,深夜に自宅で割と(それでもゆっくりと)ダウンロードが進むのを見ているうちに寝落ちしたので,目覚めてからは混雑解消したのか,すっきりとインストール以後は進みました。

インストールの間にもAppleの認証ステップがありますから,通信が混雑しているとインストール途中でプログレスバーがいつまでも動かない,ということが生じますが,それはなかった,ということです。

で,現象が解消して忘れていたのですがそこへXcodeGhostのニュース。各ニュースサイトで話題になっているのでご存知かと思いますが,細かいところまでよくまとまっているのが以下の記事かと思います。

それ以前に一般のニュースで,iCloudのパスワードを入れさせられる場合もある的な記述があり,「ゑ?」と思ったわけです。

ということで,Pangu作のチェッカを入れて確認しました。このへんは脱獄ニュースのTools4Hackさんが詳しい。Panguは脱獄ツールを作成,配布しているところですから当然でして,この界隈の修羅の様相を踏まえて,確からしい内容を選んで丁寧に解説されているのがこのサイトであります。
個人的には脱獄環境でMobile Safariの穴からiOS乗っ取られた過去があるので脱獄はめんどくさいと思ってやめましたが,iOSのセキュリティについては脱獄コミュニティがいちばん詳しく知っていて,Twitterなどでかれらが漏らす話が重要だったりするので,それをうまく掬って記事にしてくださるニュースサイトは見ております。

というわけで,上記記事の手順で,Mobile Safariからアプリをインストールして,開発者証明書プロファイルを「設定」アプリから「信頼」してあげれば動きます。エンタープライズ向け,企業などで社内業務用に開発されたものなど,一般公開されないアプリをインストールして動かす手順を踏む形。

開発者証明書はAppleに申請して,Appleの署名つきのものを取得しないとアプリが動かず,証明書の偽造はまだ確認されていない,できないことになっている,のだったと思うので,このアプリを動かす間だけ「信用」すればよいし,この画面で「信用」すると赤文字で「Appを削除」にかわるわけですが,実行後,ここをタップすれば証明書とアプリの両方が消えます。

結論ですが,わたくしのところでは,コメント欄で話題になっているCamScannerは手持ちはCamScanner+だったおかげか,感染しておりませんでした。というわけで問題なし。AppStore側も感染アプリのBAN(ストアからの削除)を積極的に進めているようなので,今後インストールするアプリに同じ不正コードが含まれている可能性は少ないのかなと思っています。(AppStoreからBANされていても,いまデバイスにインストールされているアプリまで消えるわけではないので,いま動いているiOSデバイスで確認することが大事です)

それで,XcodeGhostの該当コード部分がGitHubに上がって,めきめきスターの数が上がっております。スターは,いわゆる「お気に入り」機能です。ブックマークといってもいい。
たしかに,各種情報をとりまとめ,暗号化して情報収集サイトに送信する様子が見えます。README.mdが中国語なので読みにくいですが,英語に翻訳すればわかりやすい。文法が近いためか中国語から英語への翻訳精度は高いと思います。

Google翻訳の結果:
"XcodeGhost" Source clarification on the so-called "XcodeGhost" of

First of all, I XcodeGhost event to bring confusion apologize. XcodeGhost from my own experiments, without any threatening behavior, as detailed in the source code: https: //github.com/XcodeGhostSource/XcodeGhost

The so-called XcodeGhost is actually hard to force an unexpected iOS developers find: Modify Xcode compiler configuration text file specified code can be loaded, so I wrote the code above annex to try and upload it to your network disk.

All data in the code actually acquired basic app information: application name, application version number, system version number, language, country name, symbol developer, app installation time, device name, device type. In addition, you do not get any other data. Solemn note is required: for selfish reasons, I joined the advertising features in the code, hope can promote their applications (off the source code can be compared to the Annex do check). But in fact, from the beginning to the final shut down the server, I have not used the advertising function. And in 10 days ago, I have taken the initiative off the server and remove all data, but will not have any effect on anyone.
Willing rumors would stop the truth, the so-called "XcodeGhost", used to be a wrong experiment, after just completely dead code only.

It is emphasized that, XcodeGhost App will not affect any use, but does not obtain private data, only a dead piece of code.

Again sincerely apologize, wish you a pleasant weekend

2015年9月10日木曜日

なのぼ〜どAG 1.4(2015年8月版)が出ましたね(ちと保留.時間ができたら確認します)

(注:サイトをよく確認したんですが,4月末以後の1.4との明確な差が写真と手元の実物から確認できませんでした.通信の不具合が解消しているか,現在配布しているものを確認できないので,以下の記述を当面保留します 2015-09-10)


以前のブログエントリで述べてきた,2015年5月版の「なのぼ〜どAG 1.4」について,ともんさんと何度か質問と回答のやりとりを得ながら,割と孤独に学生の実習のためハックを重ね,いろいろと面白い成果を出すことができたのですが,報告書作成のため,あらためてサイトをアクセスしたら,2015年8月版1.4にアップグレードされていて,驚愕であります.

前のエントリもそこそこのアクセスがありまして,その内容もご参照いただいたのかと思いますが,当時の懸案事項というのか,7月から8月にかけて胃を痛めながら睡眠時間削って回避方法を探ったり,基板のパターンと回路図を眺めながら,わかる人にはわかるように仕込まれている隠れ仕様を発見しつつ学生の要望に対応してきたことが,全面的にクリアになったような印象です.

ここで最も大きいのはATmega8Lをクリスタル駆動にした大英断と賞賛したいです.5月版1.4は,前のエントリに書いたとおりATmega8L内蔵のRCクロックで動作していましたので,本当に不安定でした.一応温度補償回路内蔵というメーカーの仕様ですが,電源ケーブル,その日の温度,湿度,さまざまな理由でシリアル通信の条件がつねに変化し,120〜150分の授業の間にも動く時間と動かない時間があり,この夏は異様に蒸し暑かったのですが,エアコンあれども,日に日に不安定度が増していくようなありさまでした.

当方での使い方として,ドリトルとの間でつねにシリアル通信をする形をとったので,タイミングが不安定になるとデータが欠けたり化けたり,あとProlificのWindows版ドライバを強く疑っているのですが,連続してデータをやりとりすると,Windowsのレベルでドリトルの動作が停止したり,基板との通信が止まって基板が生きているのか死んでいるのかわからなくなる,ということが頻発して途方に暮れるのでありました.Scratchセンサーボードのスケッチは毎サイクルですべてのセンサデータの送信とモータ等の動作データ受信を繰り返すので,あるサイクルで失敗しても次のサイクルで回復するとか,Scratch側がバッファ持ってて多少遅れてもなんとかなるようでしたが,ドリトルのプログラムは間欠的に,ときにバースト的にデータをやりとりするので,データの欠落や化けはわりと致命的でした.

Prolificのチップですが,Mac版ドライバは非常に安定しており,5月版なのぼ〜どAG 1.4であっても,たまにまずいところだけ5〜10ms程度の待ち時間を入れてあげる程度で,Windowsのときのようなハングは一切生じておりませんでしたが,Windowsでは,随所に50ms以上のウエイトを入れて確率8割ぐらい,PCの個体によってはどうやってもお手上げで,その個体ではATmega168Pに8MHzのクリスタルを搭載した「スタディーノ」でさえ通信ができなかったりしました.

スタディーノで使われているのは中華クローン対策をしたTA版チップで,クローンされまくったHXAの後継であるHXシリーズとは設計が違うと思われるのに,とにかくだめなときはだめです.

WindowsのドライバはProlific公式サイトからダウンロードしたものも,Windows 8.1や10で自動インストールされるドライバも,挙動に違いはみられないように観察されました.

それから,なのぼ〜どAG基板裏のジャンパパターンのカットについて,前のエントリの何度かの更新で加筆していきましたが,公式サイトでも写真つきで説明が入り,わかりやすくなりました.僕の現在の死亡フラグが立った状態が落ち着いたら,具体的な使用例込みでこちらで報告したいと思います.

それから,Li-Po(リチウムポリマーバッテリー)について,充放電管理のチップを搭載したものを入荷されたということで,これもすばらしい.SparkFunもAdafruitも商品ラインナップは電池単体で,チップはLilyPadやFloraのようにArduino基板側に搭載されるか,Breakout基板として別途提供という形でした.国内はラジコン用でホビーショップから買う経路が安定しているようですが,小型軽量なLi-Poは小さなプロジェクト,特に身に付けるような作品をスマートに仕上げるには具合がいいので,3.7〜4Vあたりの動作の回路には積極的に使っていきたい感じですが,専用充電器じゃないと怖いよ,ということで手を出しにくいところだったかと思います.という意味で電池側にチップがあるのは楽でいいです.

ただ,Li-Poは充放電を繰り返しているうちに膨張していつか破裂するという宿命があり,それは避けられないこと,パッケージは柔らかいけれど衝撃等で内部に傷やひびが入るとボーイング787初期の燃焼事故のような感じでやっぱり燃えるので,荒っぽい使い方しないよう注意してほしいと思います.で,ちょっとでも危ない気配がしたら正しい回収先に出す.

YouTubeを「battery explosion」で検索すると,バッテリーケースやスマホ本体にナイフを打ち込んで爆発大炎上させるロックな動画がいっぱい出てきますが,よいこはまねしないでくださいね.

2015年8月17日月曜日

Yosemite 10.10.4とHomebrewのOpenSSH(追記:2015年11月5日)

(追記:2015-11-05 MacPortsの7.1p1対応、Homebrew用の7.1p1向けパッチの存在についてのエントリ書きました)

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対応の現在)

  1. brew tap homebrew/dupes
  2. 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とお話できないのをごりごりする人がいるようですが,この考え方でスマートに解決できるんではないかとも思いますがどうでしょうか。