要約：この記事では、シェルを恐れないシステム管理者やプログラマーの生活を大幅に簡素化できる高度なOpenSSH機能について説明しています。 キーと-L / D / Rオプションは何も説明していないほとんどのマニュアルとは異なり、私はsshが持っているすべての興味深い機能と便利さを集めようとしました。



警告：投稿は非常にボリュームがありますが、使いやすさのために、断片に分割しないことにしました。



目次：

• キー管理
• ssh経由でファイルをコピーする
• 入力/出力ストリームの転送
• SSH経由でリモートFSをマウント
• リモートコード実行
• .ssh / configの接続のエイリアスとオプション
• デフォルトのオプション
• Xサーバー転送
• socks-proxyとしてのssh
• ポート転送-フォワードとリバース
• リバースソックスプロキシ
• トンネリングL2 / L3トラフィック
• 認証エージェントの転送
• 信頼されていないサーバーを介してsshを介してsshをトンネリングする（ ほとんどの場合、これを知らない ）

キー管理

簡単に言うと、sshはパスワードではなくキーでログインできます。 キーは、開いた部分と閉じた部分で構成されます。 開いているものはユーザーのホームディレクトリに配置され、それによってサーバーに移動します。閉じられたものはユーザーのホームディレクトリに配置され、そこからリモートサーバーに移動します。 半分を比較し（誇張します）、すべてが問題なければ-彼らはそれを手放します。 重要：サーバー上のクライアントだけでなく、クライアントに関連するサーバーも承認されます（つまり、サーバーは独自のキーを持っています）。 パスワードと比較したキーの主な特徴は、サーバーに侵入することで「盗む」ことができないことです。キーはクライアントからサーバーに送信されず、認証中にクライアントはサーバーにキーを所有していることを証明します（同じ暗号マジック）。

キー生成

ssh-keygenコマンドを使用してキーを生成できます。 パラメータを設定しない場合、必要なすべてが保存されます。



キーはパスワードでロックできます。 このパスワード（従来のグラフィカルインターフェイス）は一度要求され、しばらく保存されます。 パスワードが空の場合、使用時にパスワードは要求されません。 忘れたパスワードを回復することはできません。



ssh-keygen -pコマンドを使用して、キーのパスワードを変更できます。

キー構造

（デフォルトで場所に関する質問に回答した場合）。

〜/ .ssh / id_rsa.pub-公開キー。 アクセスする必要があるサーバーにコピーされます。

〜/ .ssh / id_rsa-秘密鍵。 誰にも見せてはいけません。 pubの代わりにコピーしてメッセージ/チャットに貼り付ける場合は、新しいキーを生成する必要があります。 （冗談ではありません。id_rsaポストにsshキーを与えるように求められる人々の約10％、およびこれらの10％の100％は男性です）。

サーバーにキーをコピー

ログインするユーザーディレクトリで〜/ .ssh / authorized_keysファイルを作成し、そこに公開キーを配置すると、パスワードなしで入力できます。 ファイルのアクセス許可では、許可されていないユーザーがこのファイルに書き込むことを許可しないでください。許可しない場合、sshはそれを受け入れません。 キーの最後のフィールドはuser @ machineです。 これは認証とは関係なく、キーがどこにあるかを判断するためだけに便利です。 このフィールドは、キー構造に違反することなく変更（または削除）できることに注意してください。



ユーザーのパスワードがわかっている場合、プロセスを簡素化できます。 ssh-copy-id user @ serverコマンドを使用すると、ファイルを手動で編集せずにキーをコピーできます。



注：古いsshマニュアルにはauthorized_keys2が記載されています。 理由：sshの最初のバージョンがあり、次に2番目（現在）のバージョンがあり、独自の構成セットを作成したため、すべての人にとって非常に疲れていました。2番目のバージョンは「2」のないバージョンに切り替わりました。 つまり、常にauthorized_keysであり、異なるバージョンについては考えません。



非標準ポートでsshを使用している場合、ssh-copy-idを使用する場合は特別なトリックが必要です： ssh-copy-id '-p 443 user@server'



（引用符に注意）。

サーバーキー

