☰

SSHは正常に機能しますが、SCPプールを実行できません。

tag-icon • tag-icon linux ssh scp
SSHは正常に機能しますが、SCPプールを実行できません。

2 つのサーバー間で鍵認証を設定し、鍵なしで SSH で接続できます。たとえば、次のようになります。

ssh backup@hostname

これはうまく機能し、ログインします。ただし、SCPを使用してファイルを抽出しようとすると、ファイルは受信されません。

ターゲットファイルはchmod 777問題を解決するためにそのファイルを処理しましたが、コピーするファイルがあるにもかかわらず見つからないようです。

これはipの（難読化された）出力です。

scp -vvv backup@hostname:/var/stuff/backups/*.tgz /data/backups/

検証から始めてください。

debug1: Authentication succeeded (publickey).    
Authenticated to xxx.xxx.xxx.xxx ([xxx.xxx.xxx.xxx]:22).
debug2: fd 4 setting O_NONBLOCK    
debug2: fd 5 setting O_NONBLOCK    
debug2: fd 6 setting O_NONBLOCK    
debug1: channel 0: new [client-session]    
debug3: ssh_session2_open: channel_new: 0    
debug2: channel 0: send open    
debug1: Entering interactive session.    
debug2: callback start   
debug2: fd 3 setting TCP_NODELAY    
debug3: packet_set_tos: set IP_TOS 0x08    
debug2: client_session2_setup: id 0    
debug1: Sending environment.    
debug3: Ignored env XDG_SESSION_ID    
debug3: Ignored env TERM    
debug3: Ignored env SHELL    
debug3: Ignored env SSH_CLIENT    
debug3: Ignored env SSH_TTY    
debug3: Ignored env http_proxy    
debug3: Ignored env USER    
debug3: Ignored env LS_COLORS    
debug3: Ignored env MAIL    
debug3: Ignored env PATH   
debug3: Ignored env QT_QPA_PLATFORMTHEME    
debug3: Ignored env PWD    
debug1: Sending env LANG = en_AU.UTF-8    
debug2: channel 0: request env confirm 0    
debug3: Ignored env SHLVL    
debug3: Ignored env HOME    
debug3: Ignored env LANGUAGE    
debug3: Ignored env LOGNAME    
debug3: Ignored env SSH_CONNECTION    
debug3: Ignored env LESSOPEN    
debug3: Ignored env XDG_RUNTIME_DIR    
debug3: Ignored env LESSCLOSE    
debug3: Ignored env _    
debug3: Ignored env OLDPWD    
debug1: Sending command: scp -v -f /var/stuff/backups/*.tgz    
debug2: channel 0: request exec confirm 1    
debug2: callback done    
debug2: channel 0: open confirm rwindow 0 rmax 32768    
debug2: channel 0: rcvd adjust 131072    
debug2: channel_input_status_confirm: type 99 id 0    
debug2: exec request accepted on channel 0    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0    
debug2: channel 0: rcvd eof    
debug2: channel 0: output open -> drain    
debug2: channel 0: obuf empty    
debug2: channel 0: close_write    
debug2: channel 0: output drain -> closed    
debug2: channel 0: rcvd close    
debug2: channel 0: close_read    
debug2: channel 0: input open -> closed    
debug3: channel 0: will not send data after close    
debug2: channel 0: almost dead    
debug2: channel 0: gc: notify user    
debug2: channel 0: gc: user detached    
debug2: channel 0: send close    
debug2: channel 0: is dead    
debug2: channel 0: garbage collecting    
debug1: channel 0: free: client-session, nchannels 1   
debug3: channel 0: status: The following connections are open:    
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cc -1)
debug1: fd 0 clearing O_NONBLOCK   
debug1: fd 1 clearing O_NONBLOCK    
debug1: fd 2 clearing O_NONBLOCK    
Transferred: sent 3736, received 2280 bytes, in 0.0 seconds    
Bytes per second: sent 764498.2, received 466556.7    
debug1: Exit status 1    
backup@ar-secubn03:/var/scripts$

答え1

この試み：

scp -vvv 'backup@hostname:/var/stuff/backups/*.tgz' /data/backups/

それでも問題が解決しない場合は、以下を試してください。

scp -vvv 'backup@hostname:/var/stuff/backups/\*.tgz' /data/backups/

答え2

同様の問題がありましたが、sshコマンドを実行できましたが、scpコマンドは実行できませんでした。 Kensterの優れたデバッグ技術を見てみましたが、まだ何の助けも得ていませんでしたが、とても便利でした！最後に、問題がecho私のスクリプトのコマンドにあることを見つけました.bashrc（他のコマンドを挿入した後）。echoスクリプト内のすべてのコマンドをコメントアウトした後、scpコマンドを正常に実行できました。

答え3

debug1: Sending command: scp -v -f /var/stuff/backups/*.tgz    
debug2: channel 0: request exec confirm 1    
debug2: callback done    
debug2: channel 0: open confirm rwindow 0 rmax 32768    
debug2: channel 0: rcvd adjust 131072    
debug2: channel_input_status_confirm: type 99 id 0    
debug2: exec request accepted on channel 0    
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
...
debug1: Exit status 1

この行は、ローカル scp インスタンスがリモート・システムscpで予想されるコマンドの実行を要求し、リモート・サーバーが要求に応答してプロセスを開始したことを示します。ただし、リモートプロセスはステータスコード1でほぼ直ちに終了し、出力をエクスポートしません。

リモートscpインスタンスがコピーするファイルを読み取れない場合、またはファイルが存在しない場合は、エラーメッセージが表示されます。リモートscpプログラムが見つからないか実行できない場合、終了コードは1の代わりに126または127になります。

私は次のいずれかが起こっていると思います。

  1. リモートアカウントの.bashrcまたは.bash_profileの問題により、シェルが早く終了しました。たとえば、セッションにTTYがないという事実に敏感です。
  2. scpリモートシステムのプログラムが破損しているか、正しく機能していません。
  3. リモートシステムのプログラムは、scpscpのように動作しない他のプログラムに置き換えられました。たとえば、誰かがそれを誤って作成されたシェルスクリプトまたは "/bin/false"のコピーに置き換えた可能性があります。
  4. SSHソフトウェアは、人々がscpを実行しないように構成されています。使用中のキーは特定のコマンドを実行するように設定されているか、authorized_keysリモートサーバー上のファイルに指示がある可能性があります。ForceCommandsshd_config

これを確認する最も簡単な方法は、リモートシステム管理者に連絡するか、リモートシステムにログインしてscp実行可能ファイルを確認することです。scp -hたとえば、実行すると scp 関連の使用法メッセージが出力されます。

この問題をリモートで解決する必要がある場合は、次に試す方法は次のとおりです。

$ ssh -T backup@hostname cat /etc/group

これにより、リモートシステムのグループファイルが端末に書き込まれます。これは、リモートシステムで任意のコマンドを実行できることを証明します。

$ ssh -T backup@hostname scp -v -f /etc/group < /dev/zero

これはセッションのリモート部分をシミュレートしますscp。リモートscpプログラムが実行されている場合は、次の出力が表示されます。

C0644 674 group
root:x:0:
daemon:x:1:
[...]
devuser:x:1001:
Sending file modes: C0644 674 group
$

scpこれがうまくいくと、「/var/stuff/backups/*.tgz」では失敗しますが、「/etc/group」では機能する理由についての質問になります。これを実行して動作していることを確認できます。

ssh -T backup@hostname 'scp -v -f /var/stuff/backups/*.tgz' < /dev/zero

それでも失敗する場合の重要なオプションは、リモートセッションを実行するようにスケジュールし、strace各プログラムが実行する操作を正確に確認することです。

答え4

スペースを使用しないようにバックアップ*.tgzを変更するために、最初のバックアップ/ *.tgzを実行すると考えられます。おそらく99％の問題が解決する可能性があります。

関連情報