Q&A
tag を変えたほうが良いですね、UnixとかLinuxとかSSH辺りかな。その方が詳しい方に出会えるかと。
WEBサーバ：192.168.0.10 CentOS7
DBサーバ：192.168.0.100 CentOS7+MySQL
SCPコマンドでDBサーバ上のｄｍｐファイルを
定期的に、WEBサーバ側にコピーしてます。
いつものようにSCPコマンドを試みると、コピーが実行され、
両サーバのパスワード入力を促されますが、
コピーが始まったところで表題のエラーになります。
いつも実行するSCPコマンド
scp -p root@192.168.0.100:/root/backup/190712.sql.gz rails_user@192.168.0.10:/home/rails_user/myApp/
エラー画面
コピーの途中でエラー？
普段は出来てました。
特に何も設定は変更してないのですが・・・。
ちなみにDBサーバ側へPINGは通ってます。
分かる方教えて下さい。
・同日追記
SSHサービス確認
DBサーバ
WEBサーバ
・同日追記
firewall確認
DBサーバ
WEBサーバ
DBサーバ側のfirewallリストにSSHが入っていない？のが原因でしょうか？
・同時追記
-vオプション付けてSCP
scp -p -v root@192.168.0.100:/root/backup/190712.sql.gz rails_user@192.168.0.10:/home/rails_user/myApp/
WEBサーバ側
DBサーバ側
有難う御座います！
気付きませんでした。
早速変えます！
scp に -v オプションを付けると 詳細なログが表示されると思うのですが、どこで、エラーになっているかわからないでしょうか。
有難う御座います。
SCPに-v を付けてみました。
debugが出力されましたが、どこでエラーになってるか分かりませんでした。
sshが繋がるのにscpだけエラーになるなら、クライアント側のログじゃなくてDBサーバー側のログを見た方が良さそうですね
失礼しました。
DBサーバ側で同じコマンドを流した場合の結果を添付します。
scp受ける側のDBサーバーではコマンド打ちませんよ、sshdでログ出力設定しましょう。
あとデバッグレベル１だとほとんど役に立たないので、２～３辺りにした方がヒントになるでしょう。
３だとゴッチャゴチャしてて見る気失せるので２がおすすめです。
よく見たらＤＢからＷＥＢへ送ってますね。失礼。ログを出すならＷＥＢ側のssdhです。
またも失礼しました。ご指摘有難う御座います。
sshdでデバッグレベル２で出力ですね！調べてやってみます！
さらによくみたらリモート間でのＳＣＰコマンドですね、それって本当に今まで使ってたコマンドですか？
「いつも実行するＳＣＰコマンド」というのが実はいつものとは少し改変してあるって事なら納得するんですが、本当にそのコマンドがいつも実行出来ていたのなら私には対策は分かりません。むしろそのコマンドが何の設定も無しに実行出来ちゃうんだな～って感じで。
先のコメントに付帯してもう一つ気になる点
DBでもWEBでもないサーバーからscpコマンドを打っているんですよね？そうでなければどちらか片方のIP指定はいらないと思うので
度々すみません。sshdについてまだ調べてます。
はい。不定期ですがバックアップが必要になった時には、
WEBサーバ側から上記のSCPコマンドを入力してました。※バックアップファイル名だけ変えて
WEBサーバ側にログインし、そこからから入力してました。
そういう事ならscpコマンドに関して言うとローカル側のIP指定はいらないので、コマンドに書いてある192.168.0.10を取っ払ってみてはどうでしょうか。それが原因とは限りませんが。
上記の方のおっしゃる通りで、リモート間でscpを行う場合-3をつける必要があるようです。この場合はrails_userがlocalですから、後者のdestに当たる部分`rails_user@192.168.0.10:`は必要ありません
回答1件
0
ベストアンサー
logはtextで貼って頂いた方が読みやすいです。コピペもできるで。
次のUPのときはそうして下さい。
で、
logをみると成功しているようにしか見えないのですが、100%ですし、14M sentですし、Exit ０ ですし。
Web、DB双方がともに sent 14M、receive 5kというのが気になりますが。
データは届いていませんか？
ところで、うまく行くようになった暁の話ですが、
rootにloginしています。private addressだからどうでも良いちゃ良いかも、ですが、
DB側から rails_user@192.168.0.10 におくるか
backup場所を変え、他のアカウントで読めるようにし、そのアカウントで取りに行くか
にすることをお薦めします
投稿2019/07/13 07:30
総合スコア23645
有難う御座います。
logは今後テキストで貼り付けます。
申し訳ございません。
いえ。データは届いてません。
そもそも14Mなど軽くないのです。
最低でも70M以上あります。
すいません。最後のアドバイス（DB側から送るかor他のアカウントで取りに行くか）について、なぜそうした方が良いのか分かりません。
よろしければ教えていただけないでしょうか？
う〜〜む、するとあの exit 0 はなんだ！？
何故良いか、というのはセキュリティ的な問題です。scpの双方がプライベートIPなので、外部からアクセスされる気遣いは多分しなくて良いでしょうから、今の環境では杞憂レベルですが、基本的な知識としては持っていた方が良いかとおもい書きました。
rootに外部から直接アクセスできるようにするのはまずいです。
rootにSSHでloginするとき、パスワード認証はまずいです。総当りアタックを受けます。
ということで、
rootに接続する。 のをやめる方法として２案
DBのrootの方からWebに続する。
Webから DBのroot以外のアカウントに接続する
を提案しました
大変申し訳ございません！！
データは圧縮してたので14Mで間違いなかったです！！
解凍後が70M越えでした。
確認不足でした。
>rootに外部から直接アクセスできるようにするのはまずいです。
さくらクラウドを利用しており、提供されているコントロールパネル画面→DBサーバ→コンソールからアクセスしておりました。
この場合は、どうなるのでしょうか？上記に該当するのでしょうか？
度々質問すみません。宜しくお願い致します。
今、再度コマンド入力すると、データがコピーできました(+_+)!?
質問を上げた日は、何度やっても出来なかったのですが・・・。
きっと私の勘違いだったのだと思います。
お騒がせして大変申し訳ございません。
返ってくるメッセージも変わりありません。
正常に返ってきたメッセージ(Connection close)を、コピーがないため、エラーメッセージと勘違いしてました。
あなたの回答
tips
プレビュー
