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

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

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

Обновление
Я прочитал в Как использовать команду ssh в оболочке script?, почему небезопасно указывать пароли в командной строке. Использует ли expect также пароль для хранения и видимый мир (используя ps aux)? Это проблема безопасности при использовании expect?

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

Требование

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

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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

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

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

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

Ответ 2

Правильный способ сделать это:

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

echo $SSH_AUTH_SOCK

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

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

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

Ответ 3

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

Ответ 4

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

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

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

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

sshpass -e ssh [email protected]

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

Ответ 5

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

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

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

SSH-агент

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

Команды командной строки ssh

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

служебные учетные записи ssh

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

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

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

Ответ 6

Да, вы хотите аутентификацию с помощью панели.

Ответ 7

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

Для общедоступной/частной проверки подлинности с базой ключей

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

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

Ответ 8

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

SSH_ASKPASS. Если ssh требует кодовую фразу, он будет считывать кодовую фразу из текущего терминала, если он был запущен с терминала. Если ssh не имеет связанного с ним терминала, но установлены DISPLAY и SSH_ASKPASS, он выполнит программу, указанную SSH_ASKPASS, и откройте окно X11 для чтения парольной фразы. Это особенно полезно при вызове ssh из .xsession или связанного с ним script. (Обратите внимание, что на некоторых машинах может потребоваться перенаправить вход из /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 [email protected] id </dev/null)

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

Ответ 9

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

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

Это с уже запущенным агентом ssh и для достижения того, что ему нужна кодовая фраза.

Ответ 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-ключи, используя кодовую фразу, ранее сохраненную в файле keychain.

Соединения с удаленными системами могут быть прямыми или проксимированными через шлюзы 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" (aka nc) на шлюзе ssh как сетевой канал.

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

ssh app1

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

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

Без команды config и nc proxy rsync будет немного сложнее:

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

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

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

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

rsync -vaut -e 'ssh -i ~batch/.ssh/id_dsa -A gw' $sourcefiles [email protected]:/Sites/www/

Это приводит к тому, что rsync использует специальную команду ssh в качестве оболочки удаленного доступа. В специальном случае ssh используется личный ключ DSA пользователя "пакетный" пользователя. Целевая удаленная система команды rsync будет доступна с использованием пользователя "пакетной".