Назад | Перейти на главную страницу

Отправка учетных данных и команд с помощью сценария оболочки через telnet

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

Я также запускаю команду с устройства с ограниченным набором ресурсов, поэтому я не могу добавить что-то вроде Expect.

Я безрезультатно пробовал следующее:

#!/bin/ksh
( sleep 2
  echo username
  sleep 5
  echo password
  sleep 5
  echo show whoison ) | telnet 192.168.1.10

Он успешно вводит имя пользователя и не вводит пароль. "\ n" тоже не сработало.

Я пробовал SSH раньше, но оболочка, которую использует устройство, не позволяла мне передавать команды (я пробовал ssh user @ host 'show whoison')

Для автоматического входа через telnet вы действительно хотите использовать ожидать

НОТА: На самом деле, вы тоже не хотите использовать telnet. Сейчас альтернативы SSH доступны почти для каждой платформы, включая маршрутизаторы Cisco.

SSH позволяет

  1. Вход без пароля через аутентификацию с открытым ключом
  2. Более легкое выполнение удаленных команд
  3. Передача возвращаемых значений через скрипты
  4. Безопасная среда с непрерывным шифрованием
  5. Аутентификация агента, так что пароли могут использоваться для ключей, но ключи хранятся в памяти при однократном использовании.

Если у вас есть возможность использовать SSH, используйте его. Если нет, используйте expect.

первый. не. это небезопасно.

второе - только если надо ...

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

( echo someLogin;  echo somePass; echo reboot 0;  echo reboot 0 ; sleep 3; ) | telnet 192.168.0.141

вы также можете использовать ожидать

Я перешел на ваш вопрос, чтобы порекомендовать ожидать, но потом увидел вашу ограниченность. Извините, но Telnet нельзя использовать так, как вы хотите. Ты пробовала netcat или вы не можете установить что-нибудь?

Кроме того, telnet безопасен только для доверенного локального трафика; в противном случае используйте SSH.

Помогает ли использование параметра -t для ssh вообще с проблемой неработающих команд при использовании ssh?