SSHシェルアクセスを有効にするが、SFTPアクセスを無効にする


21

この質問に対する実行可能な答えを探しましたが、ほとんどの答えには、なぜそうしないかに関するアドバイスが含まれています。ただし、ここにシナリオと、それが必要な理由があります。

コンソールアプリがあり、各ユーザーの.profileにはアプリの起動コマンドがあり、起動するコマンドの直後に、システムからログアウトする「終了」コマンドがあります。提供されているインターフェイスを介してのみこのコンソールアプリにアクセスできるようにしたいのです。起動時に、アプリはユーザーにアプリを介してアクセスできるクライアントのリストを提示します。各クライアントには独自のデータディレクトリがあります。ユーザーには、アクセスが必要なクライアントのみにアクセスが許可されます。

問題は次のとおりです。ユーザーにSSHアクセスを許可すると、SFTPクライアントを使用してログインできるようになります。これにより、アプリのデータディレクトリに直接アクセスできるようになります。アクセスするべきではないデータディレクトリにアクセスします。

telnet / FTPの組み合わせを使用する場合、これは非常に簡単なことでしたが、インターネット上のどこからでもユーザーにアクセスを許可したいので、SFTPからそれらをシャットダウンする方法を見つけることができませんでした。引き続き、アプリを実行できるシェルへのアクセスを許可します。


8
詳細は忘れてしまいますが、SSHを使用すると、ユーザーがログインするときに単一のコマンドを実行するように制限できると思います。これを設定すると、ユーザーは完全なシェルアクセスを取得できません。ユースケースに役立つかもしれません。(。SSHFSを使ってSFTPアクセスをエミュレートすることが可能である、すべての後だけでは、SFTPを無効に自分のユーザーアカウントがアクセス権を持っているに任意のファイルになってから適度に決定したユーザーを停止することはありません。)
デヴィッド・Z

3
さらに、ユーザーの「chrooting」を検討することもできます。予備のデータアクセスについては、設計上の問題のように見えます
デニスノルテ14

2
.profileそのために使用すると、間違ったソリューションのように聞こえます。ユーザーに代替シェルを設定する方がはるかに理にかなっていると思います。
カスペルド14

3
.profileバイパスするのは簡単なので、トリックを使用してアクセスを制限しないでください。(詳細については私の答えを参照してください)
アレクシトルハモ14

回答:


22

編集:

明らかでない場合、次の回答は、サーバーへのシェルアクセスを持つ人がSFTPを使用するのを防ぐ安全な方法として意図されたものではありません。これは、外部表示から無効にする方法を説明する回答にすぎません。ユーザーレベルのセキュリティに関する議論については、@ cpastおよび@Aleksi Torhamoからの回答を参照してください。セキュリティに重点を置いている場合、この答えは適切ではありません。シンプルなサービスの可視性が焦点である場合、これがあなたの答えです。

元の答えに進みます。


sshd_configのsftpサポートをコメントアウトします(そしてもちろん再起動しますsshd):

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


1
時には、行が可能Subsystem sftp internal-sftp
Kondybas

1
私が持っている Subsystem sftp /usr/libexec/sftp-server しかし、それはトリックをしました。ありがとうございました
sosaisapunk

16
これはもっともらしいことではありません。サーバー上で任意のコマンドを実行できる場合は、sftpサーバー側プログラムを実行できます。インストールされていなくても、長いシェルコマンドとして再実装し、sftpクライアントにsftpの代わりにこのコマンドを送信させることができます。この方法では、sftpの使用が不便になる可能性がありますが、任意のコマンドを実行できるユーザーがこれらのコマンドを使用してファイル転送を行うことを防ぐ方法はありません。
R .. 14

1
@sosaisapunkそれは本当ではありません。ユーザーはを使用してssh user@host command、必要なコマンドを実行できます。これを.profile行うとまったく実行されず、アプリがまったく起動しなくなるためです。彼らは単に言うだけで完全なシェルアクセスを得ることができますssh -t user@host bash。試してみてください。サブシステムは単なるコマンドエイリアスです。以前にsftpを使用できた場合でも、それを使用できます-そして必要な他のコマンド。以下の私の答えを読んでください。
アレクシトルハモ14

