sshfs «Сброс соединения одноранговым узлом» с файлом идентификации
Я полагал, что su, вероятно, открыл /dev/tty, изменил настройки драйвера терминала на отсутствие эха, а затем прочитал из файлового дескриптора /dev/tty.
Чтобы проверить это убеждение, я запустил strace -o su.out su - на своем ноутбуке Arch linux. Соответствующая часть вывода strace:
ioctl(0, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0
write(2, "Password: ", 10) = 10
read(0, "hahanotthis\n", 511) = 7
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0
Я не был на 100% неправ. su действительно читает из stdin, но он отключает эхо на stdin с помощью управления терминалом ioctl(). После того как я ввожу пароль, su снова включает эхо, опять же с помощью системного вызова ioctl().
Я знаю, что некоторые другие программы, в частности ftp клиент, используют /dev/tty для чтения паролей, что означает, что вы не можете поместить пароль в командную строку или в "here document", вы должны использовать некоторые махинации.
Может быть много ошибок в синтаксисе и еще много других в связи.
Лучшее решение - включить подробный режим с помощью переключателя
-o debug
, и в моем случае я вижу проблему с «абсолютным путем к файлу идентификации»
no such identity: {{identity_file}}: No such file or directory
Permission denied (publickey).
read: Connection reset by peer
, поэтому моя полная команда выглядит так
sshfs {{user_name}}@{{server_ip}}:/ /mnt/{{server_ip}} -o "IdentityFile={{absolute_path}},port={{port_number}}" -o debug
Возможно, это проблема тайм-аута. Такое сообщение ("read: Connection reset by peer") указывает на то, что соединение было успешным (команда ssh в порядке), но внезапно завершилось: клиент ssh послал что-то и в ответ получил TCP-кадр RST, который означает "ничего не посылайте, канал закрыт".
В основном это происходит из-за того, что брандмауэр отключает вас за неактивность (но у этого могут быть и другие причины, например, слишком много соединений за небольшой промежуток времени; брандмауэры в наши дни очень чувствительны).
Чтобы избежать проблем с таймаутом, используйте опции ssh TCPKeepAlive или ServerAliveInterval/ ServerAliveCountMax. См. этот вопрос.