サーバーに初めてアクセスするとき、sshはキーを信頼するかどうかを尋ねます。 noと答えると、接続は閉じられます。 その場合、キーは〜/ .ssh / known_hostsファイルに保存されます 。 どのキーが不可能であるかを調べます（セキュリティではないため）。



サーバーキーが変更された場合（たとえば、サーバーが再インストールされた場合）、sshは偽のキーを叫ぶ。 サーバーに触れずにsshと叫ぶと、間違ったサーバーに侵入していることに注意してください（たとえば、同じIPを持つ別のコンピューターがネットワークに登場しました。これは、世界中に数百万ある192.168.1.1のすべての種類のローカルネットワークに特に当てはまります） 。 「悪意のある中間者攻撃」のシナリオは、IPのエラーだけではなく、「すべてが正常」であり、キーが変更された場合、これはパラノイアのレベルを数レベル上げる機会です（また、キーによる認証とサーバーが突然パスワードを求められた場合） -その後、パラノイアを100％オンにし、パスワードを入力しないでください。



既知のサーバーキーを削除するには、 ssh-keygen -R serverコマンドを使用します 。 この場合、IPキーも削除する必要があります（これらは個別に保存されます）： ssh-keygen -R 127.0.0.1



サーバーキーは/ etc / ssh / ssh_host_rsa_keyおよび/etc/ssh/ssh_host_rsa_key.pubに保存されます 。 次のいずれかです。

a）古いサーバーから新しいサーバーにコピーします。

b）ssh-keygenを使用して生成します。 パスワードを設定する必要はありません（つまり、空です）。 sshサーバーはパスワードキーを使用できません。



サーバーを複製する場合（たとえば、仮想マシン内）、サーバーのsshキーを再生成する必要があることに注意してください。



know_hostsから古いキーを削除することをお勧めします。そうしないと、sshは重複キーを誓います。

---

ファイルをコピーする

ファイルをサーバーに転送するのは面倒な場合があります。 sftpやその他の奇妙なことに煩わされることに加えて、sshはsshセッションを通じてファイルをコピーするscpコマンドを提供します。



scp path/myfile user@8.8.8.8:/full/path/to/new/location/









逆も可能です。

scp user@8.8.8.8:/full/path/to/file /path/to/put/here









魚の警告：mcがssh接続を実行できるという事実にもかかわらず、大きなファイルをコピーするのは非常に苦痛です。 fish（仮想fsと同様にsshを操作するためのmcモジュール）は非常に遅いです。 100-200kb-限界、それから忍耐力のテストが始まります。 （私は、scpを知らずに、魚からmcに〜5GBをコピーし、FastEthernetで12時間強かかった、非常に若い頃のことを思い出しました）。



コピーする機能は素晴らしいです。 しかし、私は「名前を付けて保存」したい-とすぐにサーバーに。 そして、特別なプログラムからではなく、使い慣れたプログラムからグラフィカルモードでコピーするため。



できること：

sshfs

理論：fuseモジュールを使用すると、カーネルからファイルシステムへの要求を「エクスポート」して、対応するプログラムのユーザー空間に戻すことができます。 これにより、「疑似ファイルシステム」を簡単に実装できます。 たとえば、sshを介してリモートファイルシステムへのアクセスを提供して、すべてのローカルアプリケーション（例外はほとんどない）が何も疑わないようにすることができます。



実際、例外：O_DIRECTは残念ながらサポートされていません（これはsshfsの問題ではなく、一般的なヒューズの問題です）。



使用法：sshfsパッケージをインストールします（それ自体が融合します）。



実際、desunote.ru（自宅のコンピューターにあります-写真はこの記事で示しています）をラップトップにマウントするスクリプトの例です。

 ＃！/ bin / bash
 sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect

ファイル+ xを作成し、それを呼び出し、任意のアプリケーションに移動して、保存して次のように表示します。







重要なsshfsオプションは次のとおりです。-o reconnect（エラーの代わりに再接続を試みます）。



ルートからのデータで多くの作業をする場合、idmapを行う（必要とする）ことができます：



-o idmap = user 。 pupkin @ serverユーザーとして接続し、vasiliyユーザーとしてローカルで作業する場合、「pupkinファイルはvasiliyファイルであると仮定します」と言います。 まあ、またはルートとして接続する場合は「ルート」。



