Я предполагаю, что вы входите на host1 как MyUser, а затем используете su -
или sudo
для переключения на root. Оба этих метода удаляют большинство или все переменные среды при переходе от одной учетной записи пользователя к другой в целях безопасности.
(Например, если вам было разрешено запускать только определенные команды от имени пользователя root с помощью sudo
, вы могли бы обойти это ограничение с помощью злонамеренной настройки переменной LD_PRELOAD
или LD_LIBRARY_PATH
, если все переменные среды передавались автоматически.)
Когда вы используете агент аутентификации SSH, для вашего сеанса SSH на host1 создается одна важная переменная среды :SSH_AUTH_SOCK
. Когда вы подключаетесь по SSH к серверу как MyUser, наличие этой переменной сообщает SSH-клиенту host1, что доступно соединение с агентом аутентификации. Переменная указывает на сокет Unix, обычно расположенный в каталоге /tmp, который доступен только его владельцу. Этот сокет подключен к процессу sshd
, который обрабатывает ваше подключение с вашей рабочей станции к host1 и, в конечном счете, к агенту аутентификации PuTTY на вашей рабочей станции.
Если эта переменная не передается при su
или sudo
переходе от одной учетной записи пользователя к другой, клиент SSH не сможет использовать соединение агента аутентификации после перехода. В результате ему необходимо запросить парольную фразу, чтобы расшифровать любые доступные закрытые ключи самостоятельно.
Кроме того, если вы перейдете к другой учетной записи, отличной от -root, права доступа к файлу в сокете и каталоге, в котором он содержится, не позволят вам использовать его, если вы не предпримете шаги, чтобы явно разрешить его перед переходом к другому пользователю.. (Это не проблема при переходе на root, потому что root может получить доступ ко всему.)
Я подозреваю, что ваша система сочетает в себе 64 -битный процессор Atom с 32 -битным UEFI; в прошлом это было обычным явлением для систем Atom. Это вызывает проблемы для ряда дистрибутивов, и Ubuntu уже давно поддерживает этот сценарий. Debian 7 не может быть установлен в 64-разрядном -битном режиме на этих системах, поэтому в Интернете много заявлений о том, что он не работает; однако смешанный режим поддерживается, начиная с Debian 8 , поэтому установка текущих выпусков Debian должна быть возможной без проблем.
Загрузите установочный образ multi -Debian 10 , выберите вариант установки 64 -бит, и программа установки установит 64 -бит Debian с 32 -бит погрузчик.
Еще одна потенциальная проблема, проявляющаяся в виде зависаний во время работы графического процессора:http://bugzilla.kernel.org/show_bug.cgi?id=109051(— печально известная intel_idle.max_cstate=1
аппаратная ошибка ).