1  SSH + Google Authenticator

最近アカウント乗っ取り系の話がよく出ていてつい先日も Twitter のパスワードリセットを食らったところなのだが、そう言えば ssh は 2 Factors auth に対応しているのかなと思って (秘密鍵とパスフレーズが既に2 Factorsに近い気もするが、そこへの追加認証手段という意味で) ちょっと調べてみると PAM に Gooogle Authenticator による認証を追加する方法が普通にあるのだった。やり方はほぼ Two Factor SSH with Google Authenticator のまま。 Debian だと libpam-google-authenticator は deb があったのですごく簡単。

# aptitude install libpam-google-authenticator 

インストールしたら PAM の ssh 認証に google authenticator を追加する。設定ファイルの最初の方に下記の行を追加。

# vi /etc/pam.d/sshd
...
auth required pam_google_authenticator.so
...

sshd 側で Challenge Response の Auth を有効化する。

# vi /etc/ssh/sshd_config 
...
ChallengeResponseAuthentication yes
...
# /etc/init.d/sshd restart

Google Authenticator のキーを新規生成。コマンドが用意されているので ssh でログインするユーザ権限で実行する。secret key や scratch codes などは ~/.google_authenticator に保存されるようなので特にここでメモる必要はないが、このサーバに入るための緊急用認証情報である scratch codes はどこか別のところに記録しておいたほうがいいだろう。いくつか設定を聞かれるので答えておく。これも後から設定ファイルで変更できる。

$ google-authenticator

[ここにURLかQRコードが表示される]
Your new secret key is: XXXXXXXXXXXXXXXXXXXXXXXXXXX
Your verification code is 492939
Your emergency scratch codes are:
  67136983
  19738098
  69970608
  69623422
  35724953

Do you want me to update your "~/.google_authenticator" file (y/n) y
(設定ファイルを上書きするか)

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y
(同じトークンを複数箇所から使えないようにするか)

By default, tokens are good for 30 seconds and in order to compensate for
possible time-skew between the client and the server, we allow an extra
token before and after the current time. If you experience problems with poor
time synchronization, you can increase the window from its default
size of 1:30min to about 4min. Do you want to do so (y/n) n
(時計が同期してない環境のために、同期のズレの許容幅を標準の1:30から4:00にするか)

If the computer that you are logging into isn't hardened against brute-force
login attempts, you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y
(総当たり攻撃を防ぐため30秒位内の試行回数を3回までに制限するか)

元記事だと Google の URL が表示されていたが、手元の環境では terminal 内に QR コードが表示されたので、Android の Google Authenticator アプリから Menu → Setup Account → Scan a barcode で簡単にアカウント追加できる。もしくは同時に表示されている Secret Key を入力してもいい。

なお既に Google アカウントで 2 Factor auth を使っている場合でも、単にアプリ内に verification code が並んで表示されるので特に問題はない。表示識別名は `whoami`@hostname` 相当になるようだが当然アプリ側で変更できる。

$ ssh yoosee@example.com
Verification code: 
...

Verification code に Google Authenticator に表示される対応の数字6桁を入れると認証される。当然この他に公開鍵 (ないしパスワード) による認証が行われる。

ちなみに当然ながらこれ、scp などの認証でも毎回聞かれる上に ssh-agent なども効かないので頻繁に接続を繰り返すようなケースには向かなさそうだ。

1  zaSFTP

W-ZERO3ツールメモ経由で知った Windows Mobile 対応の SFTP クライアント、zaSFTP を使ってみる。ssh login の方は日本語対応された PocketPutty (現在は本家にmergeされている) があるが、これで ssh port が空いていればファイル転送も出来るようになった。鍵交換、及びパスワードによる認証が選択できる。まだベータ版ということで使い勝手に難がある箇所もあるが、ssh 経由でのファイル転送が使えるというだけでもありがたい。

ところでためしにアップロード・ダウンロードしてみたが、転送速度が非常に遅い。契約は 2x で、Opera からだと少なくとも 5.5K/s (44kbps) 程度は出てくれているのだが、こちらだと上り下りとも 1KB/s (8kbps) 程度しか出ない。暗号化処理と圧縮処理で CPU を食いつぶしているのだろうか。

1  ssh で NAT 越え常時接続する際の keepalive

自宅の Bフレッツでは Aterm WR7850S と言うルータを利用しているが、これの内側から ssh でアクセスしていると、数分間の無通信で NAT が table をクリアしてしまうらしく、通信断してしまう。keepalive for ssh によれば、Debian ならば標準 deb の OpenSSH に patch が当たっているらしく、~/.ssh/config に

ProtocolKeepAlives 120

といれておくと 120秒毎に packet を投げてくれるようだ。KeepAlive yes は TCP KeepAlive で、こっちは yes にしても標準だと 2時間毎程度でしか投げてくれないらしい。

2  pptp 経由の方は(常時通信があるから?)この影響を受けていない

ちなみに 61. で始まる方は pptp 経由なので、特に KeepAlive しなくても切れない。利用者の方はご安心を。当面は pptp をやめて Asahi-net の固定IPアドレスのみにする計画は保留するか。月1,000円程度だし…。

それにしても Aterm WaveStar の NAT 周りはあまり良い話を聞かないのが気になる。NAT table が 512 ないし 2048 しか無くて Cyclic 利用していないというのは本当なのだろうか。それ以外は有線速度も速いし安定性も問題なく使えているのだけど。

1  PocketPuTTY for W-ZERO3

PocketPuTTY は Win32 用 ssh クライアント PuTTY の WinCE 版。最新版SVNに対応した20060801版ではフォントの選択もできるようになっている。フォントサイズ 5 で横幅80程度ならばギリギリ実用レベル。日本語対応と言いつつ SJIS 以外は化けるのが辛いが、サーバ側でなんとか回避できる部分ではある。しかしやはり自前の build 環境が欲しいな…。

2  AIR-EDGE パケット通信の RTT

AIR-EDGE で ssh console を使う上での根本的な問題は、パケット通信での RTT の長さだ。vxUtil で ASAHIネット経由を測ったところ、数年前と変らず 220ms 程度かかっている。CLUB AIR-EDGE では ICMP はフィルタされているようで測定できなかったが、恐らく同等だろう。http 等ではそれなりに高速化も出来るだろうが、interactive なセッションではキーを押してから文字が出るまでの間に苛立たされる。

個人的には W-OAM 等より先に解決して欲しいところなのだが、以前に WILLCOM の人と話した感じでは努力はしているものの技術的に難しいらしい。ニッチな要望ではあるだろうが、RTT の長さは TCP/IP のパフォーマンス劣化にも繋がるので頑張って欲しいところだ。