stdout
na jednom serveru CentOS je třeba převést na stdin
na jiném serveru CentOS. Je to možné?
ScottPack, MikeyB a jofel mají platné odpovědi. Odpověď jsem udělil Scottovi, protože i když moje otázka nespecifikovala bezpečnost jako požadavek, vždy je hezké být v bezpečí. Návrhy ostatních dvou kolegů však budou fungovat také.
Toto je neměnné ano.
Když jeden používá ssh
k provedení příkazu na vzdáleném serveru, provede nějaký druh efektního přesměrování interních vstupů/výstupů. Ve skutečnosti to považuji za jednu z jemně příjemnějších vlastností OpenSSH. Konkrétně pokud použijete ssh
k provedení libovolného příkazu na vzdáleném systému, ssh namapuje STDIN
a STDOUT
na příkaz prováděného příkazu.
Pro účely příkladu předpokládejme, že chcete vytvořit záložní tarball, ale nechcete nebo nemůžete jej ukládat lokálně. Podívejme se na tuto syntaxi:
$ tar -cf - /path/to/backup/dir | ssh remotehost "cat - > backupfile.tar"
Vytváříme tarball a zapisujeme ho do běžných věcí STDOUT
. Protože pomocí ssh provádíme vzdálený příkaz, STDIN je mapován na STDIN
z cat
. Což jsme pak přesměrovali na soubor.
Pohodlný způsob propojení dat mezi hostiteli, když se nemusíte starat o zabezpečení přes drát, je použití netcat
na obou koncích připojení.
To také umožňuje jejich asynchronní nastavení:
Na "přijímači" (opravdu, budete mít obousměrnou komunikaci, ale je jednodušší si to představit takto), spusťte:
nc -l -p 5000 > /path/to/backupfile.tar
A na „odesílateli“ spusťte:
tar cf - /path/to/dir | nc 1.2.3.4 5000
Velmi mocným nástrojem pro vytváření uni- a obousměrných připojení je socat
. Pro krátký pohled na možnosti, podívejte se na příklady v jeho manpage .
Nahrazuje netcat
a podobné nástroje zcela a má podporu pro šifrovaná připojení ssl. Pro začátečníky to nemusí být dost jednoduché, ale je alespoň dobré vědět, že existuje.
Věci se trochu zkomplikují, pokud máte bastion server , který musí být použit.
Můžete předat ssh
jako příkaz k ssh
jako:
cat local_script.sh | ssh -A [email protected] ssh -A [email protected] "cat > remote_copy_of_local_script.sh; bash remote_copy_of_local_script.sh"
Dejte si pozor na pseudo-terminály
Zde je důležité, aby ssh
, stejně jako většina nástrojů, ve výchozím nastavení zacházelo s opravami stdout
a stdin
.
Když však začnete vidět možnost jako Disable pseudo-terminal allocation.
A Force pseudo-terminal allocation.
, Možná budete muset udělat malou zkoušku a chybu. Ale jako obecné pravidlo nechcete změnit chování tty
, pokud se nepokoušíte opravit zkomolené/binární nevyžádané emulátor terminálu (v jakém typu člověk zadává).
Například mám tendenci používat -At
Tak, aby se ssh-agent mé pracovní stanice posunul dopředu, a aby běh tmux na dálku nezačínal binárně (podobně jako ssh -At bastion.internal tmux -L bruno attach
). A také pro dokovací stanici (podobně jako Sudo docker exec -it jenkins bash
).
Tyto dva příznaky -t
Však způsobují některé obtížné sledování poškození dat, když se pokusím něco podobného:
# copy /etc/init from jenkins to /tmp/init in testjenkins running as a container
ssh -A bastion.internal \
ssh -A jenkins.internal \
Sudo tar cf - -C /etc init | \
Sudo docker exec -i testjenkins \
bash -c 'tar xvf - -C /tmp'
# note trailing slashes to make this oneliner more readable.
Zkuste zadat veřejný klíč ssh do jiného hostitele pouze jedním příkazem
ssh [email protected] 'cat >> .ssh/authorized_keys' < .ssh/id_rsa.pub
Zjistil jsem, že je to nejjednodušší, po nastavení žádné handshaking hesla mezi servery pro uživatele, který používáte příkaz jako:
Nezkomprimováno
tar cf - . | ssh servername "cd /path-to-dir && tar xf -"
Komprese za běhu
tar czf - . | ssh servername "cd /path-to-dir && tar xzf -"