LinuxでscpできるけどTeraTermだとエラーになる


セキュリティ対策をいろいろやっているLinuxサーバに対して、scpを使ってファイルを転送しようとしたところ、問題が発生した。

Windows上からTeraTermを使って転送を試みたところ、下記のエラーとなった。

ssh

SSH2_MSG_CHANNEL_OPEN_FAILURE を受信しました.
チャネル[1]: 理由: administratively prohibited(1) メッセージ: openfailed

でも、他のLinux上からscpコマンドでコピーすると、うまくいく。

謎なので、とりあえず、サーバ上のsshdをデバグモードで起動し、状況を確認してみる

# service sshd stop
Shutting down the listening SSH daemon                               done
# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_6.2, OpenSSL 0.9.8j-fips 07 Jan 2009
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
<略>
debug1: server_input_channel_open: ctype session rchan 1 win 131072 max 32768
debug1: input_session_request
debug1: channel 1: new [server-session]
debug1: session_open: channel 1
no more sessions
debug1: session open failed, free channel 1
debug1: channel 1: free: server-session, nchannels 2
debug1: server_input_channel_open: failure session

ファイル転送用の追加セッションを作ろうとしたところで「no more sessions」というメッセージで作成に失敗している。

/etc/ssh/sshd_configを確認すると「MaxSessions 1」と設定されていた。

このため、「MaxSessions 2」に変更し、sshdを再起動したところ、TeraTermからもSCPでファイルコピーが行えるようになった。

結局のところ、TeraTermのscp機能は、今使っているsshセッションとは別にscp用セッションを作るので数が足らない、という話だった。

RHEL6/CentOS6向けの3rdパーティーrepo



RHEL6/CentO6で使われているphpがver5.3.3と古い。
より新しいバージョンのphpを要求されている。

そんな時に、頼る先は、公式以外からリリースされているRPM群

yumでとってこれる先として代表的なもの

EPEL
Fedoraプロジェクトから出ているレポジトリ。
標準にないものを追加する方が主体で、オリジナルより新しいバージョンの提供はあまりやらない。
Cent OS6の場合「yum install epel-release」で追加できる。

RepoForge
旧名:RPMforge
標準に対するアップデートも行うし、オリジナルにないのの追加も行うし、で手広いもの。
ただ、範囲が広いので、問題が発生しやすいところがある。

IUS Community Project
mysql,php,pythonのバージョンアップを目的としたレポジトリ。
それ以外のソフトウェアについては基本的に提供されていない。
また、phpの細かいソフトウェアパッケージ群についても提供せず、基本部分のみとなっている。

Les RPM de Remi – Repository
phpのバージョンアップと、phpの細かいソフトウェアパッケージ群の提供を目的としている。
php関連をがっつり入れたい場合はコレになるかな?

・Oracle Linux
番外的なところがあるが、Oracle Linuxだと、追加のレポジトリで、MySQL 5.5/5.6対応のレポジトリが存在している。
状況によってはそちらを選択してもよいかもしれない。
参考:「Oracle Linux用の公開レポジトリについて」と「RHEL6/CentOS6をOracle Linuxにしてみる

CVE-2015-0235はRHEL4/CentOS4に影響する&修正版提供開始(2015/01/30 20:40版)



CVE-2015-0235 というglibcに大きめのバグが見つかった模様。

RedHat Enterprise Linux 4 / CentOS 4に対して影響があるのかどうかを調べてみた。

まずは、RedHat公式情報系

・RedHat Bugzilla:Bug 1183461 – (CVE-2015-0235) CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow
 ・RHEL Knowledgebase Articles:GHOST: glibc vulnerability (CVE-2015-0235) / GHOST: glibc 脆弱性 (CVE-2015-0235)
 ・RHEL CVEデータベース:CVE-2015-0235
 ・RHEL4向け:RHSA-2015:0101:Critical: glibc security update
 ・RHEL5向け:RHSA-2015:0090:Critical: glibc security update
 ・RHEL6,RHEL7向け:RHSA-2015:0092:Critical: glibc security update

はい、RHEL4も対象になっています。

実際に確認してみるため、openwallにあるCVE-2015-0235についての詳細報告書「Qualys Security Advisory CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow」の「4 – Case studies」の記述を試してみる。

実行した際に「vulnerable」と出たら、問題あり。
「not vulnerable」だったら問題なし、というもの。

