9.1 概要
SFTP手順が提供する機能の概要を解説します。
ACMS Cloudの概要の他、SFTP手順のプロトコルの詳細について学びたい場合は、以下のリンクをご参照ください。
https://community.dal.co.jp/s/article/protocol-sftp
9.1.1 特徴
- ファイル（コンピュータプログラムやデータ等）を共有することの助けとなります
- プログラムを通して間接的にもしくは意識せずに遠隔地にあるコンピュータを使用することの助けとなります
- ホストのファイルの保管システムの変化から使用者を保護します
- 確実かつ能率的にデータを移動します
- 処理の起点はクライアント側であり、クライアントからサーバーへの接続により処理が開始されファイルの送信や受信を行います
- ホスト認証や暗号化により、安全性の高いファイル転送を行います。
9.1.2 接続方式
SFTPはホスト認証やデータ暗号化を行うSSHプロトコルによる伝送路上で、SFTPサブシステムというチャンネルを開設してファイル転送を行う仕組みになっています。
SFTPによるファイル転送はクライアントがリクエストを行いサーバーがレスポンスを行います。
■SFTP概念図
9.1.3 FTPとの比較
SFTPを実装しているソフトウェアの多くは、FTPに類似したユーザーインターフェースを提供しますが、SFTPはSSHプロトコルのファイル転送サブシステムとして策定された仕様であり、FTPとの互換性はありません。FTPとSFTPの主な違いは次のとおりです。
- SFTPではFTPのFTPコマンドやFTPリプライコードとは異なる体系で要求と応答を行います。
- FTPでは転送制御を行うコネクションとデータ送受信を行うコネクションを使用しますが、SFTPはこれらを一つのコネクションで行います。そのためアクティブモードやパッシブモードがありません。
9.1.4 SFTPの通信シーケンス
SFTPによるクライアントとサーバー間の通信シーケンスを以下に示します。
■SFTP通信シーケンス
1.バージョンの確認
クライアントとサーバーはお互いのSSHプロトコルバージョンを連絡し、通信可能かどうか確認します。
ACMS CloudはSSH2.0のみサポートしており、SSH1.0で通信することはできません。
2.アルゴリズムの確認
クライアントとサーバーはお互いがサポートするアルゴリズムの優先順位を連絡します。連絡するアルゴリズムは「鍵交換方法」、「公開鍵アルゴリズム」、「暗号アルゴリズム」、「メッセージ認証コード(MAC)」、「圧縮アルゴリズム」などです。
クライアントとサーバーはお互いのアルゴリズムで一致する優先順位の高いアルゴリズムを選択します。一致するアルゴリズムが見つからなかった場合、通信を切断します。
ACMS Cloudがサポートするアルゴリズムについては、「9.2.1.1プロトコル仕様」を参照してください。
3.鍵交換
データ暗号化に使用する鍵の元になる値をお互いに交換します。
サーバーはサーバーホストのキーペアの公開鍵もクライアントに送信します。
4.サーバー認証
クライアントは鍵交換でサーバーから受け取った公開鍵と、事前に登録しているサーバーホストの公開鍵を比較します。比較の結果、一致しなければクライアントは通信を切断します。
サーバー認証の詳細については、「9.2.1.2 サーバー認証」を参照してください。
5.ユーザー認証
クライアントはサーバーにユーザー認証を要求します。サーバーはユーザー認証要求の内容が正しいかどうかチェックして、その結果をクライアントに応答します。また、認証が正しい場合にはバナーメッセージも応答することができます。
サーバーの応答が認証失敗であった場合、クライアントは他の認証方法を試行するか通信を切断します。
ユーザー認証の詳細については、「9.2.1.3 ユーザー認証」を参照してください。
6.SFTPサブシステムチャンネルの開設
クライアントはサーバーにSFTPサブシステムチャンネルの開始を要求します。サーバーはSFTPサービスを提供できない場合、この要求を拒否します。
クライアントはサーバーにSFTPサブシステムチャンネル開始の要求を拒否された場合、通信を切断します。
SFTPサブシステムチャンネルが開設されると、クライアントはSFTPのバージョンをサーバーに通知します。
サーバーはサポートしているSFTPバージョンおよびクライアントに通知されたSFTPバージョンの低いほうのバージョンをクライアントに通知します2。サーバーがクライアントのサポートするバージョンよりも大きいバージョンを通知した場合、ファイル転送を正しく行うことはできません。
7.ファイル送受信などのファイル転送
クライアントはサーバーにディレクトリ操作やファイル操作などをリクエストし、サーバーはその結果をクライアントに応答します。
8.チャンネルの終了
クライアントとサーバーはSFTPサブシステムを終了します。
9.通信の終了
クライアントとサーバーはSSH通信を終了し、切断します。
鍵交換の詳細な仕様については、「RFC4253 The Secure Shell (SSH) Transport Layer Protocol」『6.5. Key Exchange Methods』、「RFC4419 Diffie-hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol」を参照してください。
2 詳細な仕様については、「draft-ietf-secsh-filexfer-02.txt」『4. Protocol Initialization』を参照してください。
9.2 仕様
SFTPに関する機能の仕様を解説します。
9.2.1 SSH
9.2.1.1 プロトコル仕様
ACMS CloudがサポートするSSHプロトコルの仕様は下記「SSHプロトコル仕様」のとおりです。この表に記載されていない機能はサポートしていません。
■SSHプロトコル仕様
項目名 | 説明 |
|---|---|
バージョン | ・2.0 |
鍵交換方法 | ・diffie-hellman-group-exchange-sha256 ・diffie-hellman-group-exchange-sha1 ・diffie-hellman-group14-sha256 ・diffie-hellman-group14-sha1 ・diffie-hellman-group1-sha1 |
公開鍵アルゴリズム | ・rsa-sha2-512 ・rsa-sha2-256 ・ssh-rsa ・ssh-dss |
暗号アルゴリズム | ・aes256-cbc ・aes192-cbc ・aes128-cbc ・3des-cbc ・3des-ctr ・blowfish-cbc ・aes256-ctr ・aes192-ctr ・aes128-ctr ・arcfour256 ・arcfour128 ・arcfour |
メッセージ認証コード(MAC) | ・hmac-sha2-512 ・hmac-sha2-256 ・hmac-sha1 ・hmac-sha1-96 ・hmac-md5 ・hmac-md5-96 |
圧縮アルゴリズム | ・none ・zlib ・zlib@openssh.com |
ユーザー認証方法 | ・公開鍵認証(publickey) ・パスワード認証(password)※SFTPクライアントのみ ・2段階認証(partial authentication) |
チャンネルタイプ | ・session |
チャンネルリクエスト | ・subsystem(サブシステム名”sftp”のみ) |
通信中のチャンネル数 | ・1チャンネル |
9.2.1.2 サーバー認証
サーバー認証はクライアントが事前に入手しておいたサーバーの公開鍵と通信時にサーバーが送信してくる公開鍵との比較により、クライアントが認証を許可する仕組みです。サーバー認証の運用イメージは「サーバー認証の運用イメージ」のとおりです。
■サーバー認証の運用イメージ
9.2.1.3 ユーザー認証
ユーザー認証は認証情報をクライアントがサーバーに送信し、サーバーはその情報を検査して認証結果をクライアントに通知します。サーバーはクライアントの認証情報が不完全であると判断した場合、認証失敗をクライアントに通知します。
クライアントは、持っている認証情報とサーバーから指示された認証方法を元に認証情報の送信(認証要求)を行います。これは認証成功応答を受信するか、試行できる認証が無くなるまで繰り返されます。
クライアントが使用する認証方法はサーバーの指示により決定されます。サーバーの指示に複数の認証方法が含まれる場合は、それらのうちどの方法を使用するかをクライアントが選択することができます。
ACMS Cloudはユーザー認証方法として公開鍵認証とパスワード認証をサポートします。認証方法は通信相手先の設定によるため、事前に確認が必要です。
なお、RFC8308の「server-sig-algs」に対応しております。その際、対象となる公開鍵アルゴリズムは「comm.sftp.server.host_key」または「comm.sftp.client.host_key」の設定に基づきます。
以下はユーザー認証のイメージ図です。
サーバーが公開鍵認証またはパスワード認証のどちらかで認証を行うことを指示し、クライアントが公開鍵認証を選択する例を示します。
■ユーザー認証のイメージ
9.2.1.4 公開鍵認証
公開鍵認証を行うためには、キーペアを準備してクライアント側では秘密鍵を保持し、サーバー側では公開鍵を保持しておく必要があります。
サーバーとの通信でユーザー認証を行う時、クライアントはキーペアから公開鍵を取得してサーバーに送信します。サーバーは事前に入手しておいたクライアントの公開鍵と比較することで認証を行います。公開鍵認証の運用方法は「公開鍵認証の運用方法」のとおりです。
■公開鍵認証の運用方法
9.2.1.5パスワード認証
パスワード認証を行うためには、サーバーにログインするユーザーパスワードが必要になります。サーバーの担当者からログインするユーザーのパスワードを入手してください。
サーバーとの通信でユーザー認証を行うとき、クライアントは入手しておいたパスワードをサーバーに送信します。サーバーはパスワードを検査することで認証を行います。
9.2.2 SFTPクライアント
9.2.2.1 プロトコル仕様
ACMS CloudがサポートするSFTPの仕様は下記「SFTP仕様」のとおりです。この表に記載されていない機能はサポートしていません。
■SFTP仕様
| 項目名 | 説明 |
|---|---|
バージョン | 3 |
文字セット | UTF-8 |
ファイル名 | ディレクトリの区切り文字は「/(スラッシュ)」 |
SFTPではクライアントとサーバーがSFTPバージョンの確認を行います。バージョンの確認はクライアントがサーバーに通知し、実際にファイル転送を行うバージョンをサーバーがクライアントに通知する手順で行われます。サーバーがクライアントに通知するバージョンは、サーバーが対応しているバージョンおよびクライアントが通知したバージョンの低いほうになります。ACMSがサポートするSFTPバージョンは「3」であるため、通信相手先のSFTPサーバーは「3」を通知する必要があります。「3」よりも大きいまたは小さいバージョンを通知された場合、ファイル転送を正しく行うことはできません。
9.2.2.2 サポートするSFTPクライアント機能
ACMS CloudがサポートするSFTPクライアントの機能は下記「SFTPクライアント機能」のとおりです。
■SFTPクライアント機能
項目名 | 説明 |
|---|---|
ファイルの受信 | ・バイナリ転送のみ ・複数受信 |
ファイルの送信 | ・バイナリ転送のみ ・送信 ・連結送信 |
ファイルリストの受信 | ・ファイルリストの受信 ・ロングファイルリストの受信 |
ファイル操作 | ・削除 ・移動 |
ディレクトリリスト操作 | ・ファイル名の取得 ・ファイル詳細情報の取得 ・ワイルドカードによる取得 |
ワイルドカード | ・「*(アスタリスク)」 ・「?(クエスチョン)」 ※「[](角括弧)」、「{}(波括弧)」には対応していません |
9.2.2.3 LIST/LONG LIST 出力フォーマット
ACMS Cloudが出力するLIST/LONG の出力フォーマットは以下のとおりです。
■共通
| 項目名 | 説明 |
|---|---|
文字コード | 稼働環境の文字コード |
並び順 | Unicode順 |
件数制限 | 無し |
■LIST
| 項目名 | 説明 |
|---|---|
出力項目 | ファイル名 |
出力イメージ
■LONG LIST
| 項目名 | 説明 |
|---|---|
出力項目 | ・パーミッション ・ハードリンク数 ・所有者とグループ ・ファイルサイズ ・タイムスタンプ ・ファイル名 |
出力イメージ
9.2.2.4 SFTPリプライコード
SFTPクライアントでは下表のとおり応答メッセージを検証します。
| 値 | 名前 | 内容 |
|---|---|---|
0 | SSH_FX_OK | 正常終了と見なします。 |
1 | SSH_FX_EOF | |
2 | SSH_FX_NO_SUCH_FILE | ファイル無しエラーと見なします。 |
3 | SSH_FX_PERMISSION_DENIED | エラーと見なします。 |
4 | SSH_FX_FAILURE | |
5 | SSH_FX_BAD_MESSAGE | |
6 | SSH_FX_NO_CONNECTION | |
7 | SSH_FX_CONNECTION_LOST | |
8 | SSH_FX_OP_UNSUPPORTED |
9.2.2.5 ファイルの移動/削除
ファイルのGET/MGETまたはPUT/APPEND後にSFTPサーバーの対象ファイルに対しての移動／削除を指定することができます。設定方法については「19.1.1.4 論理ファイルの作成」を参照してください。
| ユーザーコマンド | 移動/削除 | 内容 |
|---|---|---|
GET/MGET | 削除 | ファイル転送後にGET/MGETしたファイルをサーバーから削除します。 |
移動 | ファイル転送後にGET/MGETしたファイルを指定した移動先に移動します。 | |
PUT/APPEND | 削除 | ファイル転送後にPUT/APPENDしたファイルをサーバーから削除します。 |
移動 | ファイル転送後にPUT/APPENDしたファイルを指定した移動先に移動します。 |
9.2.2.6 ファイル転送前後チェックコマンド
ファイル転送前後で一部のSFTPコマンドを実行することができます。設定方法については「19.1.1.4 論理ファイルの作成」を参照してください。
ファイル転送前チェックコマンドとファイル転送後チェックコマンドに設定できるSFTPコマンドは下表のとおりです。
| コマンド | 形式 | 説明 |
|---|---|---|
mkdir | mkdir パス | パスに指定したディレクトリを作成します。 |
rmdir | rmdir パス | パスに指定したディレクトリを削除します。 |
rm | rm パス | パスに指定したファイルを削除します。 |
rename | rename 変更元のパス 変更先のパス | 変更元のパスに指定したファイル名を変更先のパスに指定したファイル名に変更します。 |
9.2.2.7 ファイル成立タイミング
ファイル転送の成立タイミングを指定することができます。設定方法については「19.1.1.4 論理ファイルの作成」を参照してください。
9.2.2.8 障害復旧と再開
ファイル転送時のデータの不正はファイルサイズによってチェックします。このチェックで不正が発生した場合又はネットワークの問題等でファイル転送に何らかの障害が発生した場合、ACMS Cloudのタスクは「障害」として登録されます。
障害の原因を取り除いた後、運用管理画面から当該タスクを再実行することができます。この場合は常にファイルの先頭から転送をやり直します。
9.2.3 SFTPサーバー
9.2.3.1 プロトコル仕様
ACMS CloudがサポートするSFTPの仕様は「SFTP仕様」のとおりです。この表に記載されていない機能はサポートしていません。
■SFTP仕様
| 項目名 | 説明 |
|---|---|
バージョン | 3 |
文字セット | UTF-8 |
ファイル名 | ディレクトリの区切り文字は「/(スラッシュ)」 |
SFTPではクライアントとサーバーがSFTPバージョンの確認を行います。バージョンの確認はクライアントがサーバーに通知し、実際にファイル転送を行うバージョンをサーバーがクライアントに通知する手順で行われます。サーバーがクライアントに通知するバージョンは、サーバーが対応しているバージョンおよびクライアントが通知したバージョンの低いほうになります。ACMS CloudがサポートするSFTPバージョンは「3」であるため、通信相手先のSFTPクライアントは「3」以上のバージョンを通知する必要があります。「2」以下のバージョンを通知された場合、ファイル転送を行うことはできません。
9.2.3.2 サポートするSFTPサーバー機能
ACMS CloudがサポートするSFTPサーバーの機能は「SFTPサーバー機能」のとおりです。
■SFTPサーバー機能
| 項目名 | 説明 |
|---|---|
ファイルの受信 | ・バイナリ転送のみ ・受信（追加受信(APPEND)は未サポート） |
項目名 | 説明 |
ファイルの送信 | ・バイナリ転送のみ ・送信（追加送信(APPEND)は未サポート） ・連結送信 |
ファイル操作 | ・削除 ・移動 |
ディレクトリリスト操作 | ・ファイル名の取得 ・ファイル詳細情報の取得 |
属性操作 | ・属性の参照(属性の変更は未サポート) |
同時にオープン可能なファイル、ディレクトリ数 | ・1件のみ |
9.2.3.3 同時着信制限
SFTPサーバーでは、着信可能な通信ポート数以上の着信があった場合は、着信を拒否します。
9.2.3.4 転送ディレクトリ
SFTPサーバーでは、接続相手先(SFTPクライアント)側のログイン後に表示しているディレクトリ構成をACMS Cloudの管理情報(DBに登録された論理ファイル情報)を使用して仮想的に表現します。
ログイン直後のディレクトリをトップのルートディレクトリ「/」とし、その配下に論理ファイル情報の「転送ディレクトリ」で指定したディレクトリを移動可能なディレクトリとして表示します。この「転送ディレクトリ」は階層セパレータ「/」を使用して複数の階層を指定することが可能です。但し、ファイルの送受信が行えるディレクトリは最下位層のみとなります。
詳細は「draft-ietf-secsh-filexfer-02.txt」『4. Protocol Initialization』を参照してください。
| 転送ディレクトリ | 内容 |
|---|---|
/aaa | aaaディレクトリ内で送受信が行えます。 ルートディレクトリ内では送受信は行えません。 |
/aaa/bbb | bbbディレクトリ内で送受信が行えます。 aaaディレクトリ内では送受信は行えません。 ルートディレクトリ内では送受信は行えません。 |
転送ディレクトリ | 内容 |
/aaa/bbb/ccc | cccディレクトリ内で送受信が行えます。 bbbディレクトリ内では送受信は行えません。 aaaディレクトリ内では送受信は行えません。 ルートディレクトリ内では送受信は行えません。 |
「送信」と「受信」が同一「転送ディレクトリ」を使用することはできません。したがって同一「転送ディレクトリ」で「送受」が異なる論理ファイル情報の登録は行えません。
ACMS Cloudにおいてファイル送受信はタスクという単位で管理されます。タスクは論理ファイル情報に紐づき、1回の送信または受信は1つのタスクとして登録されます。
送受信したデータファイルはこのタスクに紐づけられて管理されます。SFTPサーバーは、タスク情報を元にファイルの情報をクライアントに送信します。
このためファイルの送信を行う場合は先に送信タスクの登録が必要となります。なお、送受信タスク登録時の「伝送ファイル名」でも階層セパレータ「/」を使用してディレクトリを１階層指定することが可能です。この場合、論理ファイル情報で設定された「転送ディレクトリ」配下にさらに「伝送ファイル名」で設定されたディレクトリが構築されることになります。
9.2.3.5 SFTPリプライコード
ACMS CloudのSFTPサーバーは下記の応答メッセージを返します。
■応答メッセージ
| 値 | 名前 | 内容 |
|---|---|---|
0 | SSH_FX_OK | 正常終了した |
1 | SSH_FX_EOF | ファイルの終わりに達した |
2 | SSH_FX_NO_SUCH_FILE | ファイルやディレクトリは存在しなかった。 |
3 | SSH_FX_PERMISSION_DENIED | アクセスを拒否された |
4 | SSH_FX_FAILURE | 他のエラーコードで定義されていないエラーが発生した |
8 | SSH_FX_OP_UNSUPPORTED | 非サポートの操作を行った |
9.2.3.6 リストコマンド
SFTPサーバーはクライアントからのリストコマンドに対して、「リストコマンドに対する応答」を返します。
■リストコマンドに対する応答
| 名前 | 内容 |
|---|---|
filename | ファイル名またはディレクトリ名 |
longname | 「ls –l」を実行した結果の形式 [permissions] [リンクファイル数] [uid] [gid] [size] [mtime] [filename] ACMS Cloudではリンクファイル数は「1」固定 |
size | ファイルのサイズ ACMS Cloudではディレクトリの場合は4096固定 |
uid | ユーザーID ACMS Cloudではログイン時のログインユーザー名 |
gid | グループID ACMS Cloudではログイン時のログインユーザー名 |
permissions | パーミッション ディレクトリの場合は「drwx——」固定 ファイルの場合、 送信のファイル時には「-r-—r—–」固定 受信のファイル時には「-rw-rw—-」固定 |
atime | アクセス時刻 ACMS Cloudでは更新時刻 |
mtime | 変更時刻 ACMS Cloudでは更新時刻 |
詳細は「draft-ietf-secsh-filexfer-02.txt」『5. File Attributes』と『7. Responses from the Server to the Client』を参照してください
■表示件数
ACMS CloudのSFTPサーバー上にあるファイルは、通信タスクと結びついており、クライアントからリストコマンドが発行されると、ACMS Cloudでは通信タスクを検索し、ファイル一覧を作成します。
そのため、転送ディレクトリに存在するファイル、すなわち通信タスクが多いほど、リストコマンドの応答に時間がかかる挙動になるため、ACMS Cloudでは表示する件数を1024件に制限しています。
9.2.3.7 ファイルの移動/削除
SFTPサーバーはファイルの移動と削除をサポートしています。ただし、実際にデータファイル自体を移動／削除するのではなく、登録されたタスクの情報を変更します。
移動の場合はタスクの「伝送ファイル名」を変更し、削除の場合はタスクの状態を変更してクライアントからはファイルが移動／削除されたように見えます。
ファイルの移動に関しては、そのファイル(タスク)が属する論理ファイル情報で設定された転送ディレクトリの最終階層配下、もしくは、「移動ディレクトリ」配下以外には移動できません。
9.2.3.8 ファイル成立タイミング
ファイル転送の成立タイミングを指定することができます。設定方法については「19.1.1.4 論理ファイルの作成」を参照してください。
■処理の流れと成立タイミング
■ データ転送完了後に即座に通信が切断される場合
一部のクライアント製品において、データ転送が完了すると即座に通信を切断する挙動をとることが確認されており、このような製品との通信において「ファイル転送完了後」のファイル成立が行われない場合があります。
SFTPの通信において、ファイル転送のやり取りはマニュアル「9 ACMS Cloudで利用する各種通信プロトコルの概要（SFTP手順）」「9.1.4 SFTPの通信シーケンス」に示す通り行われます。
ファイル成立が「ファイル転送完了後」の場合、SSH_FXP_CLOSEメッセージを受信した時点でファイル成立とみなします。
しかし一部のクライアント製品では、SSH_FXP_CLOSEメッセージを送信した後、即座に通信を切断します。
このような操作が行われた場合、ACMS ApexはSSH_FXP_CLOSEメッセージを認識できず、ファイル転送が完了しないまま通信が終了したと判断し通信を異常終了とみなしてしまうことがあります。
以下の条件にすべて当てはまる場合、このケースに該当する可能性が高いと判断できます。
- 成立タイミングが転送完了後である
- ログID: CSFS313が出力され、通信タスクが障害となる
- リトライを行っても、同じ障害が何度も発生する
このようなクライアント製品との通信のためには、クローズ要求（SSH_FXP_CLOSE）受信前に通信が切断された場合において、ファイル成立とみなす機能を利用できます。
本機能の設定については、5 付録「プロパティ」の「comm.sftp.server.send.commit.before.close.request」および「comm.sftp.server.receive.commit.before.close.request」を参照してください。
ただしこの機能のご利用に当たり、以下の点にご注意いただく必要があります。
- 本機能を有効とすることにより、クライアントからの切断がファイル転送完了前なのか完了後なのかを判断できないため、クライアントがファイルを完全に送受信していない場合もファイル成立と見なすケースがある。
このような事態を避けるため、運用としてファイル成立を「移動完了後に成立」や「削除完了後に成立」等に変更することをご検討ください。
9.2.3.9 障害復旧と再開
ファイル転送に何らかの障害が発生した場合、ACMS Cloudのタスクは「障害」として登録されます。
障害の原因を取り除いた後、接続相手先から処理を再開させることができます。
9.2.3.10 同一転送ファイル名のタスクについて
SFTPサーバーでは、同一論理ファイル情報でかつ同一転送ファイル名の着信送信タスクが複数存在する場合は、以下の仕様により、処理対象を決定します。
・「未完了」のみ
処理予定日時が最も古いタスクが処理対象となる
・「完了」のみ
処理予定日時が最も新しいタスクが処理対象となる
・「未完了」、「完了」が混在する
処理予定日時が最も古い「未完了」のタスクが処理対象となる
上記仕様により、処理予定日時が過去の未完了タスクから順に処理される仕組みになっています。