Мне нужно автоматизировать способ распространения файлов на множество серверов. Проблема, конечно, в том, что мне нужно использовать безопасный протокол (SSH или SCP), а имя пользователя / пароль на каждом сервере разные.
Сценарий состоит в том, что у нас есть главный сервер a с пользователем a_prod, и нам нужно отправлять обновленные сценарии / конфигурации и т. Д. На серверы b, c, d, ... и на этих серверах имена пользователей: b_dev, c_test, d_prod с каждый имеет уникальный пароль.
Имена пользователей должны быть уникальными в разных средах по нескольким причинам, связанным с DB2 и корпоративной безопасностью.
Общие ключи не будут работать в этом сценарии, поэтому мне нужно передать имена пользователей и пароли через скрипт. Это среда AIX, и у меня нет возможности установить expect.
Любые идеи?
Общие ключи упоминаются в нескольких ответах ниже: Я пробовал несколько способов сделать это, я думаю, что основная проблема заключается в том, что идентификаторы удаленного пользователя не существуют ни на одном другом хосте, поэтому я не могу создать ssh-keygen для них на хост, с которого я хочу использовать ssh, чтобы реализовать реализацию общего ключа с основным пользователем (a_prod), имеющим несколько идентификаторов в зависимости от целевого хоста (b_dev, c_test_d_prod). Закрытый ключ для этих пользователей необходимо сгенерировать на узле a для удаленных пользователей, а затем их открытые ключи необходимо скопировать на целевые узлы.
"Корпоративный S (тупость)" :-)
Я думаю, что SSH / SCP в целом живет в рамках философии UNIX. Очень редко разработчики приложений Unix намеренно делают это так, чтобы администратор не мог легко сделать что-то глупое. Как правило, будет предупреждение типа: «Вы, вероятно, не хотите этого делать, потому что ... но, если вы действительно хотите, хорошо!».
В случае передачи пароля ssh в скрипте они намеренно усложняют это, потому что это как раз такой плохая идея.
На данный момент я бы даже не стал беспокоиться о SSH. Вам действительно нужно поговорить со специалистами по корпоративной безопасности и придумать реальное решение для сценария. Если они не хотят использовать ключи, спросите их, что вам следует делать. Если это не сработает, скажите своим менеджерам, что они хотят, чтобы этого нельзя было сделать из-за ограничений корпоративной безопасности. Если менеджеры настаивают на этом, Получите это в письменной форме, или это ваша задница на линии
Сначала предупреждение: будьте осторожны, чтобы не создать угрозу безопасности во имя целесообразности. Кевин и Кайл говорят о хороших моментах. Хранение множества комбинаций имени пользователя и пароля в файле (даже в зашифрованной базе данных), вероятно, является очень плохой идеей и может нарушать корпоративную политику.
Решением вашей проблемы может стать сертификат на стороне клиента. См. Статьи ниже для получения дополнительной информации:
Вставьте стандартный отказ от ответственности о корпоративной политике и о том, почему здесь плохо помещать user / pass в скрипты.
Но все мы работаем в реальном мире, где иногда это не имеет смысла. Так .. Есть много инструментов, которые позволят вам это сделать. У Shell нет встроенного способа заставить это работать. Мое любимое оружие для очень быстрых и грязных скриптов такого рода - Expect. Бежать до смешного легко.
#!/usr/bin/expect
set nodename "hostname"
set username "user"
set password "pass"
set prompt "your prompt on the remote system"
eval spawn ssh -x $user@$nodeaddy
set timeout 15
expect "password:" { send "$password\r" }
expect "$prompt" { send "script\r" }
exit 0
Очевидно, это может сработать, а может и не сработать, но из синтаксиса видно, насколько просто начать работать.
Если предположить, что пара открытых и закрытых ключей разрешена корпоративной политикой, этого не так уж и сложно добиться. Чтобы получить имя пользователя, отличное от имени пользователя, запустившего ssh (сценарий), используйте username@host. Сложнее всего заставить работать правильные закрытые ключи. Предполагая, что из-за какого-то ложного чувства безопасности каждый хост должен использовать другую пару ключей (в противном случае это проще), вы должны создать файл конфигурации, который сообщает клиенту, какую пару использовать для какого хоста (вы также можете указать имя пользователя в файле).
Для openssh файл будет выглядеть так:
host a_prod
user usera
IdentityFile ~/.ssh/keyfora_prod
host b_dev
user userb
IdentityFile ~/.ssh/keyforb_prod
и т.п.
Просто помните, что эта установка на самом деле не более безопасна. Если кто-то может получить доступ к этому пользователю на этом компьютере, он может прочитать все закрытые ключи (у которых не может быть пароля, если все должно быть в безопасности, или вы должны взломать ssh_agent), а также жестко закодированные пароли. Поскольку нет никаких причин для того, чтобы файлы закрытого ключа располагались где-либо еще, кроме ssh-каталога этого пользователя (в случае потери можно легко создать новый ключ), наличие четырех файлов не отличается от наличия одного с точки зрения безопасности.
ОК - я наконец получил это работает следующим образом:
ssh -i b_dev_id_dsa_2048_a b_dev@bи альт, наконец-то работает.
Спасибо всем за помощь, и, наконец, niXar за этот последний момент Гомера Симпсона DUH, так как это в точности обратное тому, что вы делаете, если пользователь на всех хостах один и тот же.
Без приватных ключей, Expect или чего-то подобного, я не понимаю, как вы можете сделать это автоматически. Что-то нужно дать.
Тебе есть над чем поработать? Я предположил, что у вас нет Perl, так как тогда вы могли бы использовать Expect.pm? Python? Что-нибудь? Просто старый уродливый кш? Расскажи нам больше.
Если вам не разрешено использовать язык программирования, вам нужно ввести пропуск вручную. В этом случае вы можете использовать:
scp myfile b_dev@b_prod:/path/to/dest
Если речь идет о пакетах, рассмотрите возможность использования SFTP. Затем вы можете использовать lftp и не вводить пароль прямо из справочной страницы:
lftp [-d] [-e cmd] [-p port] [-u user[,pass]] [site]
Но если вы не можете получить Expect, я сомневаюсь, что вы можете использовать lftp. Ты можешь?
/ О, я ненавижу проприетарную хрень Unix
Это не очень хорошая идея, но если вам действительно нужно это сделать, sshpass может вам помочь: http://sourceforge.net/projects/sshpass/
Пришлось сделать нечто подобное, только в обратном направлении. Мы получаем файлы с нескольких серверов, и именно так мы это сделали.
awk '{FS="|"; printf("rsync %s:%s %s &\n", $1, $2, $3)}' config | sh
Создайте файл с именем config и поместите в него строки, которые вы хотите запустить. (обратите внимание: для начала вам нужно вставить пустую строку).
Как это настроено сейчас, вы бы поставили username@server.com|(folder on remote server)|(folder on local server) в config, и он синхронизирует оба файла. Вы захотите переключить команду rsync в команде awk на противоположное.
Это будет хорошо работать с аутентификацией ssh-key, которую мы и используем.
Я также предлагаю создать SSH-ключи для аутентификации и использовать такие инструменты, как unison или lsyncd (в зависимости от ваших потребностей), чтобы синхронизировать файлы.
Если аутентификация на основе ключа не подходит, вы можете использовать "ожидать" (http://linux.die.net/man/1/expect), чтобы написать его. Expect проверяет определенный выход (скажем, вопрос для пароля) и связанный с этим ввод определенной строки (в этом примере пароль).
Но опять же, как было предложено, я бы предпочел решение с ssh-ключом.