- Печать
Страницы: [1] Вниз
Тема: не могу подсоединится по SSh (Прочитано 1391 раз)
0 Пользователей и 1 Гость просматривают эту тему.

dj—alex
-bash: /etc/bash_completion: Ошибка ввода/вывода
-bash: /etc/bash.bashrc: Ошибка ввода/вывода
через scp и sftp выдает туже фигню…
подскажите что сделать
есть возможность зайти в серверную,но всего 1 раз.
2 будетнескоро.

podkovyrsty
Шаг за шагом можно достичь цели.

dj—alex
тупо перезапустилмашину — всёзаработало.
точно надо проверять?

podkovyrsty
Вам по английски написать?
Запустите fschk
Шаг за шагом можно достичь цели.

Denis89
Привет всем!
Поставил Ubuntu 10 версию — в надежде облегчить работу в сети- в частности подключить свой N900 по ssh .нашел в меню- программу для этого — ввожу root@айпи телефона, логин и пароль, — жму коннект — просит пароль- какой?? дело в том что программа winSCP с этими же входными данными без проблем подключает меня к N900 — правда -в программе я еще ввожу специальный «приват — ключ» — который генерируется один раз и сохраняется на диске.
Пожалуйста- подскажите, где копать ? ) что за дополнительный пароль спрашивает программа? ( название программы забыл- но она в стандартном меню убунты)
Спасибо.