1
@sosaisapunk:いいえ、ポイントはsshでこれを行うことができるということですが.profile、セキュリティのためではなく、簡単にバイパスされます。私の答えでは、sshでそれを行う3つの異なる方法をリストしました。要するに、ちょうどからのアプリの呼び出しを移動し.profile、シェルスクリプトのいずれか1)ユーザのシェル2とシェルスクリプトを設定する)適切にマッチした(とシェルスクリプトを設定)ForceCommandsshd_config3)スイッチ、公開鍵認証へと設定シェルスクリプトcommandの中で.ssh/authorized_keys。(また、コメントを通知するために@nameを使用する必要があります)
Aleksi Torhamo

28

他の人が述べたように、無効化sftpは十分ではありません-無制限のsshアクセス権を持つユーザーは、自分のアカウントが表示する権限を持つファイルを表示でき、変更する権限があるものはすべて変更でき、自分が読むことができるものは簡単にダウンロードできます機械。これを行わないようにする唯一の方法は、実際にアクセスを制限することです。また.profile、ユーザーを制限するために依存することも理想的ではありません(編集:Aleksiが彼の答えで述べているように、実際にはバイパスするのは簡単.profileです;こと.profileは、セキュリティではなく、利便性のためであるため、そうではありません)ユーザーを制限することを目的としています。セキュリティを提供するには、以下のようなセキュリティ用に設計されたものを使用してください)。

これを行うには、2つの基本的な方法があります。ファイルのアクセス許可によって制限するか、コンソールアプリのみを実行するように強制することができます。2番目の方法の方が優れています。コンソールアプリに制限する必要があるユーザーをグループに割り当てます(例:)customers。次に、でsshd_config、次の行を追加します。

Match Group customers
ForceCommand /path/to/app

これにより、そのグループのユーザーからのすべての接続がコンソールアプリを開くようになります。sftpサーバーツールなど、他の何も起動できません。また、これは何をやってからそれらを停止し、他のシステムであり、とは違っ.profileので(SSHサーバ自体使用しない、.profileシェルでそれらを制限しForceCommand、シェルを起動伴わない他のことをやって防止します)。また、とは異なり.profile、これはセキュリティに関するものとして設計されています。悪意のあるユーザーがそれを回避するのを防ぐために特別に作られています。

(おそらく劣る)代替案には、コンソールアプリを実行するための新しいユーザーの作成が含まれます。次に、データディレクトリをそのユーザーに制限し、そのユーザーが所有するコンソールアプリを設定u+sし、プログラムに設定します。これはsetuid少しです。つまり、コンソールプログラムを実行する誰かが、プログラムの所有者の権限でそうすることを意味します。そうすれば、ユーザー自身はディレクトリにアクセスできず、プログラムを介してのみアクセスできます。ただし、「このプログラムを実行するだけ」へのすべてのアクセスをForceCommand制限するため、おそらく単に使用する必要があります。


4
ForceCommandSSHポートフォワーディングを妨げないことを追加したいと思います。
nyuszika7h 14

1
実際、依存.profileは「理想的ではない」以上のものです。それは簡単にバイパスされ(詳細については私の回答を参照)、したがって、保護はまったく提供されず、セキュリティの誤った感覚のみが提供されます。
アレクシトルハモ

@AleksiTorhamoああ。私はあなたがそれを迂回できると思ったが、どのように特定されなかった(私は一般にセキュリティを目的としないものは迂回可能であると思う)。方法の詳細をありがとう!
cpast 14

15

.profileセキュリティをまったく提供せず、まったく何も制限しないため、これを実行しようとしないでください!

.profile次のように、sshコマンドラインで実行するコマンドを指定するだけでバイパスできるため、何を入れてもかまいませんssh user@host command。を実行すると、通常のシェルアクセスを取得できますssh -t user@host bash

別の回答で述べたように、sftpサブシステムを無効にしてもまったく役に立ちません。サブシステムは本質的にコマンドの単なるエイリアスであり、を実行することでsftpを通常どおり使用できますsftp -s /path/to/sftp-executable user@host

cpastや一部のコメンターが言っているように、アクセスを制限するには適切なメカニズムを使用する必要があります。あれは、

  • 使用ForceCommandsshd_config
  • パスワードなしのログインを使用command="..."して.ssh/authorized_keys
  • ユーザーのシェルを、ユーザーができることを制限するものに変更します