[root@cent4 201501]# mkdir security
[root@cent4 201501]# cd security/
[root@cent4 security]# rpm -qa|grep glibc|sort
警告: only V3 signatures can be verified, skipping V4 signature
glibc-2.3.4-2.57
glibc-2.3.4-2.57
glibc-common-2.3.4-2.57
glibc-devel-2.3.4-2.57
glibc-devel-2.3.4-2.57
glibc-headers-2.3.4-2.57
glibc-kernheaders-2.4-9.1.103.EL
[root@cent4 security]# cat > GHOST.c << EOF
> #include <netdb.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <errno.h>
>
> #define CANARY "in_the_coal_mine"
>
> struct {
>   char buffer[1024];
>   char canary[sizeof(CANARY)];
> } temp = { "buffer", CANARY };
>
> int main(void) {
>   struct hostent resbuf;
>   struct hostent *result;
>   int herrno;
>   int retval;
>
>   /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
>   size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
>   char name[sizeof(temp.buffer)];
>   memset(name, '0', len);
>   name[len] = '\0';
>
>   retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
>
>   if (strcmp(temp.canary, CANARY) != 0) {
>     puts("vulnerable");
>     exit(EXIT_SUCCESS);
>   }
>   if (retval == ERANGE) {
>     puts("not vulnerable");
>     exit(EXIT_SUCCESS);
>   }
>   puts("should not happen");
>   exit(EXIT_FAILURE);
> }
> EOF
[root@cent4 security]# ls
GHOST.c
[root@cent4 security]# gcc GHOST.c -o GHOST
[root@cent4 security]# ls
GHOST  GHOST.c
[root@cent4 security]# ./GHOST
vulnerable
[root@cent4 security]#

「vulnerable」なので、「問題あり」確定です。

修正版については、RHEL4の通常サポートは終了。現在はELSと呼ばれる特別な契約者向けに提供されているものだけが更新されています。

前述の「RHSA-2015:0101 Critical: glibc security update」にあるとおり、修正されたglibcのバージョンは「glibc-2.3.4-2.57.el4.2」となります。

ただ、このバージョンは通常の方法ではRHEL4およびCentOS4には提供されません。

しかし、RHEL4のソースを元にOracleで再構成した、Oracle Linux 4は、まだサポートを行っています。
こちらから、ファイルを持ってくることで対応が可能となっています。

Oracle Linux 4向けのSource RPMは、「https://oss.oracle.com/el4/SRPMS-updates/」にて提供されています。
Oracle LinuxではRHEL4とパッケージバージョンが若干異なり「glibc-2.3.4-2.57.0.1.el4.1」となります。
https://oss.oracle.com/el4/SRPMS-updates/glibc-2.3.4-2.57.0.1.el4.1.src.rpm

ただ、今回のことを受けて更新されたコンパイル済みのRPMは、glibc関連だけではなかったりします。
nptl-devel, nscdも更新されています。
このため、今回については、glibcのSource RPMだけを持ってきてコンパイルして適用、というのは、あまりお薦めできないような感じです。

コンパイル済みのRPMファイルについて、Oracle Linuxでは「Oracle Public Yum Server」としてレポジトリを公開しており、適切な設定を行うことで、RHEL4/CentOS4からOracle Linux 4に乗り換え、yumコマンドによるアップデートが行えるようになります。

コンパイル済みRPMファイル自体は「http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/」以下を探せば出てきますので、ページを「2015」で検索し出てくるパッケージが自分のサーバにインストールされているかを確認し、ダウンロードして適用する、ということが可能です。

しかし、依存関係解決とか面倒なので、これを機会にOracle Linux 4に乗り換えてしまう、というのも手かもしれません。

切り替え方法については、「RHEL4/CentOS4をOracle Linux4に!」にて紹介していますので、興味がある方は参照してみてください。
設定は非常に簡単です。

こちらの環境ではOralce Linux 4になっているため「yum update -y」で更新が完了しました。

更新後、再度テストプログラムを実行してみます。

[root@cent4 security]# ./GHOST
not vulnerable
[root@cent4 security]#

「not vulnerable」と出力されるので、脆弱性は修正されている、ということになります。

これで、一安心、といったところです。


<以下は修正版のglibcが出る前に書いたものです。資料として残しておきます>

glibcに大きめのバグが見つかった模様。
CVE-2015-0235

・RedHat Bugzilla:Bug 1183461 – (CVE-2015-0235) CVE-2015-0235 glibc: __nss_hostname_digits_dots() heap-based buffer overflow
 ・RHEL CVEデータベース:CVE-2015-0235
 ・RHEL5向け:RHSA-2015:0090-1:Critical: glibc security update
 ・RHEL6,RHEL7向け:RHSA-2015:0092-1:Critical: glibc security update

RHEL4/CentOS4についての記載が見付からない。

Oracle LinuxのSource RPM置き場 https://oss.oracle.com/el4/SRPMS-updates/ を見ても、2015/01/28 10:35時点では何も無し。

