Доброго времени суток! Сщбственно вопрос: Каким образом построить скрипт BASH, что бы он заходил на другое устройство используя SSH соединение и выполнял там команды. Вроде гичего заумного, но ввод пароля это соединение требует именно с клавиатуры... в TELNET вопросов не возникало.
Вот найдено рабочее решение (пример, который при входе выполняет команды ls и df) Код (Bash): #!/bin/bash # user="www-data" ip="192.168.0.234" export DISPLAY=:0; export SSH_ASKPASS=./askpass.sh; #export DISPLAY=:0; export SSH_ASKPASS="www-data"; setsid ssh -o StrictHostKeyChecking=no -T $user@$ip << EOF 2>&1 ls df EOF тут пользователь user и ip всё понятно, но вот password выполняется файлом askpass.sh который только и делает echo: Код (Bash): #!/bin/bash echo "www-data" Таким образом скрипт по соединению SSH регистрируется на другой машине выполняет ls и df и отключается от неё вот весь отчёт: Код (Text): ./test1_ssh.shcoding/BASH$ Linux debian2 2.6.32-5-686 #1 SMP Tue May 13 16:33:32 UTC 2014 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. ! catserver clearlog.php coding cool Desktop Downloads err_stat_fur.html img index.html phpinfo.php ramdisk readlog.php start transport uno_dat.php Файловая система 1K-блоков Исп Доступно Исп% смонтирована на /dev/sda1 149950740 12774816 129558800 9% / tmpfs 517204 0 517204 0% /lib/init/rw udev 511892 2180 509712 1% /dev tmpfs 517204 0 517204 0% /dev/shm Хотелось бы посерьёзнее, но без сертификатов. и не во всех Линуксах работает setsid... к примеру в MOXA UC-7112-LX-Plus. Но в Debian и Raspbian всё работает железно.
Зря Вы так ругаетесь! на эту тему читаю непрерывно... и интересует что-то более практичное, чем тот пример, что я выложил выше... вполне рабочий пример. (посмотрите пост #4)
Не припоминаю, чтобы ssh имел такой ключик. Но есть, например, утилита sshpass. Вероятно, она подойдет.
Простите... но я не понял про какой ключик. Вот только что испытал с малины к совсем не знакомой (малине) машине. Код (Text): igor@raspberrypi:~/bash/test_ssh $ ./test1_ssh.sh Warning: Permanently added '192.168.0.234' (RSA) to the list of known hosts. Linux debian2 2.6.32-5-686 #1 SMP Tue May 13 16:33:32 UTC 2014 i686 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. ! catserver clearlog.php coding cool Desktop Downloads err_stat_fur.html img index.html phpinfo.php ramdisk readlog.php start transport uno_dat.php Файловая система 1K-блоков Исп Доступно Исп% смонтирована на /dev/sda1 149950740 13267644 129065972 10% / tmpfs 517204 0 517204 0% /lib/init/rw udev 511892 2180 509712 1% /dev tmpfs 517204 0 517204 0% /dev/shm Как видите регистрация и Warning: Permanently added '192.168.0.234' (RSA) to the list of known hosts. Linux debian2 2.6.32-5-686 #1 SMP Tue May 13 16:33:32 UTC 2014 i686 Вполне успешны setsid - собственно "организовал" сеанс с ssh... и использовал ввод пароля не с клавиатуры.
Вот ещё одно испытание... сервер на работе (с Debian) в локальной сети проверяет малину. Он с ней не знаком совсем. Файлы в директории .ssh заранее удалены: Код (Text): www-data@debian2:~/coding/test_ssh$ ./test1_ssh.sh Warning: Permanently added '192.168.0.129' (RSA) to the list of known hosts. The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. bash coding Desktop Documents Downloads mount Music Pictures Public ramdisk Templates transport Videos Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 30298204 4632460 24375176 16% / devtmpfs 469532 0 469532 0% /dev tmpfs 473864 0 473864 0% /dev/shm tmpfs 473864 6704 467160 2% /run tmpfs 5120 4 5116 1% /run/lock tmpfs 473864 0 473864 0% /sys/fs/cgroup /dev/mmcblk0p1 63503 20755 42748 33% /boot /dev/ram1 3963 30 3729 1% /mnt/ramdisk tmpfs 94776 0 94776 0% /run/user/1000 tmpfs 94776 0 94776 0% /run/user/1001 ...получает данные от малины. Следует заметить, что на малине сейчас не установлен Apache, а соответственно в скрипте изменены user и pasword. Зачем это? Это механизм автоконтроля и автоконфигурации кластера из пяти малин. Остаётся только установить пользователей с одним именем на каждую из малин... и написать пакет скриптов. А TELNET теперь и не понадобится. Пока криво конечно... НО!
Лучше всё-таки сделать авторизацию по ключу. Меньше проблем в настройке. И дыр в безопасности не будет -- первое: пароль можно перехватить, второе: доверять кому попало не следует (это про параметр -oStrictHostKeyChecking=no). Хотя, если руками прописать ключ хоста в known_hosts, то этот параметр не понадобиться.
Вполне возможно так и будет... хоть и не решил пока. На все малины залит один образ с уже установленными элементами... и установлен один пользователь. Скрипт произведёт настройку... возможно, что в директорию .ssh он же и разместит требуемые ключи. Хотя если всё в локальной сети... хотелось бы гибкость, когда идентичные скрипты на устройствах будут контролировать работоспособность соседних устройств. Это часть начальной задачи. Поиск и идентификация по IP в локальной сети уже практически проработана... и для автоконфигурации надо только проработать правила. Вот SSH и тебуется... да и пользователь ведь не ROOT, а обычный с обычным доступом только к своим рессурсам.
В целях безопасности root'у по ssh доступ давать не рекомендуется. Для решения административных задач заводится пользователь аналогичный обычным, которому разрешается выполнение команд через sudo или повышение привилегий через su. Остальным пользователям sudo и su запрещается. И если решитесь на ключи, то генерируйте ключи с длиной 4 кбит (большей длины наверно будет уже лишним, но и более устойчивым к взлому), т.к. при использовании ключей менее 2 кбит ssh соединение может быть взломано в момент авторизации (про пароли уж молчу).
Это кому что надо. Если к Малинкам Пи есть физический доступ, как бы бдеть на счёт прав рута и взлома пароля нет смысла. Будет достаточно того, что к терминалу устройства нет свободного доступа у случайных пользователей.
Кстати про взлом паролей... пользуюсь fail2ban (спокойно ставится по #aptitude install fail2ban). Первые три попытки авторизации можно друг за другом, а остальные повторить можно, но довольно не скоро.
