それマグで!

知識はカップより、マグでゆっくり頂きます。 takuya_1stのブログ

習慣に早くから配慮した者は、 おそらく人生の実りも大きい。

freenxでauthentication failedになる場合(ログインできない)

authentication failed はSSHのエラー由来。認証(ログイン)に失敗した。


FreeNXのログイン処理はちょっと特殊である。その為、SSHD_CONFIG(5)でPasswordログインを無効にしているとエラーになる。そこで上手な設定方法を紹介。

問題の切り分けと確認方法

takuya@v1046r:~$ssh 127.0.0.1
password:
takuya@v1046r:~$

ローカルホストにSSHでパスワードログインできたら問題ない。

  1. ログインできる→この場合はNXの設定が悪い。
  2. ローカルログインに失敗する→SSHの設定とNXSERVERの設定の相性が悪い。

とくにパスワード認証(PasswordAutenticationが重要な設定)

解決策:2通りのアプローチ

  1. NXのパスワードデータベースを使う
  2. SSHD_CONFIGを工夫する。

僕は、汎用性と応用性が高い「2」の方法をオススメする。
「1」のアプローチは参考URLにURL貼っておいた。

解決策。sshd_configのマッチオプションを使う

ssh の設定ファイルに次の行を追加する

/etc/ssh/sshd_config
 50 PasswordAuthentication no
... 
 83 Match Address 127.0.*.*
 84   PasswordAuthentication yes
 85 Match Host localhost
 86   PasswordAuthentication yes
再起動
sudo /etc/init.d/sshd restart

これで終了。あっけないね。

動作原理

localhostからlocalhostは、パスワードでログインできるようにした。

なぜFreeNXはパスワードログイン無効だと動作しないか?

ここのエントリが詳しいので引用させていただく。

引用:SSH のパスワード認証ができない環境で FreeNX を使う

http://d.hatena.ne.jp/mobitan/20090130/1233403256

FreeNX を使うと Linux デスクトップのリモート操作が SSH だけでできるのだが、sshd_config で PasswordAuthentication no にしちゃうと認証が通らなくなる。これは FreeNX が次のような 2 段階の SSH 接続をしていて、その 2 段階目 (自分のユーザで localhostSSH 接続するところ) が公開鍵認証をサポートしてないからだ。

クライアント                                      サーバ
┏━━━┓    (1) ユーザ nx で SSH 接続         ┏━━━┓
┃      ┃                 (公開鍵認証)         ┃      ┃
┃      ┃──────────────────→┃      ┃
┃      ┃                                      ┃      ┃
┃      ┃    (2) ユーザ mobitan で SSH 接続┌─┃      ┃
┃      ┃                  (パスワード認証)└→┃      ┃
┗━━━┛                                      ┗━━━┛

と言うわけだ。つまり二回目の認証でパスワードを使えるようにしなくてはいけない。

localhostへのログインで失敗してる

localhostへのログインがパスワード認証になっている。その為に失敗している。だから、NXだけが使う条件でpasswordauthentication をYESにしたわけだ。

ちなみにfreenxがどうやって2段階目を実現しているか

これは実現方法が面白く、応用が効きそう。

/var/lib/nxserver/home/.ssh/authorized_keys
no-port-forwarding,no-agent-forwarding,command="/usr/lib/nx/nxserver" ssh-dss A..
公開鍵に、SSHの設定と動作が書いてる

ログイン時のコマンドは普通であれば、/etc/passwordに書きたいところ。また細かい設定は~/.ssh/configに記述したいところだが、コレがpublic_keyに記述することで完結している。これは知らなかった。意外と使えそうだ。

追記:NXSERVERでログイン出来ないとき

authorized_keys2をSSHdが使わない。

NXSERVERはauthorized_keys2を使う。DebianのOpenSSHはAuthorized_keysを使うのだ。このためにファイル名の相違で公開鍵が旨く利用されないことがある。この解決はふたつの方法がある。

  1. nxserverがautorized_keysを使う様に設定する
  2. sshがauthorized_keys2を使う様に設定する。

の2通りのアプローチがある。

1:nxserverがautorized_keysを使う様に設定する。

まずnxserverのHomeディレクトリを探す
root@v1046r:/# cat /etc/passwd | grep nx
nx:x:113:124:FreeNX Server,,,:/var/lib/nxserver/home/:/usr/bin/nxserver
root@v1046r:/#

今回はAptでいれたFreeNXだったので/var/lib以下にファイルがあった。NoMachineからのバイナリインストールだと場所が違うので注意が必要だ。

DebianのFreeNXの場合 /var/lib/nxserver/home/
NoMachinesのNXSERVERの場合 /usr/NX/home/
.sshディレクトリに入りファイルを移動する
takuya@v1046r:/$sudo su
root@v1046r:/# cd /var/lib/nxserver/home/
root@v1046r:/var/lib/nxserver/home/#  cp .ssh/authorized_keys .ssh/authorized_keys2

これでnxseverがautorized_keysを使う様に設定が出来た。「方法1」はここまで。

方法2:sshがauthorized_keys2を使う

こっちは影響範囲が大きいのでオススメしない。全ユーザーに設定が影響するのだ。

takuya@v1046r:~$ sudo vim /etc/ssh/sshd_config

#AuthorizedKeysFile %h/.ssh/authorized_keys #これを
AuthorizedKeysFile %h/.ssh/authorized_keys2 #に変更

takuya@v1046r:~$ sudo /etc/init.d/ssh restart

これで『全ユーザー』のSSHDがauthorized_keys2を使う様に設定が変更された。*1

感想

なんというか、動作原理が分かってないと本当にはまりこむ。特にSSHの設定周りは、いくつもアプローチがあるので面倒だった。ちゃんと考えないと、あとで大変ですね。

今回の方法は、考え抜いたからまともだと思う。でも事情が変わったら違うアプローチの方が良かったと言うことになりかねない。困ったものだ。

参考URL

NXの動作について(引用)

NX の動作

log を見ながら何をやっているのかを調べてみました。どうやら NX は以下の様な事をやっている様です。

  1. NX client はまず nx というユーザ名で、サーバに passphrase 無しの公開鍵認証で login する。NX server の install 時に nx というユーザが作られます。
  2. login に成功すると nx というユーザは直ちに /usr/NX/bin/nxserver --login を実行する。これは公開鍵 (/usr/NX/home/nx/.ssh/authorized_keys2) に書き込まれています。SSH 公開鍵認証にはこのような機能が組み込まれているのだそうです。
  3. nxserver --login でユーザ nx は local に通常ユーザ名での login を行う。NX server はクラスターもサポートしていて、登録された nodes から自動的に login する node を選択する機能もある様ですが、NX Free Edition では単に localhost に login するだけです。この login は password 認証で、username/password は NX client で与えられたものです。
  4. この通常ユーザの login が成功して X client application が実行されると、そこからの X window data は nx の起動した nxserver が受け取る事に成ります。そこで独自形式の data に作り替えて remote の NX client との間で data の遣り取りをする、という仕組みに成っている様です。

動作原理がよく解る。ちなみに、このエントリで述べられている「全世界で鍵を共有」問題は、Ubuntu9.10(Karmic)にインストールしたバージョンでは、独自キーを勧められたので、解決していると思います

*1:もちろんSSHD設定のMatchエントリを利用してユーザーnxだけがauthorized_keys2を使うように設定することも可能だ。