Использование значения переменной в качестве пароля для scp, ssh и т. Д. Вместо запроса на ввод данных пользователем каждый раз

Question

AFAIK, команды ssh или scp не имеют / не принимают параметр пароля. В противном случае я мог бы сохранить пароль в переменной оболочки и, возможно, избавиться от приглашения ввода пароля. Если я пишу команду scp в моем сценарии оболочки, он предлагает пользователю ввести пароль. В моем скрипте несколько команд ssh и scp, и я не хочу, чтобы пользователь каждый раз вводил пароль. Я предпочел бы сначала сохранить пароль в переменной оболочки (задавая пароль один раз), а затем использовать его для каждого ssh или scp.

Я читал об "идентификации открытого ключа" в этом вопросе . Это связано с решением, которое я ищу?

Обновление
Я прочитал в Как использовать команду ssh в сценарии оболочки? Почему небезопасно указывать пароли в командной строке. Хранит ли при использовании expect пароль и виден ли он всему миру (при использовании ps aux)? Это проблема безопасности при использовании expect?

Дополнительные пояснения
Чтобы прояснить ситуацию, я пишу этот сценарий оболочки для автоматизации резервного копирования кода и базы данных, загрузки кода, выполнения необходимых запросов к базе данных, всего, что необходимо для выпуска новой версии проекта LAMP от системы разработчика до удаленного живого сервера. Мой сценарий оболочки будет находиться внутри основной базы кода проекта в каждом экземпляре разработчика.

Требование

• Я хочу, чтобы все разработчики (все могли работать с разных удаленных систем), знающие пароль SSH / FTP, могли использовать оболочку, вводя пароль ssh / ftp один и тот же только во время выполнения один раз. Я бы предпочел, чтобы пароль был паролем ssh / ftp

  Примечание - Я не хочу, чтобы другие разработчики, которые не знают пароль SSH, могли использовать его (поэтому я предполагаю, что аутентификация с открытым ключом не будет работать, поскольку она хранит пароли в системах) .

• Я не хочу никакого решения для командной строки, которое хранит пароль в каком-либо журнале в системе и может быть видимо всему миру, используя ps aux или что-то в этом роде.

Открытие Bounty
Судя по всем ответам и моему анализу этих решений, похоже, что кроме аутентификации с открытым ключом все остальные небезопасны. Я еще не уверен, что использование expect небезопасно. Я думаю, что в противном случае это правильное решение для меня. В этом случае я получаю команду «Не найдены ошибки» при попытке сделать это, как уже прокомментировал один из ответов.

С http://www.debianadmin.com/sshpass-non-interactive-ssh-password-authentication.html -

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

Итак, невозможно ли безопасно запустить несколько команд ssh, scp, введя пароль ssh / ftp (хотя бы один раз во время выполнения? Пожалуйста, прочитайте мой раздел требований снова.

Кроме того, кто-нибудь может объяснить это -

В частности, люди пишут программы что удовлетворяет предназначены для сообщить вышеуказанные пункты) пароль программно рекомендуется использовать анонимный канал и передать канал чтение конца в sshpass с помощью -d опция.

Значит ли это, что все возможно?

Answer 1

Действительно, вы определенно захотите настроить ssh-ключи, а не сохранять пароль в скрипте bash.Если ключ не имеет пароля, для ssh / scp ввод пользователя не требуется.Вы просто настроили его, чтобы использовать ключ на обоих концах и вуаля, для защищенной связи.

Однако, если я не скажу этого, я попаду в ад.Многие считают ssh-ключи без пароля плохой идеей.Если кто-нибудь получит в свои руки ключи, у них будет полный доступ.Это означает, что вы полагаетесь на другие меры безопасности, такие как права доступа к файлам, чтобы сохранить ваш пароль в безопасности.

Также посмотрите на ssh-agent.Он позволяет вам настроить его так, чтобы у вас был защищенный паролем ssh-ключ, но вам нужно всего лишь набрать его один раз, и он будет управлять паролем для вас и использовать его при необходимости.На моем компьютере с Linux, у меня есть ssh-agent, настроенный для запуска в моем файле .xinitrc, так что он запрашивает меня один раз, а затем запускает X. YMMV.

UPDATE:
Что касается ваших требований, аутентификация с открытым ключом, защищенная паролем, + ssh-agent все еще подходит.Запускать ssh-agent могут только разработчики, имеющие пароль SSH / FTP, введите пароль, а ssh-agent будет управлять паролями открытых ключей до конца сеанса, никогда не требуя взаимодействия.

