Как он говорит, записывание обратно таблицы разделов должно установить корректные флаги - однако должна быть причина, которую они изменили на 0 в первом месте - можно найти, что необходимо выполнить fsck на разделе - и даже затем диск не может быть восстанавливаемым.
Похоже, когда autossh переходит в фоновый режим (параметр -f), он меняет рабочий каталог, что означает относительный пути больше не работают. Или более конкретно: введя абсолютный путь к вашему файлу идентификаторов , вы, вероятно, добьетесь успеха.
Я воссоздал сценарий, создав ключ без пароля в расположении не по умолчанию:
~/$ mkdir test
~/$ cd test
~/test$ ssh-keygen -f test_id_rsa
Я просто дважды нажимаю Enter, чтобы сгенерировать ключ, который не защищен паролем.
Я скопировал новый ключ на свой сервер (который в настоящее время позволяет аутентификацию по паролю):
~/test$ ssh-copy-id -i test_id_rsa user@server
Сначала я подтвердил, что ключ работает с обычным ssh, затем использовал autossh, как и вы:
~/test$ ssh -i test_id_rsa user@server
~/test$ autossh -M 13000 -N -i test_id_rsa user@server
^C
Они оба работали нормально, поэтому я воссоздал вашу проблему:
~/test$ autossh -f -M 13000 -N -i test_id_rsa user@server
Это не сработало, и следующее было написано в / var / log / syslog
:
autossh [2406]: ssh преждевременно завершился со статусом 255; autossh exiting
Если изменить путь к ключевому файлу на абсолютный, это сработало:
~/test$ autossh -f -M 13000 -N -i /home/user/test/test_id_rsa user@server
Нет ошибок в / var / log / syslog
.
Не знаю, что происходит с параметром -f, но вы также можете не использовать его:
nohup autossh -M 33201 -N -f -i myIdFile -R 33101:localhost:22 autossh@myhost.com &
Добавьте следующие параметры в SSH, чтобы обойти «Вы уверены, что хотите продолжить соединение (да / нет)?»
-o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no
Последняя команда будет в следующем формате:
autossh -f -M $BASE_PORT -N -R $LOCAL_PORT:$LOCALHOST:$REMOTE_PORT $USER@$SERVER -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no