sshによるセキュアなftpについて。
下記条件のsftpサーバを立てる方法について。
[root@server ~]# groupadd sftponly [root@server ~]# cat /etc/group | grep sftponly sftponly:x:10000
sshでのログインはできないよう、ログインシェルには /sbin/nologin を指定する。所属グループは sftponly とする。ユーザ作成後、パスワードの設定を行う。
[root@server ~]# useradd -d / -s /sbin/nologin -g sftponly taro useradd: warning: the home directory already exists. Not copying any file from skel directory into it. [root@server ~]# cat /etc/passwd | grep taro taro:x:10000:10000::/:/sbin/nologin [root@server ~]# groups taro taro : sftponly [root@server ~]# passwd taro Changing password for user taro. New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully.
/etc/ssh/sshd_config）を編集する。
Match User taro
ChrootDirectory /var/sftp
ForceCommand internal-sftp
OpenSSHバージョン4.4以降でないとMatchディレクティブは使えないらしい（2010/05/20現在、RHEL 5.5 にて yum update で最新にした状態で OpenSSH_4.3p2, OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008、つまり使えない）[2]。
認証後chrootする（ディレクトリを移動し、そのディレクトリをルートと見せて外のディレクトリは見えないようにする）先のパスを指定する。このパスおよびその構成要素は全て所有者がrootで、他のユーザ・グループの書き込みが禁止されている必要がある（読み取り、実行は許可されていても構わないよう）。
【例】Chrootディレクトリが /var/sftp の場合 [root@server ~]# ls -l /var | grep sftp drwxr-xr-x 3 root sftponly 4096 5月 20 15:41 sftp ↑otherの実行権限（最後のx）がないと、配下ディレクトリのコンテンツが更新できない（Permission Deniedになる） [root@server ~]# ls -l /var/sftp 合計 4 drwxr-xr-x 2 sftpuser sftpuser 4096 5月 27 11:33 main
パスには、ユーザ認証後に相応の値に置き換えられる記号を埋め込むことができる。
%% → % の文字そのもの%h → 認証されたユーザのホームディレクトリ%u → 認証されたユーザのユーザ名
Chrootディレクトリにはユーザセッションの確立に必要なファイルやディレクトリを含んでいる必要がある。対話的セッションを確立するには少なくともシェル（通常 sh）および基本デバイス（null、zero、stdin、stdout
、stderr、arandom、ttyなどのデバイスを含む /dev）が必要。内部プロセスのsftpサーバを使った場合はこれらの準備は不要。既定ではchrootされない。
sftp-serverコマンドによって "sftp" のファイル転送サブシステムが実行される。この代わりに "internal-sftp" の名前を指定するとプロセス内で "sftp" サーバが実行される。これにより、ChrootDirectory を指定してクライアントにファイルシステム上の異なる場所をルートとして見せる設定が簡単になる。既定ではサブシステムの指定はなし。このオプションはSSHバージョン2でのみ使える。
※このディレクティブはOpenSSH 4.4で追加された機能。4.3p2以前では使えない[2][3]。
Match行にあるすべての条件が満たされた場合、これ以降の設定項目は次のMatch指令が現れるまでグローバルな設定よりも優先されます。Matchで指定できるのは「AllowAgentForwarding ,AllowTcpForwarding ,Banner ,ChrootDirectory ,ForceCommand ,GatewayPorts ,GSSAPIAuthentication ,HostbasedAuthentication ,KbdInteractiveAuthentication ,KerberosAuthentication ,MaxAuthTries ,MaxSessions ,PasswordAuthentication ,PermitEmptyPasswords ,PermitOpen ,PermitRootLogin ,PubkeyAuthentication ,RhostsRSAAuthentication ,RSAAuthentication ,X11DisplayOffset ,X11Forwarding, X11UseLocalHost」
| 種類 | 内容 | 例 |
|---|---|---|
| User | ユーザ名 | User taro |
| Group | グループ名 | Group sftponly |
| Host | ホスト名 | Host *.example.net |
| Address | IPアドレス | Address 192.168.100.0/24 |
X11フォワーディングを許可するかどうかを指定する。指定できる値は"yes"または"no"のいずれか１つ。既定値は"no"。
When X11 forwarding is enabled, there may be additional exposure to the server and to client displays if the sshd(8) proxy display is configured to listen on the wildcard address (see X11UseLocalhost below), though this is not the default. X11フォワーディングを有効にすると、sshd(8)プロキシディスプレイがワイルドカードアドレスに対して応答するよう設定されていた場合、 サーバを追加で外に情報をさらし、 Addi- tionally, the authentication spoofing and authentication data verification and substitution occur on the client side. The security risk of using X11 forwarding is that the client’s X11 display server may be exposed to attack when the SSH client requests forwarding (see the warnings for ForwardX11 in ssh_config(5)). A system administrator may have a stance in which they want to protect clients that may expose themselves to attack by unwittingly requesting X11 forwarding, which can war- rant a “no” setting. Note that disabling X11 forwarding does not prevent users from forwarding X11 traffic, as users can always install their own forwarders. X11 forwarding is automatically disabled if UseLogin is enabled.
sshd(8)からのログをどの分類で記録するかを指定する。指定可能な値は、DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7 のいずれか。既定値は AUTH。
既定のAUTHの場合、/etc/syslog.conf の「authoriv.*」で指定されたファイル（既定では/var/log/secure）に記録される。
sshd(8)のログ出力をどのレベルまで行うかを指定する。指定可能値は、QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, DEBUG3 のいずれか１つ。既定値は INFO。DEBUG と DEBUG1 は同じ意味。DEBUG2、DEBUG3 はそれぞれ指定レベル以上デバッグ出力を行う。DEBUGレベルでのログ出力はユーザのプライバシーを侵害するので推奨しない。
既定のAUTHの場合、/etc/syslog.conf の「authoriv.*」で指定されたファイル（既定では/var/log/secure）に記録される。
サーバへの接続に関するログの出力先はデフォルトではシステムログ。sshの設定（RHEL5/CentOS 5では/etc/ssh/sshd_config）におけるSyslogFacilityの設定（既定値はAUTH）とsyslogの設定（RHEL5/CentOS 5では/etc/syslog.conf）の設定により変更可能。
【例】
# grep ssh /var/log/messages
Oct 1 09:00:00 myserver sshd[28569]: Accepted password for user1 from 192.168.0.150 port 33373 ssh2
Oct 1 10:00:00 myserver sshd[28569]: Accepted publickey for user2 from 192.168.0.180 port 50483 ssh2
またデフォルトの指定ではファイルのやりとりに関する記録は残らないようだが、指定次第では残せる？[5]
/etc/ssh/sshd_config
Subsystem sftp internal-sftp
↓
Subsystem sftp internal-sftp -f AUTH -l INFO
[root@server ~]# /etc/init.d/sshd restart sshd を停止中: [ OK ] sshd を起動中:WARNING: initlog is deprecated and will be removed in a future release [ OK ]
「initlogは廃止予定であり、この機能は将来のバージョンでは取り除かれるでしょう」と言われている。起動スクリプト（/etc/init.d/sshd）でinitlogを使っているのが原因。今すぐ対処しないと問題になるという訳ではないが、将来的に動作に支障を来す可能性があるため、修正しておいた方が良い。修正方法は以下の通り[4]
echo -n $"Starting $prog:" initlog -c "$SSHD $OPTIONS" && success || failure ↓ echo -n $"Starting $prog:" # initlog -c "$SSHD $OPTIONS" && success || failure # コメントアウト（または削除） $SSHD $OPTIONS && success || failure # initlogを使わず直接記述
今度は問題なく起動。
[root@server ~]# /etc/init.d/sshd restart sshd を停止中: [ OK ] sshd を起動中: [ OK ]