web-dev-qa-db-ja.com

sshを介してサーバー上の共有フォルダーのアップロード許可を設定する

Ubuntu Server 17.04を使用して、ヘッドレスホームファイルサーバーをセットアップしました。標準のUbuntu 17.04を実行しているラップトップからSSHを使用してWiFi経由でアクセスします。ホームネットワーク用のファイル（音楽や写真など）を提供するニーズには、SSH（SFTP）で十分であることがわかりました。

ここで、サーバーのハードドライブ/dev/sda1上のフォルダーにファイルをアップロードできるようにしたいと思います。これは現在/media/aとしてマウントされています。 ext4 Linuxファイルシステムを使用し、Sudo mount /dev/sda1 /media/aコマンドを使用してマウントしました。

（ssh username@servernameでログインすることにより）ターミナルからSSHコマンドを実行でき、ラップトップのGUIを介してファイルにアクセスできます（ファイル>他の場所>サーバーに接続> sftp：// username @ servername）。ただし、新しいフォルダを作成しようとすると（たとえば）

新しいフォルダーの作成エラー：許可が拒否されました。

Sudo chmod o=rwx /media/a/uploadでuploadフォルダー（sshセッションで新しく作成された）にアクセス許可を設定しようとしました。ただし、ラップトップのGUIを使用してそこにフォルダーを作成しようとすると、

新しいフォルダーの作成エラー：不明な理由。

ラップトップからサーバーにファイルをアップロードするにはどうすればよいですか？

編集：要求された/etc/ssh/sshd_configファイルの内容は次のとおりです。

#   $OpenBSD: sshd_config,v 1.100 2016/08/15 12:32:04 naddy Exp $

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_Host_rsa_key
#HostKey /etc/ssh/ssh_Host_ecdsa_key
#HostKey /etc/ssh/ssh_Host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need Host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation sandbox
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

# override default of no subsystems
Subsystem   sftp    /usr/lib/openssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#   X11Forwarding no
#   AllowTcpForwarding no
#   PermitTTY no
#   ForceCommand cvs server

EDIT：以下は、コメントで要求されたさまざまなコマンドの出力です

username@servername:~$ findmnt /media/a

TARGET   SOURCE    FSTYPE OPTIONS
/media/a /dev/sdc1 ext4   rw,relatime,data=ordered
username@servername:~$ namei -lx /media/a
f: /media/a
Drwxr-xr-x root root /
drwxr-xr-x root root media
Drwxr-xr-x root root a
username@servername:~$ id
uid=1000(user) gid=1000(user) groups=1000(user),4(adm),24(cdrom),27(Sudo),30(dip),46(plugdev),111(lxd),116(sambashare),117(lpadmin)
username@servername:~$ getfacl /media/a
getfacl: Removing leading '/' from absolute path names
# file: media/a
# owner: root
# group: root
user::rwx
group::r-x
other::r-x

username@servername:~$ mkdir -v /media/a/upload
mkdir: cannot create directory ‘/media/a/upload’: Permission denied
serverpermissionssshshared-folderssftp
1
Ivan

所有されていないフォルダの削除を Davidが示唆する のように制限することは、使用例としては良いアイデアかもしれませんが、それは問題の根本的な原因ではありません。

Chmodのo =スイッチは、全員ではなく他のユーザー（ユーザーでもグループメンバーでもない）を示します。それがあなたの心にあるとは思いません。読み取りと書き込みを設定するには、Sudo chmod u=rwx /media/a/uploadのようにu =スイッチを使用します

もちろん、これは親ディレクトリへの書き込みアクセス権を持っていることを前提としていますが、あなたの質問はそうではないことを示しています。ディレクトリ内にディレクトリを作成するには、ディレクトリへの書き込み権限が必要です。そのため、/ media/a /に対する読み取りおよび実行権限しか持っていないため、mkdir -v /media/a/uploadを使用できません。

アクセス許可は（U）ser（G）roupおよび（O）therに適用されるため、細かなアクセス制御が必要な場合は、ユーザーまたはグループ、またはその両方を現在のroot：root所有権から変更する必要があります。以下のchownの詳細。

ユーザー名がivanで、media/a/uploadディレクトリでのみrwxアクセスが必要な場合は、次のコマンドを発行します。

Sudo chown ivan/media/a/upload（グループステータスは変更されません）またはより一般的に

Sudo chown username:groupname /media/a/upload

に続く

Sudo chmod u=rwx /media/a/upload

他のユーザーは/ media/a /へのx許可を介してアクセスするため、そのディレクトリを横断して/ media/a/upload /の所有権と許可設定を変更できるようにする必要があります。

Chownの詳細については、man chownまたは https://linux.die.net/man/1/chown を参照してください。chmodの詳細については、man chmodまたは https： //en.wikipedia.org/wiki/Chmod または https://linux.die.net/man/1/chmod

ソース：

man chown

man chmod

https://en.wikipedia.org/wiki/Chmod

編集： フォルダーのアクセス許可と所有権の変更 の投稿は、このトピックで非常に詳細になります。

3
Elder Geek

/tmpのような「スティッキー」ディレクトリが必要なようです。このディレクトリでは、書き込みアクセス権を持つすべてのユーザーがエントリを作成できますが、ディレクトリ自体を変更したり、他のユーザーが作成したエントリを削除することはできません。スティッキービットには、8進数のマスク1000またはシンボルtがあります。

「スティッキー」または「制限付き削除」フラグを設定するには：

Sudo chmod +t /media/a

「スティッキー」フラグおよびを設定するには、全員がディレクトリエントリを作成できるようにします。

Sudo chmod a=rwxt /media/a

unlink(2)のマニュアルページ は、エラー状態セクションのディレクトリに対するスティッキーフラグの効果を説明しています。

EPERMまたはEACCES：パス名を含むディレクトリにはスティッキービット（S_ISVTX）が設定されており、プロセスの有効なUIDは削除するファイルのUIDまたはそれを含むディレクトリのUIDではありません、プロセスに特権はありません（Linux：CAP_FOWNER機能はありません）。

こちらもご覧ください

3
David Foerster