私の場合、ユーザー名（ローカルとリモート）が同じであるため、idmapは必要ありません。



sshキー（記事の冒頭を参照）がある場合にのみ動作することに注意してください。そうでない場合、パスワード認証は2〜3接続をプッシュします。



fusermount -u / pathコマンドを使用して接続を切断できますが、接続がスティッキーな場合（たとえば、ネットワークがない場合）、ルートの下からこれを行うことができます/必要があります：sudo umount -f / path。

---

リモートコード実行

sshはリモートサーバーでコマンドを実行し、そこで接続を閉じることができます。 最も簡単な例：



ssh user@server ls /etc/









サーバー上の/ etc /の内容が表示され、ローカルコマンドラインが作成されます。



一部のアプリケーションでは、制御端末が必要です。 これらは、-tオプションで実行する必要があります。

ssh user@server -t remove_command









ところで、次のようなことができます。

ssh user@server cat /some/file|awk '{print $2}' |local_app









これにより、次の機能を使用できます。

フォワードstdin / out

プログラムにリモートでリクエストを行い、その出力をローカルファイルに配置するとします。



ssh user@8.8.8.8 command> my_file



ローカル出力をリモートに置きたいとしましょう



mycommand | scp-user@8.8.8.8：/パス/ remote_file



例を複雑にしましょう-サーバーからサーバーにファイルをアップロードできます：10.1.1.2にstdinを置くチェーンを作成しますが、外部からはアクセスできません。



mycommand | ssh user@8.8.8.8 "scp-user@10.1.1.2：/ path / to / file"



pipe'aの使用には、このような不可解なトリックもあります（livejournalのコメントで親切に提案されています）。



tar -c * | ssh user@server "cd && tar -x"









tarはファイルをローカルでマスクしてパックし、stdoutに書き込みます。sshはそれらを読み取り、リモートサーバー上のstdinに渡します。cdはそれらを無視し（stdinは読み取らない）、tarはそれらを読み取り、アンパックします。 つまり、scpは貧しい人々のためのものです。

エイリアス

率直に言って、最近まで私はそれを知らず、使用しませんでした。 彼らは非常に快適であることが判明しました。



多かれ少なかれ大企業では、サーバー名がspb-MX-i3.extrt.int.company.netのように見えることがよくあります。 そして、そこにいるユーザーは、ローカルのものと同等ではありません。 つまり、次のようにログインする必要があります：ssh ivanov_i@spb-MX-i3.extrt.int.company.net。 入力するたびに-あなたは十分なトンネル症候群を取得しません。 小さな会社では、問題は正反対です-DNSについて誰も考えず、サーバーへのアクセスは次のようになります：ssh root@192.168.1.4。 要するに、まだ迷惑です。 非標準のポートと、たとえばsshの最初のバージョン（helloからtsiskamまで）がある場合は、さらにドラマになります。 次に、すべてが次のようになります：ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net。 チョークで。 私はドラマの話をscpでさえしたくありません。



IP（/ etc / hosts）のシステム全体のエイリアスを登録することは可能ですが、これは曲がった出力です（ユーザーとオプションはともかく印刷されます）。 もっと短い方法があります。



〜/ .ssh / configファイルを使用すると、サーバー固有のパラメーターを含む接続パラメーターを設定できます。これは最も重要であり、サーバーごとに異なるパラメーターがあります。 以下に設定例を示します。

ホストric
        ホスト名ooh-horn-and-hoofs.rf
        ユーザー管理者
         ForwardX11はい
        圧縮はい
ホストホーム
        ホスト名myhome.dyndns.org
        ユーザーvasya
        パスワード認証

使用可能なすべてのオプションは、 man ssh_configで確認できます（sshd_configと混同しないでください）。

---

デフォルトのオプション

UUSERプロンプトで：Host *構文を使用して、デフォルトの接続設定を指定できます。例：

ホスト*
ユーザールート
圧縮はい

/ etc / ssh / ssh_config（/ etc / ssh / ssh d _configと混同しないでください）でも同じことができますが、これにはルート権限が必要であり、すべてのユーザーに適用されます。