Конечно, как он хранит, это совсем другое дело.IANASE, но для получения дополнительной информации о проблемах безопасности при использовании ssh-agent я нашел статью symantec довольно информативной: http://www.symantec.com/connect/articles/ssh-and-ssh-agent

"ssh-agent создает сокет домена unix,а затем прослушивает соединения из / usr / bin / ssh на этом сокете, полагаясь на простые разрешения unix для предотвращения доступа к этому сокету, а это означает, что любые ключи, которые вы вводите в свой агент, доступны любому, кто может подключиться к этому сокету.[то есть root] "...

" однако [..] они могут использоваться только во время работы агента - root может использовать ваш агент для аутентификации ваших учетных записей в других системах, но это не так.не обеспечивает прямой доступ к самим ключам. Это означает, что ключи не могут быть сняты с машины и использованы из других мест на неопределенный срок. "

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

Answer 2

Правильный способ сделать это следующим образом:

1. Убедитесь, что все ваши пользователи используют ssh-agent (в настоящее время это значение по умолчанию для большинства систем Linux). Вы можете проверить это, выполнив следующую команду:

   echo $ SSH_AUTH_SOCK

   Если эта переменная не пуста, это означает, что пользователь использует ssh-agent.

2. Создайте пару ключей аутентификации для каждого пользователя, гарантируя, что они защищены непустой парольной фразой.

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

4. Готово!

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

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

Answer 3

Тьфу.Я ударил страницы man для этого.Вот что я получил:

Используйте этот код в начале скрипта, чтобы получить пароль ssh в режиме без вывода сообщений:

read -p "Password: " -s SSHPASS # *MUST* be SSHPASS
export SSHPASS

А затем используйте sshpass для ssh, например:*

Надеюсь, это поможет.

Answer 4

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

Answer 5

Для тех, кто настраивает пару ключей, не вариант и абсолютно необходимо выполнить аутентификацию по паролю, используйте $SSH_ASKPASS:

SSH_ASKPASS - если ssh требуется фраза-пароль, она будет считывать фразу-пароль с текущего терминала, если она запускалась с терминала. Если ssh не имеет связанного с ним терминала, но установлены DISPLAY и SSH_ASKPASS, он выполнит программу, указанную SSH_ASKPASS, и откроет окно X11 для чтения ключевой фразы. Это особенно полезно при вызове ssh из .xsession или связанного скрипта. (Обратите внимание, что на некоторых машинах может потребоваться перенаправить ввод из / dev / null, чтобы это работало.)

например:.

$ echo <<EOF >password.sh
#!/bin/sh
echo 'password'
EOF
$ chmod 500 password.sh
$ echo $(DISPLAY=bogus SSH_ASKPASS=$(pwd)/password.sh setsid ssh user@host id </dev/null)

См. Также Скажите SSH использовать графическое приглашение для ключевой фразы .

Answer 6

Ожидание небезопасно

Управляет интерактивным сеансом. Если бы вы передавали пароль с помощью функции «Ожидайте», это не отличалось бы от ввода пароля в командной строке , за исключением , что ожидаемый сценарий мог бы получить пароль откуда-то. Обычно это небезопасно, потому что люди вводят пароль в сценарий или в файл конфигурации.

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

SSH-агент

ssh-agent - отличное решение, если это скрипт, который всегда будет запускаться вручную. Если есть кто-то, кто войдет в систему, чтобы управлять выполнением сценария, тогда агент - это хороший способ. Это не очень хорошее решение для автоматизации, потому что агент подразумевает сеанс. Обычно вы не запускаете сеанс для автоматического запуска сценария (например, cron).

ssh клавиши управления

Командные клавиши Ssh - ваш лучший выбор для автоматизированного решения. Он не требует сеанса, а командный ключ ограничивает то, что выполняется на сервере, только командой, указанной в авторизованных ключах. Они также обычно устанавливаются без паролей. Это может быть сложным решением для управления, если у вас есть тысячи серверов. Если у вас их всего несколько, то настроить и управлять ими довольно просто.

сервис ssh account

Я также видел настройки с учетными записями службы без пароля. Вместо записи команды в файле авторизованных ключей используется альтернативный механизм ограничения доступа / команд. Эти решения часто используют sudo или ограниченные оболочки. Тем не менее, я думаю, что ими сложнее управлять правильно, и поэтому они более небезопасны.

автоматическая аутентификация между хостами

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

Answer 7

Для аутентификации по паролю, как вы упомянули в своем описании, вы можете использовать «sshpass». В Ubuntu вы можете установить его как «sudo apt-get install sshpass».

