передающие сбои агента ssh с “Не могли открыть соединение с Вашим агентом аутентификации”
Я предполагаю, что Ваш единственный хост копирования хоста, не в VM как Aaron правильно поместил проблемы по поводу VM's.
Я протестировал эти сценарии и только путем установки роли Hyper-V, Вы не замедлите сервер. Для доказательства этой теории, Вы могли удалить роль, или перезагрузить поле и протестировать пропускную способность перед добавляющей ролью. Я подозреваю что-то не, связанный Hyper-V виноват. Если Вы имеете к regedit после новой установки затем, Вы, вероятно, спускаетесь по неправильному пути.
Если это не драйверы, затем они та же версия ОС? SMB является протоколом копирования файла с Windows и был обновленным достижением в 2008 и снова в 2008 R2. Необходимо удостовериться, что тестирование допустимо на основе того, что ОС включены. Если Win2000/2003 будет вовлечен в копию файла, то передачи будут намного медленнее.
Вы принимаете шпиндели диска во внимание? Более новые драйверы SAS быстрее во вводе-выводе затем более старый SCSI или SATA. Количество дисков и RAID конфигурирует вопрос в копии файла также. Фрагментация может также играть роль при использовании серверов, которые были вокруг некоторое время.
Вы, возможно, отформатировали диски на новом сервере с неправильно выровненными дисками. Google может помочь Вам узнать, как проверить, ли Ваше дисковое форматирование выровненное, который, если это не, может влиять на производительность как Вы, видят.
Я публикую это здесь, потому что потратил много времени, пытаясь найти решение с помощью Google, читал страницы руководства и консультировался с популярной книгой по SSH, но все безрезультатно.
Ключом к обнаружению проблемы было тщательное изучение вывода отладки.
debug1: Remote: Agent forwarding disabled: mkdtemp() failed: Permission denied
Промежуточная машина - это виртуальный сервер (RHEL 6.4), размещенный у облачного провайдера, использующего стек AWS. По причинам, которые я не могу объяснить, вот какие права доступа к каталогу / tmp были установлены на:
drwxr-x--- 19 727 727 4096 Nov 28 05:30 tmp
Гребание через / etc / passwd Я не смог найти пользователь с идентификатором 727.
Подобное исправление разрешений решило мои проблемы:
sudo chown 0:0 /tmp
sudo chmod 1777 /tmp
Может ли кто-нибудь говорить об особом владельце каталога / tmp ?
Для тех, кто ищет весь процесс для пересылки ключей и получения журналов отладки вместе с исправлениями, это выглядит следующим образом:
Создайте ~/.ssh/config
Host [IP of HOST]
ForwardAgent yes
Запустите ssh-agent
eval "$(ssh-agent)"
Добавьте ключ, который вы хотите перенаправить агенту ssh:
ssh-add [path to key if there is one]/[key_name].pem
Войдите на удаленный хост:
ssh -A -v [user]@[hostname]
просмотрите журналы отладки по ssh
debug1: Remote: Agent forwarding disabled: mkdtemp() failed: Permission denied
Last login: Tue Nov 10 22:57:07 2020 from 10.100.28.239
во время входа в удаленную машину просмотрите разрешение tmp.
убедитесь, что у пользователя есть разрешение на доступ к папке tmp
ls -la /tmp/
sudo chown 0:0 /tmp
sudo chmod 1777 /tmp
моя проблема заключалась в том, что я создал пользователя для запуска сервера, и у этого пользователя не было разрешений, необходимых для временной папки. Я не хотел использовать root, так как это не лучшая практика. Исправление было таким же. :)