---

Xサーバー転送

実際、上記の設定例でこの部分を少し設定しました。 ForwardX11はまさにそれです。



理論：Unixグラフィックアプリケーションは通常Xサーバーを使用します（waylandは準備中ですが、まだ準備ができていません）。 これは、アプリケーションが起動し、描画のためにXサーバーに接続することを意味します。 つまり、GUIのない​​ベアサーバーとローカルのXサーバー（作業場所）がある場合は、サーバーからのアプリケーションをデスクトップに描画できるようにすることができます。 通常、リモートXサーバーに接続することは、最も安全で簡単なことではありません。 SSHはこのプロセスを簡素化し、完全に安全にします。 また、トラフィックを取得する機能により、より少ないトラフィックで処理できます（つまり、チャネル使用率を削減、つまりping（正確にはレイテンシー）を削減、つまり遅延を削減）。



キー：-X-Xサーバーを転送します。 -Y転送許可。



ssh -XYC user @ SERVERの組み合わせを覚えておいてください。

上記の例（会社名は架空のものです）では、サーバーooh-horn-and-hoofs.rfに接続しますが、そのようなものではなく、Windowsサーバーにアクセスすることを目標にしています。 私たちは皆 、ネットワークでの作業中にマイクロソフトのセキュリティを知っているので、裸のRDPを出すのは不快です。 代わりに、sshを介してサーバーに接続し、そこでrdesktopコマンドを実行します。

ssh ric

rdesktop -k en-us 192.168.1.1 -g 1900x1200









そして奇跡、デスクトップ上のウィンドウのログインウィンドウ。 慎重に暗号化され、通常のsshトラフィックと区別できないことに注意してください。

---

ソックスプロキシ

次のホテル（カフェ、会議室）にいると、ローカルのwifiがひどいことになります-閉じたポート、どのレベルのセキュリティかはわかりません。 はい、他の人のアクセスポイントへの信頼はそれほどではありません（これは妄想ではありません。近くのカフェの名前を持つすべての人に3Gを配布する（そしてその過程で興味深いことを書く）普通のラップトップを使用してパスワードとCookieが削除されるのをよく見ました）。



ポートが閉じていると、特定の問題が発生します。 ジャバーがカバーされ、次にIMAP、次に何かがカバーされます。



通常のVPN（pptp、l2tp、openvpn）は、このような状況では機能しません-単に通過しません。 443rdポートは、ほとんどの場合CONNECTモードのままであることが実験的に知られています。つまり、「そのまま」渡されます（通常のhttpはsquidで透過的にラップできます）。



ソリューションはsocks-proxy sshモードです。 その原則：sshクライアントはサーバーに接続し、ローカルでリッスンします。 リクエストを受信した後、（オープン接続を介して）サーバーに送信し、サーバーはリクエストに従って接続を確立し、すべてのデータをsshクライアントに転送します。 そして、彼は申請者に答えます。 動作するには、アプリケーションに「ソックスプロキシを使用する」ように指示する必要があります。 そして、プロキシのIPアドレスを指定します。 sshの場合、これはほとんどの場合localhostです（したがって、見知らぬ人にチャンネルを渡すことはありません）。



sock-proxy接続は次のようになります。

 ssh -D 8080ユーザー@サーバー

他の人のwifiはしばしばイチジクだけでなく遅れているという事実のために、-Cオプション（トラフィックを圧縮する）を有効にすると良いかもしれません。 それはほとんどオペラターボであることがわかります（写真だけが押されません）。 HTTPでの実際のサーフィンでは、約2〜3回クリックします（64kbitの災害が発生した場合、40分ではなく40秒でメガバイトのページを開くことができます。それは良いことですが、すべてが優れています）。 しかし、最も重要なのは、盗まれたCookieや傍受されたセッションがないことです。



閉じられた港については何も言わなかった。 22番目のポートは、ジャバーの「不要な」ポートとまったく同じように閉じられます。 解決策は、ポート443でサーバーをハングアップすることです。 22から写真を撮る価値はありませんが、DPI（ディープパケットインスペクション）を備えたシステムで、「擬似ssl」が手放せない場合があります。



これは私の設定のようです：