(2015/01/28 23:00 追加)
1時間ぐらい前に「GHOST: glibc vulnerability (CVE-2015-0235)」にRed Hat Enterprise Linux 4 Extended Life Cycle Supportに関する記述が追加された。
いまのところ修正版に関する記述はないが、RHEL4に脆弱性がある、という公式告知になっている。

(2015/01/29 19:30追加)
Red Hat Enterprise Linux ELS (v. 4)に対するSecurity Advisoryが公開された。
RHSA-2015:0101 Critical: glibc security update

ELS契約者向けに glibc-2.3.4-2.57.el4.2 としてリリースされたので、そのうちOracle Linuxにも波及してくるものと想定されるが、現状はまだ公開されていない。

(2015/01/30 14:20追加)
https://oss.oracle.com/el4/SRPMS-updates/ に、glibc-2.3.4-2.57.0.1.el4.1.src.rpmが置かれました。
Oralce Linux 4のpublic yumレポジトリのほう(repo url)にはまだ登録されていないようです。

(2015/01/30 16:30追加)
Oracle Linux 4のpublic yumレポジトリでの配布が始まりました。

以下の16:20ぐらいの段階ではi386(32bit)版のみだったのですが、16:37にはx86_64(64bit)版のディレクトリにもファイルが置かれ始めました。

i386(32bit)版
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-common-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-devel-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-headers-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-profile-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/glibc-utils-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/nptl-devel-2.3.4-2.57.0.1.el4.1.i386.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/nptl-devel-2.3.4-2.57.0.1.el4.1.i686.rpm
 http://public-yum.oracle.com/repo/EnterpriseLinux/EL4/latest/i386/getPackage/nscd-2.3.4-2.57.0.1.el4.1.i386.rpm

64bit(x86_64)版
 

(追加部分おわり)

openwallにあるCVE-2015-0235についての詳細報告書「Qualys Security Advisory CVE-2015-0235 – GHOST: glibc gethostbyname buffer overflow」の「4 – Case studies」には事象確認方法が記載されている。

下記をコンパイルして、実行した際に「vulnerable」と出たら、問題あり。
「not vulnerable」だったら問題なし、というもの。

#include <netdb.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define CANARY "in_the_coal_mine"

struct {
  char buffer[1024];
  char canary[sizeof(CANARY)];
} temp = { "buffer", CANARY };

int main(void) {
  struct hostent resbuf;
  struct hostent *result;
  int herrno;
  int retval;

  /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
  size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
  char name[sizeof(temp.buffer)];
  memset(name, '0', len);
  name[len] = '\0';

  retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);

  if (strcmp(temp.canary, CANARY) != 0) {
    puts("vulnerable");
    exit(EXIT_SUCCESS);
  }
  if (retval == ERANGE) {
    puts("not vulnerable");
    exit(EXIT_SUCCESS);
  }
  puts("should not happen");
  exit(EXIT_FAILURE);
}

さて・・・CentOS4ではどうなっているのか?

[root@cent4 201501]# mkdir security
[root@cent4 201501]# cd security/
[root@cent4 security]# rpm -qa|grep glibc|sort
警告: only V3 signatures can be verified, skipping V4 signature
glibc-2.3.4-2.57
glibc-2.3.4-2.57
glibc-common-2.3.4-2.57
glibc-devel-2.3.4-2.57
glibc-devel-2.3.4-2.57
glibc-headers-2.3.4-2.57
glibc-kernheaders-2.4-9.1.103.EL
[root@cent4 security]# cat > GHOST.c << EOF
> #include <netdb.h>
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <errno.h>
>
> #define CANARY "in_the_coal_mine"
>
> struct {
>   char buffer[1024];
>   char canary[sizeof(CANARY)];
> } temp = { "buffer", CANARY };
>
> int main(void) {
>   struct hostent resbuf;
>   struct hostent *result;
>   int herrno;
>   int retval;
>
>   /*** strlen (name) = size_needed - sizeof (*host_addr) - sizeof (*h_addr_ptrs) - 1; ***/
>   size_t len = sizeof(temp.buffer) - 16*sizeof(unsigned char) - 2*sizeof(char *) - 1;
>   char name[sizeof(temp.buffer)];
>   memset(name, '0', len);
>   name[len] = '\0';
>
>   retval = gethostbyname_r(name, &resbuf, temp.buffer, sizeof(temp.buffer), &result, &herrno);
>
>   if (strcmp(temp.canary, CANARY) != 0) {
>     puts("vulnerable");
>     exit(EXIT_SUCCESS);
>   }
>   if (retval == ERANGE) {
>     puts("not vulnerable");
>     exit(EXIT_SUCCESS);
>   }
>   puts("should not happen");
>   exit(EXIT_FAILURE);
> }
> EOF
[root@cent4 security]# ls
GHOST.c
[root@cent4 security]# gcc GHOST.c -o GHOST
[root@cent4 security]# ls
GHOST  GHOST.c
[root@cent4 security]# ./GHOST
vulnerable
[root@cent4 security]#

