ssh で segmentation fault

新規アカウントを作っても接続できませんか？

質問と意図が違ったら申し訳ありませんが...
localhost 側で新規アカウントを作成しても、やはり同様にsegmentation fault が発生します。
remotehost 側に関しては新規アカウントを作成することが出来ないのですが、他のユーザは問題なく接続しております。

> localhost 側で新規アカウントを作成しても、やはり同様にsegmentation fault が発生します。
そうですか。
openssh のウェブサイトで調べても、パーミッション関係による不具合ぐらいしか見当たりませんので、新規アカウントからならうまくいくかもと思ったのですが。
ssh に -o ChallengeResponseAuthentication というオプションを付けてみるとどうですか？
Windows の ssh クライアントから、ある種の Linux 機に接続するときは、このオプションを付けないと接続できないです。

-o ChallengeResponseAuthentication というオプションを付けると、
command-line line 0: Missing yes/no argument.
と言われてしまって上手くいきません。
U.S. の Discussion Board
http://discussions.apple.com/thread.jspa?messageID=2426071&tstart=0#2426071
でも解決策がないようで、次のupdateまで待たなきゃいけないのかなと言ってます。

> command-line line 0: Missing yes/no argument.
> と言われてしまって上手くいきません
ならば、-o ChallengeResponseAuthentication yes とするとどうですか?

そういう事なんですね。すいません。
-o ChallengeResponseAuthentication=yes と付けて実行しても、結局 segmentation fault で止まってしまうことには変わりありませんでした。-v での出力も変化ありませんでした。

> ssh での接続が segmentation fault となり接続できなくなってしまいました。
同症状の方を見つけたので、一応リンクしておきます。
http://pc7.2ch.net/test/read.cgi/mac/1111656280/673-701
投稿日が5/23なので、原因が同じであるとするならばセキュリティアップデートは関係ないかもしれません。
症状の出ているお三方に共通するのは、intel Macであるということ・・・？
リンク先のヒトのコメントに「DarwinPorts で入れた ssh は問題なく動いた」とあるので設定の問題ではなくssh自身の問題？
ターミナルから
file /usr/bin/ssh
としたときにどのように返答がきますか？（半ば当てずっぽう）

localhostへの接続でも同じでしょうか？
sshあるいは関連ライブラリが壊れている可能性もあるかも。ktraceでトレースすれば、もう少し原因がしぼれるかもしれません。
なお、PPC Macの場合は、ssh関連のモジュール（本体およびダイナミックライブラリ）では、最新のセキュリティアップデート（2006-003）でアップデートされたものはないようです。

2ch のこの投稿のあとは進展がなさそうなんですね。intel Mac の方でもこの症状に遭遇している人は少ないということなんですかねぇ。
DarwinPorts は使用したことがないので大変そうな印象がありますが、トライしてみます。
ちなみに、file /usr/bin/ssh の出力は、
/usr/bin/ssh: Mach-O universal binary with 2 architectures
/usr/bin/ssh (for architecture i386): Mach-O executable i386
/usr/bin/ssh (for architecture ppc): Mach-O executable ppc
となってました。

localhost への接続は成功しました。以下に出力を載せておきます。途中エラーらしき文字も見られますが(良く分からないので)...
ktrace は初耳で使い方には慣れていないので、少し時間がかかりそうですが、調べてみたいと思います。
--- 以下は、ssh -v localhost の出力 ---
OpenSSH_3.8.1p1, OpenSSL 0.9.7i 14 Oct 2005
debug1: Reading configuration data /Users/ryo/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to localhost [::1] port 22.
debug1: Connection established.
debug1: identity file /Users/ryo/.ssh/identity type -1
debug1: identity file /Users/ryo/.ssh/id_rsa type 1
debug1: identity file /Users/ryo/.ssh/id_dsa type 2
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.8.1p1
debug1: match: OpenSSH_3.8.1p1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1
debug1: An invalid name was supplied
Configuration file does not specify default realm
debug1: An invalid name was supplied
A parameter was malformed
Validation error
debug1: An invalid name was supplied
Configuration file does not specify default realm
debug1: An invalid name was supplied
A parameter was malformed
Validation error
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'localhost' is known and matches the RSA host key.
debug1: Found key in /Users/ryo/.ssh/known_hosts:51
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: An invalid name was supplied
Configuration file does not specify default realm
debug1: An invalid name was supplied
Configuration file does not specify default realm
debug1: Next authentication method: gssapi
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/ryo/.ssh/id_dsa
debug1: Authentications that can continue: gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug1: Trying private key: /Users/ryo/.ssh/identity
debug1: Offering public key: /Users/ryo/.ssh/id_rsa
debug1: Authentications that can continue: gssapi-with-mic,publickey,gssapi,password,keyboard-interactive
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Requesting authentication agent forwarding.
Last login: Thu Jun 22 09:23:47 2006 from localhost
Welcome to Darwin!

localhostでは問題ないとすると、認証方式が異なるのでしょうか？リモートホスト間の認証方式は何でしょうか？
ktraceの使い方です。
% sudo ktrace ssh -v hoge@host
これで普通にsshが実行され、同じようにエラーになるはずです。
これで、sshで行われたカーネルでのシステムコールがすべてktrace.outというファイルにバイナリでダンプされます。続いて
% sudo kdump > ssh.ktrace
これで出力をアスキーテキストに変換します。ssh.ktraceにリダイレクトするのは、kdumpの出力が膨大になる（多分数千行）ためです。「ssh.ktrace」は他の名前でも構いません。
あとはssh.ktraceをエディタで開いて、segmentation faultが発生する前にどのようなシステムコールが呼ばれているかを調べます。ただし、プログラミングの経験がないと、ほとんど内容がわからないかもしれません。
ちなみに私がlocalhostへsshした場合のktraceの結果では、「debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1」の出力の後は、Kerberos認証のプロセスに入ります。

ktrace 使ってみましたが、予想された通り何が書いてあるか全く分かりません。
私の方も「"debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1」の数行後に、
2533 ssh NAMI "/Users/ryo/Library/Preferences/edu.mit.Kerberos"
という行があったので、Kerberos認証のプロセスに入っているものと思われます。
最後の数行は、
2533 ssh CALL stat(0xbfffddd0,0xbfffe1d0)
2533 ssh NAMI "/System/Library/Frameworks/SystemConfiguration.framework/SystemConfiguration"
2533 ssh RET stat 0
2533 ssh PSIG SIGSEGV SIG_DFL
となっておりました。
ktraceの出力の意味を何も分かってないので、意味のないものを示しているかもしれませんが...

結局、今のところ ssh 自身に問題がありそうということで、DarwinPorts の openssh を使うことにしました。
これだと今まで segmentation fault が生じていたところもすんなり通過するして使用できました。
皆さん、ありがとうございました。