/ etc / ssh / sshd_config：

（フラグメント）

ポート22

ポート443



そして、これはラップトップからのvpnを説明する〜/ .ssh / configの一部です

ホストVPN
    ホスト名desunote.ru
    ユーザーvasya
    圧縮はい
     DynamicForward 127.1：8080
    ポート443

（localhostを書く「怠yな」形式-127.1に注意してください。これは127.0.0.1を書くための非常に正当な方法です）

---

ポート転送

SSH機能の理解が非常に難しい部分に移ります。これにより、「サーバーから」および「サーバーへ」のTCPトンネリング操作が不可解になります。



状況を理解するために、以下のすべての例ではこの図を参照します。







コメント：2つの灰色のネットワーク。 最初のネットワークは典型的なオフィスネットワーク（NAT）に似ており、2番目はゲートウェイです。つまり、白いインターフェイスと灰色のインターフェイスを備えたサーバーであり、独自のプライベートネットワークを見ています。 さらに考慮すると、「私たちの」ラップトップはAで、「サーバー」はBであると考えています。



タスク ：アプリケーションをローカルで実行しているので、別のユーザーに（ネットワークの外部で）彼を見る機会を与える必要があります。



解決策：ローカルポート（127.0.0.1:80）を公的にアクセス可能なアドレスに転送します。 「公開されている」Bが何か便利なポート80を使用したと仮定して、非標準ポート（8080）に転送します。



最終構成：8.8.8.8:8080のリクエストはラップトップAのローカルホストに送られます。



ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8









-Rオプションを使用すると、リモート（ R emote）サーバーから（ローカル）ポートにポートをリダイレクトできます。

重要：アドレス8.8.8.8を使用する場合、サーバー設定BでGatewayPortsを有効にする必要があります。

チャレンジ 。 サーバー「B」では、特定のデーモンがリッスンしています（たとえば、SQLサーバー）。 私たちのアプリケーションはサーバーと互換性がありません（他のビット、OS、邪悪な管理者、制限の禁止と課しなど）。 リモートのローカルホストにローカルにアクセスしたい。



最終構成：localhost：3333 'A'のリクエストは、localhost：3128 'B'のデーモンによって処理される必要があります。



ssh -L 127.1:3333:127.1:3128 user@8.8.8.8









-Lオプションを使用すると、ローカルコール（ L ocal）をリモートサーバーに転送できます。



タスク ：サーバー「B」の灰色のインターフェイスで、特定のサービスがリッスンしており、同僚（192.168.0.3）がこのアプリケーションを見ることができるようにします。



最終構成：グレーのIPアドレス（192.168.0.2）への要求は、サーバーBのグレーのインターフェイスに到達します。



ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8



ネストされたトンネル

もちろん、トンネルはリダイレクトできます。



タスクを複雑にしましょう。アドレス10.1.1.2（ポート80）のサーバー上のローカルホストで実行されているアプリケーションを同僚に見せたいと思います。



解決策は難しいです。

ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2









何が起こっているの？ ローカルリクエストをアドレスからサーバーBのローカルホストにリダイレクトするようにsshに指示し、ローカルホストをリッスンしてサーバー10.1.1.2（クライアントが接続する必要がある）にリクエストを送信するオプションを使用して、サーバーBでssh（つまり、sshクライアント）を起動した直後に接続します。 ポート9999は任意に選択されます。主なことは、最初の呼び出しと2番目の呼び出しで一致することです。

リバースソックスプロキシ

前の例が単純で明白に思えた場合、この例が何をするかを推測してみてください。

ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2







サーバー10.1.1.2でインターネットの使用を禁止することをタスクとするセキュリティ担当者の場合、このコマンドはコンピューター「A」で実行されているプロキシプロキシを使用してサーバー10.1.1.2のインターネットアクセスを整理するため、教皇の髪の毛を抜くことができます。 トラフィックは完全に暗号化され、他のSSHトラフィックと区別できません。 ネットワーク「192.168.0 / 24」の観点からのコンピューターからの発信トラフィックは、コンピューターAの通常のトラフィックと区別できません。

---

トンネリング