駄目でした。

とりあえず、続報待ちということで・・・

(2015/01/30 16:50追記)
Oralce public yum repoで提供されたのでアップデートを行い、試験実施。

[root@cent4 security]# ./ghost
not vulnerable
[root@cent4 security]#

問題がなくなったことを確認できました。

なお、Oracle Linux public レポジトリからyumコマンドを使ってファイルを持ってこれるようにするには「RHEL4/CentOS4をOracle Linux4に!」で紹介しているようにOracle Linuxに切り替えてしまう、というのが簡単でいいと思います。

RHEL6でSAN Boot multipath構成時、initramfsを再作成するとmultipath関連が組み込まれないことがある



RedHat Enterprise Linux/Cent OS6.5環境で、SAN Boot multipath構成を作成した。

構築後、バックアップを取得し、別のLUNにリストアし、そのディスクからブートをさせた。

ディスク自身が持つ、WWIDが変更になったため、multipath構成が外れた状態で起動してくる、というのは想定通りだったのだが、設定を修正し、initramfsを再作成して、再起動しても、multipath構成にならず、悩んだ。

原因は「How do I rebuild the initramfs with multipath.」であった。

普通にdracutでinitramfsを再作成すると、multipath関連モジュールが組み込まれていないものができあがっていた。
これをmultipathモジュールを組み込むことを強制させるようにして、解決した。

手順

1. とりあえず起動
2. 現在のディスクのwwidを確認
現在のディスクの「/dev/sd?」を確認し、そのディスク名に対して「scsi_id –whitelist /dev/sd?」を実行して確認する。

# df -h
/dev/sdb3 ~ /
tmpfs ~ /dev/shm
/dev/sdb1 ~/boot
# scsi_id --whitelist /dev/sdb
<wwid>
#

3. /etc/multipath.conf内のwwid変更
multipath.conf内に「wwid 値」という記述があるので、現在の値に変更する。

4. /etc/multipath/bindings内のwwid変更
bindings内に「mpatha 値」といった記述があるので、現在の値に変更する。
(注: mpathaをsdbとかに変更しないこと)

5. 古いinitramfsをバックアップ

6. intiramfsを作成

# dracut -v -f -a multipath --include /etc/multipath /etc/multipath
#

もしくは、/etc/dracut.confに以下の記述を行ってから、dracutを実行する。

# Dracut modules to add to the default
add_dracutmodules+="multipath"

7. 再起動

RHEL6でインストール時からSAN Boot multipath構成したら/bootがマウントされない



RHEL6で、SAN Boot multipath構成を組んでみた。
起動時からmultipath設定でうまくいくのかなぁ?と思ったら、案の定、いくつか問題が・・・

ディスクは/dev/mapper/mpathaで認識しており、
/dev/mapper/mpathap1 /boot 500MB
/dev/mapper/mpathap2 swap 適量
/dev/mapper/mpathap3 / 残り全部
いうパーテーション設定。

この状況で起動したところ、/etc/fstabが以下となっていた。

UUID=~ /                       ext4    defaults,_rnetdev 1 1
UUID=~ /boot                   ext4    defaults,_netdev 1 2
/dev/mapper/mpathap2    swap                    swap    defaults,_netdev 0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

この状態だと、起動時、/bootがマウントされていなかった。
「mount -a」を実行するとマウントはされた。

UUID指定ではなく、mpatha指定なら行くだろうと、変更してみても/bootがマウントされない。

いろいろ試した結果、マウントオプションが「defaults,_netdev」となっていることが原因だった。

最終的に、以下の様な/etc/fstabとした。

/dev/mapper/mpathap3    /                       ext4    defaults,_rnetdev 1 1
/dev/mapper/mpathap1    /boot                   ext4    defaults 1 2
/dev/mapper/mpathap2    swap                    swap    defaults,_netdev 0 0
tmpfs                   /dev/shm                tmpfs   defaults        0 0
devpts                  /dev/pts                devpts  gid=5,mode=620  0 0
sysfs                   /sys                    sysfs   defaults        0 0
proc                    /proc                   proc    defaults        0 0

ちなみに、mpath指定ではなく、UUID指定でもきちんと動作しました。