web-dev-qa-db-ja.com

パスワードなし（SSH提供）SFTPを機能させることができません

私は以下のようにsftpセットアップをchrootしました。

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_Host_rsa_key
HostKey /etc/ssh/ssh_Host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin without-password
StrictModes yes
AllowGroups admins clients

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

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

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

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

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

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

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

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

#Subsystem sftp /usr/lib/openssh/sftp-server

# 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



Subsystem sftp internal-sftp

Match group clients
    ChrootDirectory /var/chroot-home
    X11Forwarding no
    AllowTcpForwarding no
    ForceCommand internal-sftp

ダミーユーザー

root:~# tail -n1 /etc/passwd
david:x:1000:1001::/david:/bin/sh

この場合、davidはたとえばfilezillaクライアントを使用してsftpでき、/ var/chroot-home/david /にchrootされます。しかし、パスワードなしの認証を設定した場合はどうなりますか？彼のキーを/var/chroot-home/david/.ssh/authorized_keysに貼り付けようとしましたが、役に立たず、davidとしてボックスにsshを実行しようとしましたが、入力後に「debug1：Sending env LC_CTYPE = C」で停止します。パスワードで、auth.logに何も表示されないのは、homedirが見つからないことが原因である可能性があります。ルートとして「su--david」を実行すると、「ディレクトリがありません。HOME= /でログインします」という意味があります。シンボリックリンクも役に立ちません。

私も試しました：

Match group clients
        ChrootDirectory /var/chroot-home/%u
        X11Forwarding no
        AllowTcpForwarding no
        ForceCommand internal-sftp

ダミーユーザー

root:~# tail -n1 /etc/passwd
david:x:1000:1001::/var/chroot-home/david:/bin/sh

このように、/ var/chroot-home/davidをroot：rootに変更しないと、sshdは所有権や権限のモードが悪いと文句を言います。変更すると、davidはsftpを使用しているときに自宅に直接アップロード/削除できなくなります。 filezilla。

linuxsshdebiansftp
3
Shoaibi

まず、/etc/passwdのホームディレクトリは、chrootされていないパスを反映している必要があります。そうしないと、一般的に問題が発生します。この場合、sshdはchrootする前に許可されたキーをチェックするため、chrootされていないパスを使用してそれらを見つける必要があります。そのため、最初の試行は機能しません。

2番目に注意すること：最初の設定では、davidがログインすると/var/chroot-home/davidで開始しますが、実際には/var/chroot-homeにchrootされています。つまり、cd ..と入力すると、すべての他のホームdir（権限が正しければ内容は異なりますが）。これはあなたにとって問題かもしれないし、そうでないかもしれませんが、知っておくのは良いことです。

上記で問題がない場合は、最初のsshd_configを使用して、davidのホームディレクトリをpasswdファイルの/var/chroot-home/davidに設定し、次のシンボリックリンクを追加して、davidが引き続きホームディレクトリで起動するようにします。

cd /var/chroot-home
mkdir var
ln -s .. var/chroot-home

そのシンボリックリンクにより、chrootにいるかどうかに関係なく、同じパスを使用してホームディレクトリにアクセスできるようになります。

ただし、クライアントに互いのホームディレクトリの名前を表示させたくない場合は、2番目のソリューションのように、ホームディレクトリ自体にchrootする必要があります。しかし、これまで見てきたように、sshdはそれを好みません（さまざまな微妙な理由から、ユーザーにファイルシステムのルートへの書き込みアクセスを許可するのは危険です）。悲しいことに、あなたはここでほとんど運が悪いです。これに対する1つの（厄介な）解決策は、各ホームディレクトリにfiles/サブディレクトリを作成し、代わりにクライアントにそのサブディレクトリへの書き込みアクセス権を与えることです。

別のオプションは、とにかく/ var/chroot-homeにchrootし、ホームディレクトリに別の名前を付けることです。名前の代わりにユーザーID番号を使用します。

6
Jander

私はこれを使用してこの問題を解決しました：

AuthorizedKeysFile /sftp/%u/.ssh/authorized_keys

ここで、％uはロギングしているchRootedユーザーです。

Match Group sftp
   ChrootDirectory /sftp/%u
2
Carlos Lande

.sshとauthorized_keysのファイル権限を確認しましたか？

drwx------   .ssh/                   (chmod 0700)
-rw-------   .ssh/authorized_keys    (chomd 0600)

当たり前のことかもしれませんが、見落とされることもあります。

1
Jeff Bauer

ユーザーのchrootホーム（/ var/chroot-home/david/incomingなど）にサブディレクトリを作成してからchown david:clients incomingを作成し、chmod 755 incomingで適切な権限を付与する必要があります。

詳細については、 この投稿 を参照してください。

.ssh/authorized_keysファイルを保存するためにchrootホーム（上記のように）だけでなく実際のホーム（/ home/david）も作成する必要があることがわかりました。これは、SSH認証がchrootの前に行われるため、sshdがそこで.sshファイルを探すことを知らないためだと思います。

今考えてみると、実際のホームディレクトリをchrootホームとして使用して再試行する可能性があります。それでもincomingフォルダを作成する必要がありますが、少なくとも.sshは期待どおりの場所になります。

0
gravyface