Для базовой аутентификации пары открытый / закрытый ключ,

• Сначала сгенерируйте ключи, используя "ssh-keygen"
• Затем скопируйте ключ на удаленный компьютер, используя "ssh-copy-id username @ remote-machine"

После копирования последующие логины не должны запрашивать пароль.

Answer 8

Сегодня единственный способ, которым я смог сделать это в bash-скрипте через crontab, был таким:

eval $(keychain --eval --agents ssh id_rsa id_dsa id_ed25519)
source $HOME/.keychain/$HOSTNAME-sh

Это с агентом ssh, уже запущенным и для достижения которого он был необходимпароль

Answer 9

Да, вы хотите аутентификацию pubkey.

Answer 10

ssh, ssh-keygen, ssh-agent, ssh-add и правильная конфигурация в /etc/ssh_config на удаленных системах - необходимые компоненты для обеспечения доступа к удаленным системам.

Во-первых, необходимо создать частную / открытую пару ключей с помощью ssh-keygen. Результатом процесса keygen являются два файла: открытый ключ и закрытый ключ .

Файл открытого ключа, обычно хранящийся в ~/.ssh/id_dsa.pub (или ~/.ssh/id_rsa.pub, для шифрования RSA), необходимо скопировать в каждую удаленную систему, которая будет предоставлять удаленный доступ пользователю.

Файл закрытого ключа должен оставаться в исходной системе или на переносном USB-накопителе, на который ссылается система источников.

При создании пары ключей используется кодовая фраза , чтобы защитить ее от использования пользователями, не прошедшими проверку подлинности. При первом установлении ssh-сессии закрытый ключ может быть разблокирован только с помощью ключевой фразы. После разблокировки исходная система может вспомнить разблокированный закрытый ключ с помощью ssh-agent. Некоторые системы (например, Mac OS X) будут автоматически запускаться ssh-agent как часть процесса входа в систему, а затем автоматически ssh-add -k, который разблокирует ваши личные ssh-ключи, используя фразу-пароль, ранее сохраненную в файле цепочки для ключей .

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

.

Например, чтобы войти в удаленную систему «app1» через систему шлюзов ssh с именем «gw», можно сделать следующее:

ssh -At gw ssh -A app1

или следующие строфы, помещенные в файл ~/.ssh/config:

Host app1
ForwardAgent = yes
ProxyCommand = ssh -At gw nc %h %p 2>/dev/null

, который запускает "net cat" (он же nc) на шлюзе ssh как сетевой канал.

Вышеуказанная настройка разрешает очень простые команды ssh, даже через ssh-шлюзы:

ssh app1

Иногда даже более важными, чем терминальные сеансы, являются команды scp и rsync для безопасного перемещения файлов. Например, я использую что-то вроде этого для синхронизации моей личной среды с удаленной системой:

rsync -vaut ~/.env* ~/.bash* app1:

Без файла конфигурации и команды прокси-сервера nc rsync будет немного сложнее:

rsync -vaut -e 'ssh -A gw' app1:

Ничто из этого не будет работать правильно, если удаленные системы не настроены правильно /etc/ssh_config. Одной из таких конфигураций является удаление «корневого» доступа через ssh, что улучшает отслеживание и учет, когда несколько сотрудников могут выполнять корневые функции.

В автоматических пакетных сценариях необходимо создать специальную пару ключей ssh ​​для ИД пользователя без полномочий root, под которым запускаются сценарии. Как и в случае управления сеансом ssh, пара ключей ssh ​​пакетного пользователя должна быть развернута аналогично: открытый ключ копируется в удаленные системы, а закрытый ключ находится в исходной системе.

Закрытый ключ может быть заблокирован парольной фразой или разблокирован, по желанию системных администраторов и / или разработчиков. Способ использования специального пакетного ключа ssh, даже в скрипте, работающем под root, состоит в использовании опций команды "ssh -i ~/.ssh/id_dsa" со всеми командами удаленного доступа. Например, чтобы скопировать файл в сценарии, используя специальный «пакетный» доступ пользователя:

rsync -vaut -e 'ssh -i ~batch/.ssh/id_dsa -A gw' $sourcefiles batch@app2:/Sites/www/

Это заставляет rsync использовать специальную команду ssh в качестве оболочки удаленного доступа. Команда special-case ssh использует в качестве идентификатора личный ключ DSA пользователя "batch". Доступ к целевой удаленной системе команды rsync будет осуществляться с помощью «пакетного» пользователя.