web-dev-qa-db-ja.com

ユーザーはSFTP経由で/ var / www / html /に接続できません

AmazonにLAMPとWordPressサイトを実行しているUbuntuサーバーがあります。FTPクライアントからSFTPプロトコルを介して/var/www/html/site/に接続するftpuserというユーザーを作成しました。 。

  1. SSHキーを作成しましたが、ユーザーは自分の/home/ftpuser/フォルダーに接続します。

  2. 設定しました

    usermod -m -d /var/www/html/site/ ftpuser

  3. /home/ftpuser/.ssh/を/var/www/html/siteにコピーしました。所有権をftpuserに設定しました。

  4. ftpuserをwww-dataグループに追加しました。

しかし、それは私にはうまくいきません。 FTPユーザーは接続すらしません。ユーザーは実際には、ユーザーの最初のホームディレクトリにのみ接続します。

/var/www/html/site/の所有権をftpuserに変更する必要がありますが、この場合、www-dataが実行するように設定されているため、WordPressサイトは機能しなくなりますApache、または私は間違っていますか？

いくつかのマニュアルでは、次のように述べています。

chmod ug+w /var/www/html/site/
chmod g+s /var/www/html/site/
setfacl -d -m g::rwx /var/www/html/site/

それが私に役立つかどうかはわかりません。ディレクトリを誤って構成して、動作中のWebサイトを停止したくありません。

何か助けてください？ディレクトリに関するいくつかの情報は次のとおりです。

ls -l /var/www/html/
drwxr-xr-x 12 www-data www-data 4096 Jan 29 13:16 site

ls -al /var/www/html/site/
drwx-w----  2 ftpuser  www-data  4096 Jan 29 13:16 .ssh

ls -l /var/www/html/site/.ssh/
-rw-r--r-- 1 ftpuser www-data  407 Jan 29 13:16 authorized_keys
-rw------- 1 ftpuser www-data 1675 Jan 29 13:16 id_rsa
-rw-r--r-- 1 ftpuser www-data  406 Jan 29 13:16 id_rsa.pub

getfacl /var/www/html/site/
getfacl: Removing leading '/' from absolute path names
# file: var/www/html/site/
# owner: www-data
# group: www-data
user::rwx
group::r-x
other::r-x

getfacl /var/www/html/site/.ssh/
getfacl: Removing leading '/' from absolute path names
# file: var/www/html/site/.ssh/
# owner: ftpuser
# group: www-data
user::rwx
group::-w-
other::---

解決しました。私の場合、私もしなければなりませんでした：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
linuxubuntusshftpsftp
2
Jake W.

まず、「FTPユーザーは接続すらしません」と言います。ユーザーがConnection timed outのようなエラーを受け取っている場合は、ファイアウォール/ iptablesに問題がある可能性が高いため、最初にそれを修正する必要があります。 SFTPはSSHと同じTCPポートを使用します：デフォルトでは22です。

次に、セキュリティ上の理由から、通常のユーザーのホームディレクトリは通常、ユーザー自身（通常の場合）またはroot（特別な目的のユーザーの場合）のいずれかによって所有されます。また、ホームディレクトリにアクセスするには、ユーザーは、ルートに至るまで、ホームディレクトリのすべての（グランド）親ディレクトリに対する少なくともx（ディレクトリアクセス）権限を持っている必要があります。これらの要件が満たされていない場合、sshdは不正なプレイを想定し、そのユーザーのログイン（シェルおよびSFTP）を許可しない可能性があります。 SFTPクライアントがサーバーのホストキーを正常に受信したが、その後切断された場合は、これが発生している可能性があります。

sshdでは、ユーザーのホームディレクトリ、ルートディレクトリに至るまでの（グランド）親ディレクトリ、.sshサブディレクトリ、およびその中のauthorized_keysファイルが他のユーザーによって書き込み不可であるか、sshdである必要があります。 「許可されたキー」は別の悪意のあるユーザーによって挿入されたものと見なされ、それらを信頼しません。ユーザーのホームディレクトリをHTTPサーバーのサブツリーの中央に配置すると、これらの要件を満たすことがより困難になる可能性があります。

システムでSELinuxまたはその他の追加のセキュリティ対策が有効になっている場合、ユーザーのホームディレクトリを非標準の場所に配置しようとすると、追加の手順が必要になる場合があります。一般に、サイトの実際の場所を指すftpuserのホームディレクトリへのシンボリックリンクを作成する方がはるかに簡単です。ユーザーは1つのサブディレクトリを処理する必要がありますが、通常はそれで問題ありません。

最初に、ユーザーのホームディレクトリの場所を通常の場所に復元することをお勧めします。

usermod -d /home/ftpuser ftpuser

次に、シンボリックリンクを作成します。

ln -s /var/www/html/site /home/ftpuser/site

次に、テストを開始します。まず、FTPユーザーに少なくとも接続してもらいます。サーバーのログをチェックして、ネットワーク接続が確立されているかどうかを確認します。次に、SSHキー認証が機能することを確認します。その後、ファイルのアクセス許可について心配する時が来ました。それらについて別の質問を書く方が良いかもしれません。