ノート:

  • command="..." 1つのキーにのみ適用されるため、パスワードまたは別のキーを使用するユーザーのsshログインを制限しません
  • また、ポート転送などを制限することもできます(ポート転送、x11転送、エージェント転送、およびpty割り当ては私が聞いたことがあるものです)
    • AllowTcpForwarding など sshd_config
    • no-port-forwarding など .ssh/authorized_keys
  • 他のデーモン(FTPなど)を実行している場合は、それらがユーザーを許可しないことを確認する必要があります(一部のデーモンはユーザーのシェルに基づいてこの決定を行うため、変更する場合は、これを再確認することをお勧めします)
  • ユーザーのシェルを、必要な処理を行うスクリプトに変更できます。引数なしで実行されるか、またはscript -c 'command-the-user-wanted-to-run'
  • 両方ForceCommandcommand="..."ユーザーのシェルを介してコマンドを実行するので、ユーザーのシェルが例えばに設定されている場合、それらは動作しません。/bin/falseまたは/sbin/nologin

免責事項:私はこの問題の専門家で.profileはありません。そのため、物事は安全ではないと言うことはできますが、私が知らない他の方法には「落とし穴」がないと約束することはできません。約。私の知る限り、彼らは安全ですが、インターネット上で最初に間違いを犯すことはありません。


1
少なくともin でForceCommandパスワードなしログインを強制command=authorized_keys、以前はバイパスされていましたが、それはサーバーのバグによるものです。悪意のあるユーザーに対して安全であることが意図されており、それをバイパスするユーザーは深刻な脆弱性としてカウントされますSSHサーバーで(したがって優先順位の修正です)。あなたが指摘するように、.profile設計によってバイパス可能です。セキュリティ機能とは見なされないため、それをバイパスするユーザーはシェル開発者の観点からは完全に問題ありません。
cpast 14

1
@cpast:ええ、ポートフォワーディングなどの機能の存在を考えていました。つまり、sshがポート転送をForceCommand許可し、アクセスを制限するためだけに使用されていることを知らず、ローカルで接続のみをリッスンし、認証を実行しないデーモンがあった場合、sshユーザーはまだデーモンにアクセスできます。リストした機能は、たとえば次のものです。gitホスティングソリューションは通常無効になっており、マンページには「邪悪な」ものは追加されていませんが、公式の「これはForceCommand安全に使用する方法」ドキュメントもまだ見つかりません。
アレクシトルハモ14

確か~/.profileにユーザーは編集可能であり、セキュリティには役に立たないが、cpastのテクニックをそれを入れて意味のあるものにできます/etc/profileか?UIDを確認して、適切なユーザーに制限することができます。
雛14

1
@chicks:いいえ、まったく同じ問題があります。問題は、ファイルがユーザー編集可能であるということではありません。問題は、両方のファイルを完全にバイパスできることです。これらのファイルはログインシェルにのみ使用されます。ログインシェルは、と言うだけで取得できますssh user@hostが、コマンドを実行するようにsshに指示した場合は、つまり。ssh user@host command-ログインシェルを取得できなくなり、ファイルはまったく変更されません。したがって、sshに追加の引数を指定するだけで、誰かがファイルで作成しようとした制限を簡単にバイパスできます。
アレクシトルハモ14

2
@chicks:また、あなたはcpastを参照していることに気付きました。cpastの答えのメソッドはを使用せず、使用し.profilesshd_config安全である必要があります。彼は.profile、これを行うために使用すべきではない方法としてのみ言及しています。
アレクシトルハモ14

1

グローバルおよびユーザー/グループごとにSSHを有効にし、SFTPを無効にすることができます。

SSH経由でいくつかのgitリポジトリへのアクセスを許可したいので、個人的にこれが必要です。また、不要なシステムを無効にしたいのです。その場合、SFTPは必要ありません。

世界的に

いくつかの方法で、すべてのユーザーのSFTPを無効にできます。

不足しているサブシステム

SSHで使用されるSFTPデーモンは、Subsystemキーワードを使用して構成できます。sshd_config(5)マニュアルから:

