mentransfer file melalui sesi SSH dua-hop


6

Saya memiliki kotak Linux di tempat kerja yang sering saya masuki dari rumah. Kotak Linux ada di jaringan internal, tapi ada kotak yang merentang kedua jaringan, jadi saya bisa masuk seperti ini:

ssh -tA username@bridge.work.com ssh username@10.10.10.130

Saya memiliki beberapa file yang duduk di ~ / tmp yang ingin saya salin ke mesin lokal saya. (sebut saja mereka ~ / tmp / file1 ~ / tmp / file2 dan ~ / tmp / file3 demi argumen)

Saya telah melihat sesuatu seperti pekerjaan ini:

ssh -tA username@bridge.work.com ssh username@10.10.10.130 'tar cf - ~/tmp/file*' | tar xf -

Ini akan tar file pada mesin jarak jauh, mengirim hasilnya ke stdout, lalu pipa hasilnya ke tar lokal, yang sedang membongkar data pada stdin lokal.

Tidak bekerja:

Pada mesin jarak jauh, jika saya jalankan

tar cf - tmp/file* | md5sum
f1b776364c10dfc20500f228399a7c63  -

Dari mesin lokal:

ssh -tA username@bridge.work.com ssh username@10.10.10.130 'tar cf - ~/tmp/file*' | md5sum
bc7436c9771ee2b4978ffd29b8b7ed36  -

Saya berasumsi bahwa ini mungkin byte pemesanan snafu di seluruh jaringan ... Saya akhirnya bisa mengatasinya dengan uuencoding file, catting di jaringan kemudian uudecoding secara lokal ... untuk beberapa alasan saya tidak bisa dapatkan sintaks yang benar untuk dapat tar | uuencode di sisi jarak jauh dan uudecode | untar di sisi lokal.

Saya mencari cara yang baik untuk melakukan ini semua dalam satu langkah; lebih disukai sesuatu yang bisa saya bungkus dengan fungsi shell.

Jawaban:


6

Gunakan opsi konfigurasi SSH ProxyCommand ke dalam konfigurasi pada klien Anda. Ini memungkinkan Anda untuk membuat koneksi langsung ke tujuan.

Host remotebox
    ProxyCommand /usr/bin/ssh username@bridge.work.com "/bin/netcat -w 1 10.10.10.130 22"
    User username

scp remotebox: file lokal


Hmm. Saya mendapatkan bash: / bin / netcat: Tidak ada file atau direktori seperti itu
Barton Chittenden

Ngomong-ngomong, saya sangat suka solusi ini ... Saya tidak pernah bermain dengan arahan 'ProxyCommand', dan itu membuat saya penasaran. Saya akan menandai ini sebagai jawaban yang diterima seandainya ini berhasil. Terima kasih atas pendidikannya.
Barton Chittenden

netcat perlu diinstal pada kotak jembatan Anda. Ini adalah alat yang sangat umum.
Zoredache

Aha. Itu diinstal sebagai / usr / bin / netcat pada kotak jembatan.
Barton Chittenden

... dan scp bekerja. Tepuk tangan!
Barton Chittenden

6

Anda dapat mengatur penerusan porta. Ubah perintah inital Anda menjadi:

ssh -TA username@bridge.work.com -L 2222:10.10.10.130:22

Kemudian abaikan perintah ini. Buka terminal baru dan jalankan salah satu dari:

ssh -p 2222 username_for_10.10.10.130@127.0.0.1
scp -P 2222 username_for_10.10.10.130@127.0.0.1 remote_file local_file

Setiap kali sistem lokal Anda mendapatkan permintaan koneksi pada port alamat IP localhost 2222, perintah SSH yang Anda jalankan terlebih dahulu akan meneruskannya ke sistem jarak jauh dan membuatnya mengeluarkan permintaan koneksi ke 10.10.10.130. Ini semua ditentukan oleh saklar -L.


4

Pemesanan byte hanya berlaku untuk hal-hal seperti header IP (yang memiliki alamat berukuran empat byte sebagai satu unit), tetapi tidak mempengaruhi protokol layer yang lebih tinggi yang hanya bekerja dengan byte 8-bit - IP, TCP, dan SSH semuanya menjamin bahwa Anda menerima data persis seperti yang dikirim, byte demi byte.

Masalahnya disebabkan oleh -topsi ke yang pertama ssh. Ini memaksa alokasi pseudo-tty untuk koneksi pertama, yang hanya diperlukan untuk terminal (dan terminal emulator) dan akan memotong-motong data tertentu selama transfer. Secara khusus, carriage return (0x0D) akan dimasukkan secara otomatis sebelum setiap umpan baris (0x0A).

Hapus saja -topsi, dan Anda akan memiliki saluran yang bersih untuk mentransfer data biner.


Ini berhasil ... Saya mendapat file tar yang bagus di sisi lokal. Ironisnya, perbedaan dalam md5sum adalah herring merah: setiap kali saya menjalankan 'tar zcf - / home / username / tmp / file * | md5sum 'pada mesin jarak jauh, saya mendapat md5sum yang berbeda.
Barton Chittenden

2
@ Barton: Tidak, bukan itu. Pengujian Anda dalam pertanyaan dilakukan dengan menggunakan tar biasa, yang selalu menampilkan data yang sama untuk direktori yang sama dan menghasilkan hash yang sama juga. (Data Anda rusak oleh SSH.) Namun, yang ada di komentar Anda, mengompres output dengan zopsi gzip (the ), yang menyematkan stempel waktu saat ini di header gzip, menyebabkan hash yang berbeda setiap waktu.
grawity

Menarik. Mengapa ini hanya terjadi ketika tar gzips file? Jika saya membuat 'asdf.txt' dan menjalankan 'gzip -c asdf.txt | md5sum 'dua kali berturut-turut, saya akan mendapatkan checksum yang sama ... oh ... Saya mengerti ... header gzip menahan mtime dari file yang sedang di-gzip ... jika itu file tar yang baru dibuat, berbeda mtime.
Barton Chittenden

@ Barton: Dalam hal ini, "mtime" sebenarnya adalah waktu sistem saat ini. Saat Anda menggunakan gzip via tar -z, tidak ada "file tar"; hanya ada aliran anonim yang menghasilkan tar dan kompres gzip.
grawity

Saya juga menemukan bahwa -titu mengacaukan sungai. Masalahnya adalah, saya ingin mendefinisikan skrip shell atau alias sebagai ssh -[t]A bridge.work.com ssh 10.10.10.130dan saya membutuhkan dua di antaranya, untuk masing-masing interaktif dan non-interaktif!
musiphil
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.