Несколько ssh сессий в единственной команде

Подсказки пароля являются громоздкими. Способ сделать ssh более применимым состоит в том, чтобы использовать ключи для аутентификации и выполнять ключевой агент (ssh-agent) где можно зарегистрировать ключ однажды на сессию (с дополнительным тайм-аутом). Затем можно непосредственно работать

ssh root@server1 mysqldump --databases db | ssh root@server2 mysql

Если можно войти в систему от server1 до server2, необходимо передать данные непосредственно между этими двумя серверами.

ssh root@server1 'mysqldump --databases db | ssh root@server2 mysql'

(или противоположное, если можно войти в систему от server2 до server1). Снова, имейте ключ SSH для аутентификации. На Вашей локальной машине зарегистрируйте закрытый ключ SSH, который предоставляет Вам доступ к server1 и тому, который предоставляет Вам доступ к server2; удостоверьтесь, что передача агента включена (AgentForwarding yes в ~/.ssh/config).

Если Вы действительно не можете постараться не вводить пароль, Ваше лучшее обращение за помощью должно сначала установить соединение, то пойдите и передайте данные. С достаточно недавними версиями OpenSSH можно открыть основное соединение, затем впоследствии направить ведомые соединения через него. Ведомые соединения не требуют никакой дополнительной аутентификации. В Вашем ~/.ssh/config:

ControlMaster auto
ControlPath ~/.ssh/control:%h:%p:%r

Запустите основное соединение с обоими серверами:

ssh -N -M root@server1 &
ssh -N -M root@server2 &

Затем сделайте копию:

ssh root@server1 mysqldump --databases db | ssh root@server2 mysql

После этого можно уничтожить основные соединения, если Вам больше не нужны они.

ssh -O exit root@server1
ssh -O exit root@server2

Самый эффективный способ сделать это, передал бы по каналу от mysqldump сервер. Вид подобных этот список команд...

ssh root@server1 'mysqldump --databases db | ssh root@server2 mysql'

Если Вы не можете передать по каналу от удаленной машины по некоторой связанной с конфигурацией причине, Вы могли сделать этот список команд...

ssh root@server1 'mysqldump db' | ssh root@server2 'mysql db'

Если бы я был вынужден сделать последнего, то я рассмотрел бы gziping mysqldump. Я полагаю, что это сохранило меня некоторое время трансфера, независимо это не должно быть предпочтительным вариантом.

ssh root@server1 'mysqldump db | gzip -f' | ssh root@server2 'gzip -d | mysql db'

Этот последний пример, не могло бы быть на 100% корректным, я просто предполагаю, что он должен работать.

В случае, если, где Вы вынуждены передать от до B с подобной прокси машиной, нет никакого чудодейственного средства: необходимо будет использовать прокси, будучи компьютером или промежуточным сервером.

Это может быть довольно раздражающим, но ssh так гибок, что это может быть сделано прозрачным. Если Вы устанавливаете nc программа на прокси, можно добавить это к Вашему ~/.ssh/config из A:

Host B
  ProxyCommand ssh -q my_proxy nc -q0 B 22

И после этого, Вы сможете, от A, сделать классические команды ssh/scp к B, как то, если не было никакого прокси вообще.

Так, с этой конфигурацией Вы сможете использовать sshfs.

sshfs B: /mnt/B_fs

И с sshfs, Ваша команда дампа может наконец быть похожей на это:

 mysqldump --databases db ... > /mnt/B_fs/db.dump

К сожалению, это не ускорит пропускную способность прокси. Лучшее, которое можно сделать с ssh, должно включить Compression и повышение CompressionLevel.

См. это сообщение для более подробного объяснения о мультитранзитном участке ssh.

Сказанные ключевые решения являются лучшими вещами пойти. Но если Вы, по какой-либо причине, не можете сделать этого, Вы могли бы изменить свой cmdline к

ssh root@server1 mysqldump --databases db | {sleep 5; ssh root@server2 mysql; }

чтобы иметь 2-ю команду, ожидают. Корректируйтесь 5 согласно тому, как быстро Вы вводите в 1-м пароле.

Знайте, что это - просто решение для нейтрализации и что ключевые решения намного лучше.

Насколько я понимаю основная трудность, с которой Вы встречаетесь, состоит в том, что необходимо ввести два пароля: один для первого соединения SSH (пишущий в канал) и один для второго соединения SSH (читающий из канала).

Один разумный способ иметь дело с этой (несколько неблагоразумной) проблемой состоит в том, чтобы настроить ключ временного пароля меньше для аутентификации от локальной учетной записи до удаленных корневых учетных записей. Пока удаление ssh конфигурация демона уже поддерживает основанную на ключе аутентификацию, можно настроить вход в систему пароля меньше, не изменяя sshd конфигурацию. С этим методом однако, действительно необходимо отредактировать список authorized_keys для удаленного пользователя.

Вот сценарий, который генерирует ключ пароля меньше, делает интерактивный вход в систему на каждом удаленном, чтобы добавить ключевую авторизацию, нев интерактивном режиме делает Вашу копию mysql, затем нев интерактивном режиме удаляет авторизацию и наконец удаляет сгенерированные файлы ключей.

#!/bin/bash
set -e  # bail out if anything fails

verbose=
rmthosts="server1 server2"
rmtuser=root

# generate key with empty passphrase
keyfn=~/.ssh/tmpid_rsa
keycomment="tmpid_$USER@$HOSTNAME"
rm -f $keyfn*
ssh-keygen -t rsa -N '' -C $keycomment -f $keyfn

# add key to remote accounts
authfn=.ssh/authorized_keys
for rmthost in $rmthosts
do
    [ "$verbose" ] && echo "Adding key to $rmtuser@$rmthost:$authfn"
    < $keyfn.pub ssh $rmtuser@$rmthost "cat >>$authfn"
done


# perform your mysql copy
[ "$verbose" ] && echo "Performing operation"
ssh -i $keyfn rcp@gromit hostname | \
    ssh -i $keyfn rcp@gromit "cat >/tmp/prog.out"


# remove the temporary key
[ "$verbose" ] && echo "Removing temporary keys"
for rmthost in $rmthosts
do
    ssh -i $keyfn $rmtuser@$rmthost "sed -i '/$keycomment/d' $authfn"
done
ssh-add -d $keyfn
rm -f $keyfn*

Хотя решения для управления ключами великолепны, и у меня есть другой способ обойтись без: использовать именованные каналы и две оболочки.

В первой оболочке введите

mkfifo ~/db_dump
cat db_dumb | ssh root@server2 mysql

и введите второй пароль.

В другой оболочке введите

ssh root@server1 mysqldump --databases db >~/db_dump

и введите первый пароль.

После завершения дампа:

rm ~/db_dump

в любой оболочке.

Я думаю, вы могли бы сначала запустить дамп, а потом восстановление. Не должно иметь большого значения.