また、ftpuserにWebサイトのコンテンツのみを表示させ、システムの他の部分は表示させない場合、これは特殊なケースです。これはchrootされたSFTPアカウントであり、バージョンに応じていくつかの追加要件があります。システムで使用されるsshdの。 ftpuserを標準のホームディレクトリにジェイルし、bind mountを使用してジェイル内でサイトにアクセスできるようにする方が簡単な場合があります。

mkdir /home/ftpuser/site  #empty directory for a mount point
mount -o bind,rw /var/www/html/site /home/ftpuser/site

シンボリックリンクと同様に、これはftpuserがサイトディレクトリをホームディレクトリのサブディレクトリとして「見る」ためのchroot互換の別の方法です。サイトの操作にはまったく影響しません。

（シンボリックリンクは、chroot jailの内部から外部の世界を指すことはできませんが、バインドマウントにより、jail内で他のファイルシステムの一部にアクセスできるようになります。）

Root以外のユーザーが管理するWebサイトのディレクトリツリーを設定する場合、考慮すべきアクセスカテゴリがいくつかある可能性があります。

  • a）Webサーバーとメンテナの両方が読み取り可能であるが、どちらも変更できないディレクトリとファイル。これには、特権CGIスクリプトまたはサイトのインフラストラクチャの他の同様の部分が含まれる場合があります。
  • b）サイトのメンテナが変更可能で、Webサーバーのみが読み取り可能にするディレクトリとファイル：これは、侵入者が新しいWordPress脆弱性またはその他の攻撃ベクトル。
  • c）WordPressおよび/またはWebサーバーの一部として実行されている他のプロセス、およびサイトのメンテナによって変更可能である必要があるディレクトリとファイル。これは本質的にWordPressであり、すべてのコンテンツはそれによって管理されます。
  • d）WordPress のみによって変更可能なディレクトリとファイル。デフォルトでは、WordPressは、データベースファイルがこのように保護されていることを自動的に確認します。

カテゴリa）とb）のファイルとディレクトリは簡単です。それらは任意のユーザー/グループによって所有できます以外www-data。唯一の要件は、それらがwww-dataユーザーによって読み取り可能であるということであり、誰でも読み取り可能/アクセス可能な許可ビットがそれをカバーします。

カテゴリa）のファイルとディレクトリは、ユーザーroot、グループrootが所有し、通常のファイルの場合は-rw-r--r--、実行可能ファイルの場合は-rwxr-xr-x、ディレクトリの場合はdrwxr-xr-xなどの権限を持っている可能性があります。

サイトにカテゴリb）のファイルが含まれている場合は、2番目のグループwwwadminを作成し、ftpuserもそのグループのメンバーにすることができます。このグループでは、ユーザーwww-dataがメンバーではないことが重要です。

カテゴリb）のファイルとディレクトリは、ユーザーftpuser（または誰でも）、グループwwwadmin、および通常のファイルの場合は-rw-rw-r--、実行可能ファイルの場合は-rwxrwxr-x、ディレクトリの場合はdrwxrwxr-xによって所有されます。

Apacheがwww-dataserとして実行されている場合、WordPressやその他のサイトコンポーネントによって作成された新しいファイルは、ユーザーwww-data、グループwww-dataによって所有されます。 ftpuserはすでにwww-dataグループのメンバーであるため、カテゴリc）ですべてのファイルに基本的なアクセス許可rw-rw-r--とディレクトリのアクセス許可drwxrwxr-xがあることを確認するだけで済みます。つまり、www-dataが所有するすべてのファイルにグループ書き込み権限を追加し、umask 002を使用するようにApacheやWordPressを構成することを意味します。 Ubuntuでは、Apacheのumaskは/etc/Apache2/envvarsファイルで設定できると思います。 WordPressはWebサーバーのデフォルトのumaskを上書きする可能性があるため、個別に構成する必要がある場合があります。

www-dataグループが所有するすべてのファイルとディレクトリに適切なグループアクセス許可を与えるには、次のコマンドを実行します。

find /var/www/html/site -group www-data -exec chmod g+rwX {} \+

www-dataユーザーが所有するすべてのディレクトリにsetgid権限ビットを追加して、それらに追加されたすべての新しいファイルとサブディレクトリが、のプライマリグループでなくても自動的にwww-dataグループによって所有されるようにすることもできます。ファイル/ディレクトリを追加するユーザー：

find /var/www/html/site -type d -group www-data -exec chmod g+s {} \+

これにより、グループの権限drwxrwxr-xがdrwxrwsr-xに変更され、新しいファイルを追加した後にftpuserが手動でchgrp www-dataを使用する必要がなくなります。

umaskのデフォルトのftpuser設定を002に変更すると（まだ変更されていない場合）、それらが作成する新しいファイルには、デフォルトでグループ書き込みアクセス権があります。これは、カテゴリc）ファイルを変更するときに役立ち、通常のUbuntuの他のファイルを傷つけることはありません。もちろん、SFTPクライアントは、ファイルを転送するときにファイルの既存のアクセス許可を維持しようとする場合があります。これには、クライアント側での調整が必要になる場合があります。

ftpuserがカテゴリd）のファイルを操作できるようにする場合、ユーザーは、ファイルが存在するディレクトリへの書き込みアクセス権があり、ファイルが読み取り可能である限り、いつでもファイルの所有権を取得できることを知っておく必要があります。ファイルのコピーを作成してから、元のファイルを削除します。

3
telcoM