Subsystem
        Configures an external subsystem (e.g. file transfer daemon).
        Arguments should be a subsystem name and a command (with optional
        arguments) to execute upon subsystem request.

        The command sftp-server(8) implements the “sftp” file transfer
        subsystem.

        Alternately the name “internal-sftp” implements an in-process
        “sftp” server.  This may simplify configurations using
        ChrootDirectory to force a different filesystem root on clients.

        By default no subsystems are defined.

最後の行は、「sftp」のサブシステムを定義しないで十分であることを示唆しています。

偽りの嘘

SSHで使用されるSFTPデーモンを使用できないものに設定することにより、SFTPを無効にすることもできます。たとえば、「sftp」サブシステムを/bin/false次のように構成します。

Subsystem sftp /bin/false

何かがSFTP経由でログインしようとすると、SSHデーモンは「sftpデーモン」を生成しようとします/bin/false/bin/falseプログラムは、一つのことを行い、それはエラーコードを返すことです。SFTP接続の試行は事実上拒否されます。

ユーザー/グループごと

ユーザー、グループ、またはその他のいくつかの基準ごとにSFTPを無効にすることもできます。

ユーザーに通常のシェルプロンプトを表示させたい場合、これは機能しません。また、シェルにアクセスできる場合はほとんどのものを回避できるため、意味がありません。 特定のプログラムへのアクセスのみを許可する場合にのみ機能します。

マッチング

一連のユーザーを一致させるには、Matchキーワードを使用してSSHを構成できます。sshd_config(5)マニュアルから:

Match
        ...

        The arguments to Match are one or more criteria-pattern pairs or the
        single token All which matches all criteria.  The available criteria
        are User, Group, Host, LocalAddress, LocalPort, and Address.  The
        match patterns may consist of single entries or comma-separated
        lists and may use the wildcard and negation operators described in
        the PATTERNS section of ssh_config(5).

        ...

いくつかの例:

  • Match User eva 「eva」ユーザーに一致
  • Match User stephen,maria 「stephen」および「maria」ユーザーに一致
  • Match Group wheel,adams,simpsons 「wheel」、「adams」、「simpsons」グループに一致

さらに情報が必要な場合は、sshd_config(5)マニュアルに多数の情報が記載されています。

強制コマンド

通常、SSH経由で接続するときにユーザーのログインシェルを取得しますが、特定のコマンドを強制するようにSSHを構成できます。このコマンドは、SFTPを含むすべてのSSH接続に対して強制されるため、必要なコマンドを強制するオプションがある場合があります。

強制するコマンドは、ForceCommandキーワードを使用して構成できます。sshd_config(5)マニュアルから :

ForceCommand
        Forces the execution of the command specified by ForceCommand,
        ignoring any command supplied by the client and ~/.ssh/rc if
        present.  The command is invoked by using the user's login shell
        with the -c option.  This applies to shell, command, or subsystem
        execution.  It is most useful inside a Match block.  The command
        originally supplied by the client is available in the
        SSH_ORIGINAL_COMMAND environment variable.  Specifying a command of
        “internal-sftp” will force the use of an in-process sftp server that
        requires no support files when used with ChrootDirectory.  The
        default is “none”.

したがって、を使用して制約付きコマンドを強制できますForceCommand <your command>。例えば:

Match User kim
        ForceCommand echo 'successful login man, congrats'

gitアクセスを許可したい場合、ユーザーにアクセスできるのはユーザーのみですgit-shell。これは、いくつかのセキュリティオプションとともに、gitユーザーのSFTPを無効にするセクションです。

Match Group git

        # have to do this instead of setting the login shell to `git-shell`,
        # to disable SFTP
        ForceCommand /usr/bin/git-shell -c "$SSH_ORIGINAL_COMMAND"

        # disable stuff we don't need
        AllowAgentForwarding no
        AllowTcpForwarding no
        AllowStreamLocalForwarding no
        PermitOpen none
        PermitTunnel no
        PermitTTY no
        X11Forwarding no

私の場合、特定の認証されたキーに対してのみMySQLアクセス(SFTPアクセスとSSHターミナルウィンドウの両方を禁止)を許可したかった(つまり、sshd_configファイルに変更を加えなかった)。特定のキーに対して次の〜/ .ssh / authorized_keysオプションを使用してこれを行うことができました:command = "/ usr / bin / echo 'MySQLアクセスのみが許可されています。'"、no-pty、no-X11-forwarding、permitopen = "127.0.0.1:3306"
Martin_ATS
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.