ブログという名の備忘録ですが、更新再開しました。
間違いがありましたらビシバシ指摘してください。
-----今後の更新予定-----
☆PHP ☆MySQL ☆CMS
☆JavaScripit ☆XML ☆Ajaxなどなど
その他、FreeBSDインストール編を増やしてほしい等ありましたら
コメントください。私も勉強になりますので！
間違いがありましたらビシバシ指摘してください。
-----今後の更新予定-----
☆PHP ☆MySQL ☆CMS
☆JavaScripit ☆XML ☆Ajaxなどなど
その他、FreeBSDインストール編を増やしてほしい等ありましたら
コメントください。私も勉強になりますので！
ユーザ管理
mysql> show databases; mysql> use mysql; mysql> show tables; +---------------------------+ | Tables_in_mysql | +---------------------------+ | columns_priv | | db | | func | | help_category | | help_keyword | | help_relation | | help_topic | | host | | tables_priv | | time_zone | | time_zone_leap_second | | time_zone_name | | time_zone_transition | | time_zone_transition_type | | user | +---------------------------+
PHP-Nukeインストール(１)
PHP-Nuke日本語版
http://nukejp.sourceforge.jp/
ITmedia エンタープライズ：PHP-Nuke 7
http://www.itmedia.co.jp/enterprise/articles/0412/29/news002.html
PHP-Nukeウェブポータルシステム
http://www.infotek.co.jp/o2s/o2s_phpnuke1.html
このあたりを参考にインストール中
更新再開いたします
このブログには、ブログらしいことを書かないつもりだったのですが、
気が付けば、約半年も放置してしまった。
言い訳させてもらえば、
新生活が始まったため、時間がなかったのです。
すいません。
とはいっても、今もほとんど時間はないのですが、
週末ぐらいはFreeBSDをいじって、仲良くなれる時間もありそうなので、
すこしずつ更新（備忘録になりそうですが）したいと思います。
どうぞ、よろしくお願いします。
# 読者になっていただいたみなさま、ありがとうございます。
気が付けば、約半年も放置してしまった。
言い訳させてもらえば、
新生活が始まったため、時間がなかったのです。
すいません。
とはいっても、今もほとんど時間はないのですが、
週末ぐらいはFreeBSDをいじって、仲良くなれる時間もありそうなので、
すこしずつ更新（備忘録になりそうですが）したいと思います。
どうぞ、よろしくお願いします。
# 読者になっていただいたみなさま、ありがとうございます。
Permission denied
Windows PC から putty を用いて ssh にて接続はできたのだが、
なぜか ASTEC-X（評価版）のセキュアシェルを用いた
パスワードによる接続ができなかった。
ログウィンドウを起動し確認したところ、
以下のエラーが表示されていた。
Permission denied (publickey,keyboard-interactive)
ぐぐってみたら、
接続先が OpenSSH を利用し、プロトコル優先が SSH2 であることが考えられる
なんていう記事も見つかった。
http://www.itmedia.co.jp/help/tips/linux/l0542.html
だけど、プロトコル優先が異なるなら違うエラーを出す（はず）。
Permission denied といわれていること、
パスワードを聞かれる前にsshによる認証が終了していることがおかしい。
sshd_configをもう一度確認してみてわかった。
# vi /etc/ssh/sshd_config
# Change to yes to enable built-in password authentication.
#PasswordAuthentication no
↓
PasswordAuthentication yes
ってな感じで、Passwordによる認証をOKにしてsshdを再起動。
みごと接続成功。
でも、なぜputtyでは接続できたんだろう。
同じパスワードによるログインだったのに…。
なぜか ASTEC-X（評価版）のセキュアシェルを用いた
パスワードによる接続ができなかった。
ログウィンドウを起動し確認したところ、
以下のエラーが表示されていた。
Permission denied (publickey,keyboard-interactive)
ぐぐってみたら、
接続先が OpenSSH を利用し、プロトコル優先が SSH2 であることが考えられる
なんていう記事も見つかった。
http://www.itmedia.co.jp/help/tips/linux/l0542.html
だけど、プロトコル優先が異なるなら違うエラーを出す（はず）。
Permission denied といわれていること、
パスワードを聞かれる前にsshによる認証が終了していることがおかしい。
sshd_configをもう一度確認してみてわかった。
# vi /etc/ssh/sshd_config
# Change to yes to enable built-in password authentication.
#PasswordAuthentication no
↓
PasswordAuthentication yes
ってな感じで、Passwordによる認証をOKにしてsshdを再起動。
みごと接続成功。
でも、なぜputtyでは接続できたんだろう。
同じパスワードによるログインだったのに…。
sshコマンドのログイン要求でのエラー
Protocol major versions differ: 1 vs. 2
サーバ側のsshdはバージョン2に対応。
しかしクライアント側がバージョン1であるために出るエラー。
原因はいくつか考えられる。
まずは、クライアントのsshのバージョンを確認。
からなずバージョン2を使用すること。
また、sshdをアップデートした際に、
sshd_configまでは変更されないので書き換える必要がある。
2.3.0p1 --> 2.5.2p2 とアップデートしたホストと、 また素から 2.5.2.p2 をインストールしたホストとも比較してみると、 sshd_config にも違いがあるのが解った。 そうか。アップデートの場合には sshd_config が上書きされずに 2.3.0p1 のまま になっていたから、バージョンアップによる変更に対応できていなかったのね。
とゆーことで、sshd_config に以下のエントリを追加することで、 sshd 起動時のメッセージは出なくなった。
HostKey /usr/local/etc/ssh_host_rsa_key
HostKey /usr/local/etc/ssh_host_dsa_key
しかしプロトコルバージョン 2 を用いて SSH ログインできない。
$ slogin -2 localhost
Permission denied (publickey,keyboard-interactive).
$ slogin localhost
Permission denied (publickey,keyboard-interactive).
slogin -1 localhost には問題ないことからすると、 どうやらデフォルトが 1 から 2 に変更になっているらしい。 という事は、原因は ユーザ鍵に RSA 鍵を作っていないため、か。
ssh-keygen -t rsa で Protocol 2 の RSA 鍵 (~/.ssh/id_rsa, id_rsa.pub) を生成。
ssh-keygen -t dsa で Protocol 2 の DSA 鍵 (~/.ssh/id_dsa, id_dsa.pub) を生成。
これでどうだっ！
$ slogin vizzer
Permission denied (publickey,keyboard-interactive).
むー。そうだ！ ログイン先のホストに秘密鍵を置いてないじゃん。
id_rsa.pub および id_dsa.pub をログイン先のホストの ~/.ssh/authorized_keys2 に 追加しておく。
(参考までに authorized_key2 の内容はこんな感じ)
ssh-rsa TAEAB3NzaC1yc2E....
ssh-dss TAEAB3NzaC1kc3M....
これで問題解決！
なお ssh-agent には ssh-add ~/.ssh/id_rsa 等として認証情報を登録する。
ひとつ未解決の問題。
~/.ssh/config に Protocol 2,1 を追加。これで 2 がダメだったら 1 で認証という 動作をするはずだが、思うような動作をしない。 む～。Protocol 2 や Protocol 1 では、それぞれ -2 -1 と同様の動作をするだが...。
Permission denied (publickey,keyboard-interactive
回避するためには、接続先のデーモン設定ファイル（/etc/ssh/sshd_config）を次のように編集すればよい。
# vi /etc/ssh/sshd_config ← RPMインストールの際のパス先
Protocol 2,1
↓
Protocol 1,2
この編集によって、まずはSSH1プロトコルが優先されることになる。次のようにデーモンの再起動も必要だ。
# /etc/rc.d/init.d/sshd restart
サーバ側のsshdはバージョン2に対応。
しかしクライアント側がバージョン1であるために出るエラー。
原因はいくつか考えられる。
まずは、クライアントのsshのバージョンを確認。
からなずバージョン2を使用すること。
また、sshdをアップデートした際に、
sshd_configまでは変更されないので書き換える必要がある。
2.3.0p1 --> 2.5.2p2 とアップデートしたホストと、 また素から 2.5.2.p2 をインストールしたホストとも比較してみると、 sshd_config にも違いがあるのが解った。 そうか。アップデートの場合には sshd_config が上書きされずに 2.3.0p1 のまま になっていたから、バージョンアップによる変更に対応できていなかったのね。
とゆーことで、sshd_config に以下のエントリを追加することで、 sshd 起動時のメッセージは出なくなった。
HostKey /usr/local/etc/ssh_host_rsa_key
HostKey /usr/local/etc/ssh_host_dsa_key
しかしプロトコルバージョン 2 を用いて SSH ログインできない。
$ slogin -2 localhost
Permission denied (publickey,keyboard-interactive).
$ slogin localhost
Permission denied (publickey,keyboard-interactive).
slogin -1 localhost には問題ないことからすると、 どうやらデフォルトが 1 から 2 に変更になっているらしい。 という事は、原因は ユーザ鍵に RSA 鍵を作っていないため、か。
ssh-keygen -t rsa で Protocol 2 の RSA 鍵 (~/.ssh/id_rsa, id_rsa.pub) を生成。
ssh-keygen -t dsa で Protocol 2 の DSA 鍵 (~/.ssh/id_dsa, id_dsa.pub) を生成。
これでどうだっ！
$ slogin vizzer
Permission denied (publickey,keyboard-interactive).
むー。そうだ！ ログイン先のホストに秘密鍵を置いてないじゃん。
id_rsa.pub および id_dsa.pub をログイン先のホストの ~/.ssh/authorized_keys2 に 追加しておく。
(参考までに authorized_key2 の内容はこんな感じ)
ssh-rsa TAEAB3NzaC1yc2E....
ssh-dss TAEAB3NzaC1kc3M....
これで問題解決！
なお ssh-agent には ssh-add ~/.ssh/id_rsa 等として認証情報を登録する。
ひとつ未解決の問題。
~/.ssh/config に Protocol 2,1 を追加。これで 2 がダメだったら 1 で認証という 動作をするはずだが、思うような動作をしない。 む～。Protocol 2 や Protocol 1 では、それぞれ -2 -1 と同様の動作をするだが...。
Permission denied (publickey,keyboard-interactive
回避するためには、接続先のデーモン設定ファイル（/etc/ssh/sshd_config）を次のように編集すればよい。
# vi /etc/ssh/sshd_config ← RPMインストールの際のパス先
Protocol 2,1
↓
Protocol 1,2
この編集によって、まずはSSH1プロトコルが優先されることになる。次のようにデーモンの再起動も必要だ。
# /etc/rc.d/init.d/sshd restart
SSHとは
ものすごく詳しいSSHの説明！！
★sshでの暗号化による遠隔操作
http://hiiro-sou.hp.infoseek.co.jp/unix/tips/ssh.html
sshd - OpenSSH SSH デーモン
http://www.unixuser.org/~euske/doc/openssh/jman/sshd.html
ssh-keygen - 認証用の鍵を生成、管理、および変換する
http://www.unixuser.org/~euske/doc/openssh/jman/ssh-keygen.html
鍵の作成
http://www.tcn.zaq.ne.jp/gara_k/pc_unix/pc_unix_019.htm
SSHのメモ
http://www.logos.ic.i.u-tokyo.ac.jp/~masamiti/work/ssh.html
★sshでの暗号化による遠隔操作
http://hiiro-sou.hp.infoseek.co.jp/unix/tips/ssh.html
sshd - OpenSSH SSH デーモン
http://www.unixuser.org/~euske/doc/openssh/jman/sshd.html
ssh-keygen - 認証用の鍵を生成、管理、および変換する
http://www.unixuser.org/~euske/doc/openssh/jman/ssh-keygen.html
鍵の作成
http://www.tcn.zaq.ne.jp/gara_k/pc_unix/pc_unix_019.htm
SSHのメモ
http://www.logos.ic.i.u-tokyo.ac.jp/~masamiti/work/ssh.html
Secure Shellによる安全なリモートアクセス
http://h50146.www5.hp.com/products/software/oe/hpux/developer/tips/ss_remote/p03.html
登録されるfingerprint情報について
Secure Shellクライアントを使用する場合は、telnetや rloginなとを使用する方法と大きくは異なりませんが、最初の接続の際に接続しようとしているホストの fingerprintの確認を求められます。
$ ssh login-name@server.xxx.xx
The authenticity of host 'server.xxx.xx (XXX.XXX.XXX.XXX)' can't be established.
RSA key fingerprint is c7:82:85:c9:73:0d:12:a6:91:fb:23:fc:a8:fd:47:9e.
Are you sure you want to continue connecting (yes/no)?
この確認プロンプトは最初の接続時のみに出力され、yesを選択するとこのfingerprint情報はローカルファイルに保存され次回からはプロンプトは出力されません。以降の通信ではホストのfingerprint情報と記録されている情報とが異なれば、Secure Shellクライアントはホストへの接続を拒否します。
接続しようとするホストの OSが再インストールされたりすると、fingerprintが変更されてしまいますので、この時はローカルに保存されている接続対象ホストのfingerprint情報を削除します。そうするとまた接続時に、対象のfingerprintの確認プロンプトが出力されます。
HP-UX Secure Shellでは、ホストのfingerprint情報は クライアントマシンのローカルなファイル ＜ホームディレクトリ＞/.ssh/known_hosts に格納されていますが、このファイルにはそのユーザが Secure Shellで接続したすべてのホストの fingerprint情報が含まれています。そのため fingerprint情報を削除する場合には エディタでそのファイルを編集し、該当するホストの行だけを削除します。ファイルごと削除してしまうとすべての登録済みホストに対するfingerprint情報が消えてしまいますので注意してください。
目的のホストのfingerprintの確認方法
Secure Shellでは最初の接続時に、fingerprintの確認が行われますが、この時正しくないホストを登録してしまっては意味がありません。接続するホストのfingerprintを安全な方法で入手しておき、初回接続の際にそれを確認します。
SSHサーバの RSA公開鍵が 以下のディレクトリに登録されています。fingerprintはこの公開鍵を変換し16進数形式で表現したものです。
/opt/ssh/etc/ssh_host_rsa_key.pub
このファイルの中身は、公開鍵そのものですので、このファイルをそのまま参照しても fingerprintとしては、識別できません ssh-keygenコマンドを使用して、公開鍵をfingerprintとして出力できます。
# ssh-keygen -l -f /opt/ssh/etc/ssh_host_rsa_key.pub
1024 c7:82:85:c9:73:0d:12:a6:91:fb:23:fc:a8:fd:47:9e /opt/ssh/etc/ssh_host_rsa_key.pub
sshで接続を行う前に、これを改ざんされない安全な方法で入手しておきます。セキュリティの保たれた電子媒体を使用しても良いですし、紙に出力して郵送するなどもよい方法でしょう。
登録されるfingerprint情報について
Secure Shellクライアントを使用する場合は、telnetや rloginなとを使用する方法と大きくは異なりませんが、最初の接続の際に接続しようとしているホストの fingerprintの確認を求められます。
$ ssh login-name@server.xxx.xx
The authenticity of host 'server.xxx.xx (XXX.XXX.XXX.XXX)' can't be established.
RSA key fingerprint is c7:82:85:c9:73:0d:12:a6:91:fb:23:fc:a8:fd:47:9e.
Are you sure you want to continue connecting (yes/no)?
この確認プロンプトは最初の接続時のみに出力され、yesを選択するとこのfingerprint情報はローカルファイルに保存され次回からはプロンプトは出力されません。以降の通信ではホストのfingerprint情報と記録されている情報とが異なれば、Secure Shellクライアントはホストへの接続を拒否します。
接続しようとするホストの OSが再インストールされたりすると、fingerprintが変更されてしまいますので、この時はローカルに保存されている接続対象ホストのfingerprint情報を削除します。そうするとまた接続時に、対象のfingerprintの確認プロンプトが出力されます。
HP-UX Secure Shellでは、ホストのfingerprint情報は クライアントマシンのローカルなファイル ＜ホームディレクトリ＞/.ssh/known_hosts に格納されていますが、このファイルにはそのユーザが Secure Shellで接続したすべてのホストの fingerprint情報が含まれています。そのため fingerprint情報を削除する場合には エディタでそのファイルを編集し、該当するホストの行だけを削除します。ファイルごと削除してしまうとすべての登録済みホストに対するfingerprint情報が消えてしまいますので注意してください。
目的のホストのfingerprintの確認方法
Secure Shellでは最初の接続時に、fingerprintの確認が行われますが、この時正しくないホストを登録してしまっては意味がありません。接続するホストのfingerprintを安全な方法で入手しておき、初回接続の際にそれを確認します。
SSHサーバの RSA公開鍵が 以下のディレクトリに登録されています。fingerprintはこの公開鍵を変換し16進数形式で表現したものです。
/opt/ssh/etc/ssh_host_rsa_key.pub
このファイルの中身は、公開鍵そのものですので、このファイルをそのまま参照しても fingerprintとしては、識別できません ssh-keygenコマンドを使用して、公開鍵をfingerprintとして出力できます。
# ssh-keygen -l -f /opt/ssh/etc/ssh_host_rsa_key.pub
1024 c7:82:85:c9:73:0d:12:a6:91:fb:23:fc:a8:fd:47:9e /opt/ssh/etc/ssh_host_rsa_key.pub
sshで接続を行う前に、これを改ざんされない安全な方法で入手しておきます。セキュリティの保たれた電子媒体を使用しても良いですし、紙に出力して郵送するなどもよい方法でしょう。
DynamicDNS
私的DynamicDNS(MyDNS.jp)
http://www.mydns.jp/
Dynamic DO!.jp - ダイナミックDNS -
http://ddo.jp/
ieServer.Net - ダイナミックDNS(DDNS)サービス
http://www.ieserver.net/
Dynamic Domain Name System
http://www.instat.ne.jp/ddns/index.html
ちなみに、私はieServer.Netにしました。
理由は、特になしです（笑）。
http://www.mydns.jp/
Dynamic DO!.jp - ダイナミックDNS -
http://ddo.jp/
ieServer.Net - ダイナミックDNS(DDNS)サービス
http://www.ieserver.net/
Dynamic Domain Name System
http://www.instat.ne.jp/ddns/index.html
ちなみに、私はieServer.Netにしました。
理由は、特になしです（笑）。
X と起動時のホスト名のエラー
Xを起動後以下のエラーメッセージが出た。
xauth:(argv):1:bad display name "xxx.yyy.zzz:0" in "remove" command
ADSL（Yahoo BB）によるネットワーク接続の場合
DHCP により IPアドレスが動的に割り当てられる。
このとき、自ホスト名の名前解決ができないため、
このようなエラーが出るらしい。
これを回避する解決方法としては、
/etc/hosts ファイルに自ホスト名を、
実際に割り当てられたIPアドレスをifconfigコマンドで調べ、
その都度記述すればよい。
しかし、IP アドレスが動的な場合は、
決まった IP アドレスを記述できないので（毎度調べるのも面倒なので）、
127.0.0.1 （ループバック）を利用するといい。
/etc/hostsファイルの例
127.0.0.1 localhost localhost.example.jp
127.0.0.1 xxx xxx.yyy.zzz
xauth:(argv):1:bad display name "xxx.yyy.zzz:0" in "remove" command
ADSL（Yahoo BB）によるネットワーク接続の場合
DHCP により IPアドレスが動的に割り当てられる。
このとき、自ホスト名の名前解決ができないため、
このようなエラーが出るらしい。
これを回避する解決方法としては、
/etc/hosts ファイルに自ホスト名を、
実際に割り当てられたIPアドレスをifconfigコマンドで調べ、
その都度記述すればよい。
しかし、IP アドレスが動的な場合は、
決まった IP アドレスを記述できないので（毎度調べるのも面倒なので）、
127.0.0.1 （ループバック）を利用するといい。
/etc/hostsファイルの例
127.0.0.1 localhost localhost.example.jp
127.0.0.1 xxx xxx.yyy.zzz