Вопросы Теги

Я делаю plink (ssh) → sudo → удаленное копирование файлов в среде X11, и это не удается

ПРОБЛЕМА РЕШЕНА!!!! РЕШЕНИЕ:

Вы должны использовать параметр ядра findiso для процесса загрузки, чтобы найти файл iso на полпути к загрузке корневой файловой системы. Смотрите мои последние и рабочие записи grub.config ниже:

ПРИМЕЧАНИЕ. :Я ПЕРЕМЕСТИЛ СВОИ ISO-ФАЙЛЫ в папку /boot -isos/ только для того, чтобы протестировать superGrub. Но они могут быть где угодно. Просто убедитесь:

1. to give correct path name to the iso file
2. MUST USE findiso kernel parameter to let boot process find the iso file. Else it will NOT work.

Моя текущая структура каталогов на USB теперь выглядит следующим образом:

USB STICK ->
/boot (folder that holds GRUB)
/boot-isos (folder that holds isos below)
- KALI iso file
- Parrot iso file
- Ubuntu iso file

menuentry "[loopback]Parrot-full-3.6_amd64" {
    set isofile='/boot-isos/Parrot-full-3.6_amd64.iso'
    loopback loop $isofile
    linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=parrot
    initrd (loop)/live/initrd.img
}


menuentry "[loopback]kali-linux-2017.1-amd64" {
    set isofile='/boot-isos/kali-linux-2017.1-amd64.iso'
    loopback loop $isofile
    linux (loop)/live/vmlinuz boot=live findiso=$isofile noconfig=sudo username=root hostname=kali
    initrd (loop)/live/initrd.img
}
0
23.07.2019, 02:17
1 ответ

Да, сообщение похоже от remoteserverC.

Вы используете plink для подключения как testadminк linuxserverB и запускаете там скрипт с sudo -u user_a. Таким образом, скрипт будет работать как user_a@linuxserverB.

Поскольку спецификация цели scp не включает имя пользователя, команда scp, встроенная в perl-скрипт, будет пытаться подключиться к user_a@remoteserverC. По-видимому, либо неправильное имя пользователя, либо соответствующие ключи недоступны для этого (, либо в соединении доступно больше ключей, чем количество попыток аутентификации, разрешенных remoteserverC ).

Первый вопрос: имеет ли user_a@remoteserverCсмысл? Если user_aне существует на удаленном сервере C, то ваша спецификация источника копирования должна включать имя пользователя для удаленного сервера C, например some_other_user@remoteserverC.com:/a/b/c/filetocopy.txt.

Если это не решит проблему, проверьте журналы на удаленном сервере C и выясните, какие попытки аутентификации отклоняются и почему. Возможно, пользовательский файл ~/.ssh/authorized_keysнедостаточно защищен на удаленном сервере C, и в результате демон сервера sshdигнорирует список авторизованных ключей. Файл authorized_keysнужно защитить, чтобы в него мог писать только сам пользователь (или root ). Если это так, в сообщении журнала должен быть указан файл или каталог, права доступа sshdкоторого неудовлетворительны.

0
28.01.2020, 03:25

Теги

Похожие вопросы