この時点でセキュリティ部門の司祭がbげていないのに、sshがセキュリティの最大の敵としてリストされていない場合、IPトンネリングまたはイーサネットでさえ、すべてが究極の殺人者です。 最も過激なケースでは、これにより、dhcpのトンネリング、リモートarpスプーフィング、lanおよびその他の第2レベルのさでの起動が可能になります。



詳細についてはこちらをご覧ください： www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html



（悲しいかな、私自身はこれを使用しませんでした）。



このような状況では、DPI（ディープパケットインスペクション）でそのようなトンネルをキャッチすることは不可能であることが容易に理解できます-sshは許可されています（読み取り-必要なことを行います）またはsshは禁止されています（そして、少し後悔することなく安全にバカを残すことができます）。

承認転送

それがすべてだと思うなら.......しかし、まだ「下」に書かれていない著者とは異なり、読者は下にたくさんの手紙や陰謀があることを前もって見ています。



OpenSSHでは、これらのサーバーが信頼されておらず、必要なものを悪用する可能性がある場合でも、サーバーをブリッジヘッドとして使用して他のサーバーに接続できます。



単純な承認転送で開始します。



私は絵を繰り返します：







キーを受け入れる準備ができているサーバー10.1.1.2に接続するとします。 しかし、ここでは8.8.8.8にコピーしたくありません。エントランスヤードと半分の人がsudoを持ち、他の人のディレクトリを介して収集される可能性があるためです。 妥協のオプションは、user @ 8.8.8.8から10.1.1.2を認証する「異なる」sshキーを持つことですが、8.8.8.8から10.1.1.2のユーザーを許可したくない場合、これはオプションではありません（さらに、キーはpoyuzatであるだけでなく、「雨の日のために」自分自身をコピーすることもできます）。



sshは、sshエージェント（キーのパスワードを要求するサービス）を転送する機能を提供します。 ssh -Aオプションは、認証をリモートサーバーに転送します。



呼び出しは次のようになります。



ssh -A user@8.8.8.8 ssh user2@10.1.1.2









リモートsshクライアント（8.8.8.8）は、このサーバーに接続し、sshクライアントに認証エージェント（ただし、キーではない！）にアクセスする場合のみ、10.1.1.2であることを証明できます。



ほとんどの場合、ロールします。



ただし、サーバーが完全に不良な場合、ルートサーバーは接続時に偽装のためにソケットを使用できます。



さらに強力な方法があります-sshを単純なパイプ（「パイプ」の意味）に変換し、それを通してリモートサーバーを操作します。



この方法の主な利点は、中間サーバーのプロキシから完全に独立していることです。 偽のsshサーバーを使用し、すべてのバイトとすべてのアクションをログに記録し、任意のデータをインターセプトし、必要に応じて偽造することができます。やり取りは「最終」サーバーとクライアントの間で行われます。 ターミナルサーバーのデータが改ざんされている場合、署名は収束しません。 データが改ざんされていない場合、セッションは保護モードで設定されるため、インターセプトするものはありません。



私はこのクールな設定を知りませんでした 。



セットアップは、2つのssh機能に関連付けられています：-Wオプション（sshを「パイプ」に変換する）とProxyCommand configオプション（コマンドラインオプション、そうではないようです）。 これらのオプションは最近登場したため、centosユーザーは逃走中です。



次のようになります（上の写真の図）：



.ssh / config：

ホストレイプ
      HostName 10.1.1.2
     ユーザーuser2
      ProxyCommand ssh -W％h：％p user@8.8.8.8

さて、接続は簡単です： ssh raep



。



サーバー8.8.8.8はトラフィックを傍受または偽造したり、ユーザー認証エージェントを使用したり、トラフィックを変更したりすることはできません。拒否-はい、できます。ただし、許可されている場合、復号化または変更せずに自分自身を通過します。設定が機能するためには、user @ 8.8.8.8とuser2@10.1.1.2の両方のauthorized_keysに公開鍵が必要です



もちろん、ポートフォワーディング、ファイルコピー、ソックスプロキシ、L2トンネル、トンネリングなど、他のすべての障害を接続に装備できますXサーバーなど

ファイナル

もちろん、トンネルに関する投稿にはトンネルがあり、成功した記事にはすべての人気が秘められています。 維持する：