web-dev-qa-db-ja.com

ユーザーはchroot後にSFTPを実行できません

Ubuntu 10.04.4 LTS

ユーザー「sam」をchrootしようとしています。そこにあるすべての記事によると、これはうまくいくはずですが、どうやら私はまだ何か間違ったことをしています。

ユーザー：

sam:x:1005:1006::/home/sam:/bin/false

/ etc/ssh/sshd_configを次のように変更しました（ファイルの下部）：

#Subsystem sftp /usr/lib/openssh/sftp-server
# CHROOT JAIL
Subsystem sftp internal-sftp
Match group users
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

ユーザーグループにsamを追加しました。

$groups sam
sam : sam users

Samのホームフォルダーのアクセス許可を変更しました。

$ ls -la /home/sam
drwxr-xr-x 11 root root  4096 Sep 23 16:12 .
drwxr-xr-x  8 root root  4096 Sep 22 16:29 ..
drwxr-xr-x  2 sam  users 4096 Sep 23 16:10 awstats
drwxr-xr-x  3 sam  users 4096 Sep 23 16:10 etc
...
drwxr-xr-x  2 sam  users 4096 Sep 23 16:10 homes
drwxr-x---  3 sam  users 4096 Sep 23 16:10 public_html

Sshを再起動したところ、samはSFTPでログインできません。セッションが作成されますが、すぐに閉じられます：

Sep 24 12:55:15 ... sshd[9917]: Accepted password for sam from  ...
Sep 24 12:55:15 ... sshd[9917]: pam_unix(sshd:session): session opened for user sam  by (uid=0)
Sep 24 12:55:16 ... sshd[9928]: subsystem request for sftp
Sep 24 12:55:17 ... sshd[9917]: pam_unix(sshd:session): session closed for user sam

サイバーダックは言うUnexpected end of sftp stream.および他のクライアントが同様のエラーを出します。

私は何を忘れましたか/何が間違っていますか？

ありがとう！

編集する

OpenSSHメーリングリストに連絡した後でも、それを機能させることができなかったので、サーバー全体をリセットすることにしました（幸い、これは実行可能なオプションでした）。それは今働いています。

sftpchroot
4
Dauntless

ジャウメの答えは非常にいいですが、結局私を助けることができませんでした。 OpenSSHメーリングリストを試しましたが、うまくいきませんでした。私はサーバー全体をリセットすることになりましたが、それでもまだ幸運でした。現在は完全に機能しています。

1
Dauntless

あなたの設定は間違いなく良さそうです。問題がどこにあるかを見つけられるかどうか見てみましょう。

  1. OpenSSHバージョンがChrootDirectoryをサポートしていることを確認してください：

    ChrootDirectoryキーワードのサポートがopenSSHバージョン4.8p1に追加されました（ http://www.debian-administration.org/articles/59 ）。少なくともそのバージョンがインストールされていることを確認します。

    dpkg --list openssh-server

    [ http://releases.ubuntu.com/lucid/ubuntu-10.04.4-server-AMD64.list）によると、これはおそらく原因ではありません openssh -serverのバージョンは5.3p1]です

  2. SFTPをローカルでテストします。

    Ubuntuコンピューターのターミナルに入力します。

    sftp sam@localhost

    ログインできるかどうかを確認します（尋ねられたらsamのパスワードを入力する必要があります）。動作する場合は、Cyber​​duckの構成に問題がある可能性があります。

    ログインできない場合は、chrootなしでSFTPを試してください。

  3. ChrootなしでローカルにSFTPをテストします。

    接頭辞：

    Match group users
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no

    #を使用してコメント化し、sshd（Sudo service ssh restart）を再起動して、次のように入力します。

    sftp sam@localhost

    プロンプトが表示されたらパスワードを入力し、ログインできるかどうかを確認します。ログインできる場合は、次のようにchroot構成のトラブルシューティングを行います。詳細な出力を表示するには、コマンドsftp -vvv sam@localhostを使用してステップ2を再試行します。 LogLevel VERBOSEを/etc/ssh/sshd_configに追加してsshdを再起動することにより、sshdのログレベルを上げることもできます。うまくいけば、コンソールまたは/var/log/auth.logに明らかなものが表示されます。

    ログインできない場合は、SSHを試してください。

  4. ローカルでSSHをテストします。

    SFTPには有効なSSHが必要なので、samのシェルを/ bin/bashに変更します。

    Sudo usermod -s /bin/bash sam

    そして試してください：

    ssh sam@localhost

    尋ねられたら、samのパスワードを入力します。ログインできる場合は、3）で説明されているように詳細度を上げて問題を見つけてください（sftp -vvv sam@localhostのLogLevel VERBOSEおよび/etc/ssh/sshd_config）。別の可能性は、シェルの初期化がsftpクライアントを混乱させることです（ http://www.openssh.org/faq.html#2.9 ）：

    2.9-接続時にsftp/scpが失敗しますが、sshは問題ありません。

    非インタラクティブセッションの出力を生成するシェルの初期化（.profile、.bashrc、.cshrcなど）がある場合、接続時にsftpやscpが失敗する可能性があります。この出力は、sftp/scpクライアントを混乱させます。シェルがこれを実行しているかどうかを確認するには、次のコマンドを実行します。

    ssh yourhost /usr/bin/true

    上記のコマンドで出力が生成された場合は、シェルの初期化を変更する必要があります。

    ログインできない場合は、ssh root@localhostをお試しください。どちらも動作しない場合は、サーバーのsshdに問題があります。冗長性を増やし（LogLevel VERBOSEの/etc/ssh/sshd_config）、sshdを再起動して/var/log/auth.logを熟読してください。答えはおそらくそこにあります。

3
jaume

Centos 7-私は同じ問題を抱えていました-私はそれを診断するためにSunの下ですべてを試しました-最終的に '/ etc/ssh/sshd_conf'のsftpサブシステムを変更し、sshd（service sshd restart）と問題が修正されました：

から：

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

へ：

Subsystem sftp internal-sftp

なぜ2つの実装が提供されるのかわかりません

2
bryan hunt

同じ問題があり、chroot-dirを所有者ルートとグループルートに設定することで解決しました。

chown root:root chroot-dir

1
Genesio