podkovyrsty
Дык а ключ то ей кто давать будет? (:
А пароль она просит от учетной записи root
Шаг за шагом можно достичь цели.

Denis89
спасибо , но не помогло , правда. Вводил пароль , что при запуске требует- все равно пишет — логин фэйлд ( Программа называет bareFTP версия 0.3.4.

podkovyrsty
если вы с убунты пробуете, попробуйте для начала просто по ssh зайти
откройте терминал и наберите
ssh -v root@ip_адрес_нокии
Шаг за шагом можно достичь цели.
- Печать
Страницы: [1] Вверх
Re: Забавный баг с удалённой машиной. Что с ней случилось и как исправить?
А точно в логах пусто?
Если в /var/log/everything/current есть свежие записи, то, судя по всему, с самой FS всё ок:
…
Тьфу, я тормоз. Не на той машине смотрел. dmesg тут, действительно, чист. А вот в everything такое:
Oct 18 21:06:52 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069980)
Oct 18 21:06:52 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 e8 79 3e 00 00 08 00
Oct 18 21:06:52 [kernel] mptscsih: ioc0: WARNING - TM Handler for type=1: IOC Not operational (0xffffffff)!
Oct 18 21:06:52 [kernel] mptscsih: ioc0: WARNING - Issuing HardReset!!
Oct 18 21:06:52 [kernel] mptbase: ioc0: Initiating recovery
Oct 18 21:06:52 [kernel] mptbase: ioc0: WARNING - Unexpected doorbell active!
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff8801ff069480, mf = ffff88022e204280, idx=35
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff88022e6f4980, mf = ffff88022e206880, idx=81
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff88022e6f4880, mf = ffff88022e208580, idx=bb
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff8801ff069180, mf = ffff88022e209f00, idx=ee
Oct 18 21:06:52 [kernel] sd 4:0:0:0: mptscsih: ioc0: completing cmds: fw_channel 0, fw_id 0, sc=ffff8801ff069980, mf = ffff88022e20fc00, idx=1a8
Oct 18 21:07:52 [kernel] mptbase: ioc0: WARNING - ResetHistory bit failed to clear!
Oct 18 21:07:52 [kernel] mptbase: ioc0: ERROR - Diagnostic reset FAILED! (ffffffffh)
Oct 18 21:07:52 [kernel] mptbase: ioc0: WARNING - NOT READY!
Oct 18 21:07:52 [kernel] mptbase: ioc0: WARNING - Cannot recover rc = -1!
Oct 18 21:07:52 [kernel] mptscsih: ioc0: WARNING - TMHandler: HardReset FAILED!!
Oct 18 21:07:52 [kernel] mptscsih: ioc0: task abort: FAILED (sc=ffff8801ff069980)
Oct 18 21:07:52 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff88022e6f4880)
Oct 18 21:07:52 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 e8 f4 c6 00 00 08 00
Oct 18 21:07:52 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022e6f4880)
Oct 18 21:08:02 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff88022e6f4880)
Oct 18 21:08:02 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
Oct 18 21:08:02 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022e6f4880)
Oct 18 21:08:02 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff88022e6f4980)
Oct 18 21:08:02 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 ed 30 76 00 00 08 00
Oct 18 21:08:02 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022e6f4980)
Oct 18 21:08:12 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff88022e6f4980)
Oct 18 21:08:12 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
Oct 18 21:08:12 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff88022e6f4980)
Oct 18 21:08:12 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069480)
Oct 18 21:08:12 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 f0 68 36 00 00 08 00
Oct 18 21:08:12 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff8801ff069480)
Oct 18 21:08:14 [named] client 94.25.128.68#7031: query (cache) 'www.goodfly.ru/A/IN' denied
Oct 18 21:08:15 [named] client 94.25.208.69#33011: query (cache) 'www.goodfly.ru/A/IN' denied
Oct 18 21:08:22 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069480)
Oct 18 21:08:22 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
Oct 18 21:08:22 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff8801ff069480)
Oct 18 21:08:22 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069180)
Oct 18 21:08:22 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 fa 39 de 00 00 08 00
Oct 18 21:08:22 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff8801ff069180)
Oct 18 21:08:32 [kernel] mptscsih: ioc0: attempting task abort! (sc=ffff8801ff069180)
Oct 18 21:08:32 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x0: 00 00 00 00 00 00
Oct 18 21:08:32 [kernel] mptscsih: ioc0: task abort: SUCCESS (sc=ffff8801ff069180)
Oct 18 21:08:32 [kernel] mptscsih: ioc0: attempting target reset! (sc=ffff8801ff069980)
Oct 18 21:08:32 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 e8 79 3e 00 00 08 00
Oct 18 21:08:32 [kernel] mptscsih: ioc0: target reset: FAILED (sc=ffff8801ff069980)
Oct 18 21:08:32 [kernel] mptscsih: ioc0: attempting bus reset! (sc=ffff8801ff069980)
Oct 18 21:08:32 [kernel] sd 4:0:0:0: [sda] CDB: cdb[0]=0x2a: 2a 00 03 e8 79 3e 00 00 08 00
Oct 18 21:08:35 [named] client 83.169.185.33#46884: query (cache) 'goodfly.ru/A/IN' denied
Oct 18 21:08:35 [named] client 83.169.185.33#43016: query (cache) 'goodfly.ru/A/IN' denied
Oct 18 21:08:43 [kernel] mptscsih: ioc0: bus reset: FAILED (sc=ffff8801ff069980)
Oct 18 21:08:43 [kernel] mptscsih: ioc0: attempting host reset! (sc=ffff8801ff069980)
Oct 18 21:08:43 [kernel] mptbase: ioc0: Initiating recovery
Oct 18 21:08:43 [kernel] mptbase: ioc0: WARNING - Unexpected doorbell active!
Oct 18 21:08:46 [named] zone wikilinks.ru/IN: refresh: retry limit for master 85.30.226.178#53 exceeded (source 0.0.0.0#0)
Oct 18 21:08:46 [named] zone wikilinks.ru/IN: Transfer started.
Походу, проблема с контроллером. Странно только, что /home работает, а другие разделы на том же винте и контроллере — нет…
★★★★★
(19.10.09 11:07:01 MSD)
- Ссылка
Ошибка при копировании (!)
Модератор: SLEDopit
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Ошибка при копировании
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов и Midnight Commander выдает ошибки «Не возможно сменить владельца целевого файла. Ошибка удаленного вводавывода 121» и потом вторая «Невозможно сменить режим доступа целевого файла»
Сходил до сервера воткнул флешку, примонтировал и все спокойно перекинул. Но хотелось бы разобраться в чем проблема данная.
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 12.11.2014 09:31
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов
КУДА копировали?
Zloydog писал(а): ↑
11.11.2014 17:32
Но хотелось бы разобраться в чем проблема данная.
проблема в том, что какие-то атрибуты файлов в удалённой системе не поддерживаются.
Zloydog писал(а): ↑
11.11.2014 17:32
воткнул флешку
это с FAT, да? Так там никакие атрибуты не поддерживаются, только временной штамп, и то 32х битный. Вот вы их все успешно потеряли.
Hint: что-бы не потерять атрибуты(основные, такие как права доступа и владельца), используйте tar-архив для передачи, ну или rsync over ssh тоже хорошо работает.
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 12.11.2014 09:42
drBatty писал(а): ↑
12.11.2014 09:31
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов
КУДА копировали?
Zloydog писал(а): ↑
11.11.2014 17:32
Но хотелось бы разобраться в чем проблема данная.
проблема в том, что какие-то атрибуты файлов в удалённой системе не поддерживаются.
Zloydog писал(а): ↑
11.11.2014 17:32
воткнул флешку
это с FAT, да? Так там никакие атрибуты не поддерживаются, только временной штамп, и то 32х битный. Вот вы их все успешно потеряли.
Hint: что-бы не потерять атрибуты(основные, такие как права доступа и владельца), используйте tar-архив для передачи, ну или rsync over ssh тоже хорошо работает.
Копировал с со шлюза (Debian) на Samba файлообменник (debian). Архив создал 1.tar.gz
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 12.11.2014 10:04
Zloydog
очень плохая идея копировать файлы удалённо от/в root-доступ. Это РЕШЕТО.
Так никто не делает, потому и не тестирует никто. А если вы копируете обычным пользователем, то владелец автоматически меняется на получателя. Причём AFAIK в mc всё вроде-бы менялось без ошибок.
Ваша проблема скорее всего в том, что пользователи разные, и mc почему-то хочет сменить владельца файла на отправителя, как оно на локальной системе.
А зачем вы используете именно SMB соединение, ведь оно предназначено лишь для Windows™ систем? Нельзя-ли использовать OpenSSH?
Ещё вопрос: надеюсь вы применяете «SMB соединение», а не «FiSH»?
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 12.11.2014 13:45
drBatty писал(а): ↑
12.11.2014 10:04
Zloydog
очень плохая идея копировать файлы удалённо от/в root-доступ. Это РЕШЕТО.Так никто не делает, потому и не тестирует никто. А если вы копируете обычным пользователем, то владелец автоматически меняется на получателя. Причём AFAIK в mc всё вроде-бы менялось без ошибок.
Ваша проблема скорее всего в том, что пользователи разные, и mc почему-то хочет сменить владельца файла на отправителя, как оно на локальной системе.
А зачем вы используете именно SMB соединение, ведь оно предназначено лишь для Windows™ систем? Нельзя-ли использовать OpenSSH?
Ещё вопрос: надеюсь вы применяете «SMB соединение», а не «FiSH»?
То есть перекидывать из под пользователя? Ну вообще я по SSH и так цепляюсь к серверам..Физически их нет рядом. да smb. Я пробовал менял у архива владельца и группу на те что на папку в которую скидваю тоже не хочет.. мне конечно не лень раз в неделю дойти до сервера подцепить флешку и бекап сделать, но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
-
Bizdelnick
- Модератор
- Сообщения: 19763
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Ошибка при копировании
Сообщение
Bizdelnick » 12.11.2014 14:30
Zloydog писал(а): ↑
12.11.2014 13:45
хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
Ну не через mc же бекапы будут перекидываться? Обычным cp пробовали копировать?
Пишите правильно:
| в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
drBatty
- Сообщения: 8735
- Статус: GPG ID: 4DFBD1D6 дом горит, козёл не видит…
- ОС: Slackware-current
- Контактная информация:
Re: Ошибка при копировании
Сообщение
drBatty » 13.11.2014 16:20
Zloydog писал(а): ↑
12.11.2014 13:45
То есть перекидывать из под пользователя?
естественно. Для бекапов проще из под рута(хотя и опасно), НО: обязательно в простого пользователя. Этому удалённому пользователю можно назначить права write only, а также, как я их называю, «янтарные каталоги» сделать, это в ext4 атрибут append only, что-бы бекап нельзя было удалить с другой системы.
Zloydog писал(а): ↑
12.11.2014 13:45
Ну вообще я по SSH и так цепляюсь к серверам.
дык и смысл?
Zloydog писал(а): ↑
12.11.2014 13:45
но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
я не пойму: зачем вам вообще SMB и mc в данной задаче? Аж две лишних сущности.
-
Zloydog
- Сообщения: 17
- ОС: Linux Debian
Re: Ошибка при копировании
Сообщение
Zloydog » 14.11.2014 11:30
drBatty писал(а): ↑
13.11.2014 16:20
Zloydog писал(а): ↑
12.11.2014 13:45
То есть перекидывать из под пользователя?
естественно. Для бекапов проще из под рута(хотя и опасно), НО: обязательно в простого пользователя. Этому удалённому пользователю можно назначить права write only, а также, как я их называю, «янтарные каталоги» сделать, это в ext4 атрибут append only, что-бы бекап нельзя было удалить с другой системы.
Zloydog писал(а): ↑
12.11.2014 13:45
Ну вообще я по SSH и так цепляюсь к серверам.
дык и смысл?
Zloydog писал(а): ↑
12.11.2014 13:45
но хотелось бы автоматизировать все, чтобы он сам перекидывал бекапы на сервер самбы
я не пойму: зачем вам вообще SMB и mc в данной задаче? Аж две лишних сущности.
Так и пробовал кидать из под рута на пользователя..
В смысле смысл? А как еще цепляться то к серверам с винды в кабинете?) в кабинете винда стоит, а сервера в другом конце здания там Linux
Да вот решил МС попробовать чтобы удаленно скопировать, так то все время ножками до сервером и накопитель цепляю)
Или так попробовать, через «scp -r user@server1:/var/www/html/ /backup»?
-
Bizdelnick
- Модератор
- Сообщения: 19763
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: Ошибка при копировании
Сообщение
Bizdelnick » 14.11.2014 12:05
Zloydog писал(а): ↑
14.11.2014 11:30
Или так попробовать, через «scp -r user@server1:/var/www/html/ /backup»?
Да хотя бы так. Хотя лучше, конечно, rsync, если всё время в одно и то же место копируете.
Пишите правильно:
| в консоли вку́пе (с чем-либо) в общем вообще |
в течение (часа) новичок нюанс по умолчанию |
приемлемо проблема пробовать трафик |
-
BigBrother
- Сообщения: 436
- Статус: ¯_(ツ)_/¯
- ОС: linux based
Re: Ошибка при копировании
Сообщение
BigBrother » 23.11.2014 23:47
Zloydog писал(а): ↑
11.11.2014 17:32
Ситуация такая — подключился со шлюза на котором стоит Debian к самбе с помощью Midnight Commander через Shell. Стал перекидывать архивы бекапов и Midnight Commander выдает ошибки «Не возможно сменить владельца целевого файла. Ошибка удаленного вводавывода 121» и потом вторая «Невозможно сменить режим доступа целевого файла»
У mc есть опция «сохранять атрибуты» при копировании, попробуйте ее убрать.
При работе с SSH-соединениями нередко возникают разного рода ошибки. Это могут быть неполадки с соединением, авторизацией и т. д. Но есть также категория ошибок работы SSH, которые возникают на уровне протокола. Зачастую они имеют место быть при неумелом обращении, собственно, с самим протоколом SSH, например неправильное использование ключей шифрования. Но также могут быть и реальные неполадки, связанные с некорректной конфигурацией сервера или клиента SSH, что отражается на работе, в частности, протокола. Именно о таких неполадках, а также способах их выявления и устранения пойдёт речь в данной статье.
Содержание
- Какие бывают ошибки протокола SSH?
- Невозможность проверки ключа хоста
- Закрытие или сброс соединения
- Ошибка взаимодействия с хостом
- Заключение
Когда SSH-клиенты получают ошибки сброса соединений, неполадки с шифрованием, а также наблюдаются проблемы, связанные с «неизвестным» или «изменённым» хостом, то это, как правило, ошибки работы протокола SSH. Подобного рода неполадки часто возникают на этапе согласования зашифрованного соединения протоколом SSH посредством создания доверия между сервером и клиентом.
Невозможность проверки ключа хоста
При создании SSH-соединения протокол требует, чтобы стороны идентифицировали себя. Бывает так, что от сервера поступает следующая ошибка:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ECDSA key sent by the remote host is SHA256:doBAKL304WyMd8hnFc9a29r3nX9okS9BlrBJcHtuyNk. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending ECDSA key in /root/.ssh/known_hosts:14 ECDSA host key for 212.45.27.201 has changed and you have requested strict checking. Host key verification failed.
Эта ошибка может возникать по нескольким причинам:
- переустановка SSH-сервера и неполная его конфигурация;
- восстановление сервера из резервной копии;
- изменение IP-адреса сервера.
Очистка ключей хостов помогает решить эту проблему. Сами эти ключи хранятся на стороне клиента в файле ~/.ssh/known_hosts. Для очистки можно удалить все записи вручную. Либо можно использовать команду:
$ ssh-keygen -R host_ip
Эта команда попытается очистить соответствующую информацию о ключе хоста в файле known_hosts:
Host 123.123.123.123 found: line 14 /home/john/.ssh/known_hosts updated. Original contents retained as /home/john/.ssh/known_hosts.old
После этих действий можно попробовать снова выполнить подключение к серверу SSH.
Закрытие или сброс соединения
Бывает так, что соединение с SSH-сервером устанавливается, однако на этапе проверки ключей сбрасывается. Эта ошибка выглядит следующим образом:
Connection closed by 123.123.123.123 port 22
Часто такая ошибка возникает по нескольким причинам:
- программный сбой работы SSH-сервера или он не запущен;
- невозможность инициализировать соединение из-за отсутствия или недоступности ключей.
В данном случае необходимо проверить корректность заданной конфигурации сервера, проверить, запущен ли сам сервис. Если же с сервисом всё в порядке, то необходимо удостовериться, что SSH-ключи доступны для использования сервером. Если они отсутствуют, то необходимо их сгенерировать.
В данном случае необходимо проверить, есть ли в каталоге /etc/ssh набор файлов с именами sshd_host_*_key. Один из них должен иметь расширение *.pub.
В случае, если таких файлов нет, их нужно сгенерировать:
$ ssh-keygen -A ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
Теперь можно снова попытаться подключиться к серверу.
Ошибка взаимодействия с хостом
Для работы протокола SSH на этапе его инициализации генерируется общий закрытый ключ. Он создаётся на основе шифрования, которое согласуется при создании подключения между сервером и клиентом. Иногда на этом этапе возникают несоответствия и на стороне клиента это приводит к следующей ошибке:
Unable to negotiate with 123.123.123.123: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
Эта ошибка говорит о том, что сервер и клиент друг друга «не понимают». Это может быть вызвано следующими причинами:
- список шифрования сервера был изменён или сервер его не поддерживает;
- различные реализации (версии) протокола SSH на сервере и у клиента.
Как можно видеть, для устранения этой ошибки необходимо привести в соответствие версию клиента SSH, а также настроить шифрование для него. Если сервер использует устаревший метод шифрования, например SHA1, а у клиента по-умолчанию задействованы более совершенные методы, то это также будет вызывать ошибки протокола SSH. Для начала необходимо выяснить, действительно ли у сервера и клиента используются разные методы шифрования.
Для клиента использование методов шифрования можно настроить, используя опцию KexAlgorithms:
$ openssh -o KexAlgorithms=+diffie-hellman-group1-sha1 root@your_server_ip
Эта проблема не такая распространённая, поскольку возникает, когда версия реализации SSH-клиента более новая, чем используемая на сервере.
Заключение
В заключение нужно отметить, что рассмотренные неполадки и способы их устранения являются самыми распространёнными. Если для конкретного случая вышеописанное не помогает устранить проблему в работе SSH, то возможно, неполадка связана не с протоколом, а с другой областью, например с неполадками установления подключения по SSH.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Я не могу войти в свой sshfs, хотя я уверен, что соединение в порядке и место назначения существует. Каждая файловая операция завершается с ошибкой Input/output error .
Выводы sshfs:
$ sshfs -p 7292 server:/in/vm/dir ~/vm_dir -d
FUSE library version: 2.9.2
nullpath_ok: 0
nopath: 0
utime_omit_ok: 0
unique: 1, opcode: INIT (26), nodeid: 0, insize: 56, pid: 0
INIT: 7.20
flags=0x000017fb
max_readahead=0x00020000
INIT: 7.19
flags=0x00000011
max_readahead=0x00020000
max_write=0x00020000
max_background=0
congestion_threshold=0
unique: 1, success, outsize: 40
unique: 2, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2287
getattr /
unique: 3, opcode: OPENDIR (27), nodeid: 1, insize: 48, pid: 21063
unique: 3, success, outsize: 32
unique: 4, opcode: LOOKUP (1), nodeid: 1, insize: 57, pid: 2288
LOOKUP /.xdg-volume-info
getattr /.xdg-volume-info
unique: 2, success, outsize: 120
unique: 4, error: -2 (No such file or directory), outsize: 16
unique: 5, opcode: RELEASEDIR (29), nodeid: 1, insize: 64, pid: 0
unique: 5, success, outsize: 16