orcsweb является одним из лучших, которые я видел
Соединение, которому отказывают, предполагает, что sshd не работает. Попытайтесь выполнить sshd в режиме отладки из командной строки, чтобы видеть, существуют ли какие-либо сообщения об ошибках.
/usr/sbin/sshd -f /etc/ssh/sshd_config -D -d
Править:
Поскольку у Вас нет доступа к выполненному вышеупомянутой попыткой, помещая его в @reboot задание крона
Добавить
@reboot root /bin/mkdir -p -m0755 /var/run/sshd && /usr/sbin/sshd -f /etc/ssh/sshd_config -d &>/var/log/sshd_debug
в /etc/crontab
Ubuntu sshd требует, чтобы/var/run/sshd каталог существовал.
Можно попытаться добавить вход (трафик SSH) к правилам брандмауэра и перезапустить машину. Таким образом, необходимо смочь проверить, достигают ли пакеты, место назначения (следовательно sshd не работает).
Относительно этой части:
Я попытался сделать ссылку вручную с помощью ln-s/etc/init.d/ssh/etc/rc6.d/K09sshd и перезапустил сервер - это не решило проблему.
Runlevel 6 для перезагрузки, таким образом, это не то, чем Вы интересуетесь. И K в K09sshd для уничтожения.;-) Попытайтесь использовать решение, упомянутое odk, и посмотрите то, что происходит.
Я попытался сделать ссылку вручную с помощью ln-s/etc/init.d/ssh/etc/rc6.d/K09sshd и перезапустил сервер - это не решило проблему
Вы почти разобрались в нем. K* имена заставляют сервис быть остановленным. S* имена заставляют сервис быть запущенным.
rc6.d для управления подсистемами при вводе runlevel 6, что означает "перезагрузку".
Вы хотите запустить сервис в runlevels 3 (нормальный многопользовательский) и 5 (многопользовательский + X). Сделайте/etc/rc.3d/S90sshd и/etc/rc5.d/S90sshd символьные ссылки на/etc/init.d/sshd, Это должно заставить sshd быть запущенным на начальной загрузке системы.
Я понял. В первую очередь, большое спасибо всем, которые пытались помочь!
Для тех из Вас просматривающий архивы с подобной проблемой: начальная проблема состояла в том, что ссылки/etc/rc*.d/не были установлены, этот sshd не был выполнен на запуске. Мои многочисленные попытки, устраняющие это, были испорчены из-за пути ln работы: Когда я создаю выполнение ссылок
$ cd /repair/etc/rc3.d/ $ ln -s ../init.d/ssh S20sshd
и подобный для всего runlevels, ссылки создают, выглядел полностью прекрасным в режиме восстановления. Однако, когда мне наконец удалось входить в использовании взлома, описанного выше, я видел, что все связи были разорваны, т.е.
$ ls /etc/rc3.d/ ... lrwxrwxrwx 1 root root 10 2011-03-08 09:51 S20sshd -> init.d/ssh ...
таким образом, относительная ссылка теперь указывает где-нибудь неправильно.
Для фиксации его я добавил к верхней части другого init сценария строку (ВНИМАНИЕ: ВЗЛОМ!!!)
/etc/init.d/ssh start
который хорошо работал и позволил мне входить в. Я затем удалил все неработающие ссылки и создал новые, с помощью update.rc.
Снова большое спасибо за всю справку!
Вы записали, что имеете доступ для записи к файловой системе и можете изменить файлы и изменить правила брандмауэра.
Я предполагаю, что можно также выполнить перезагрузку системы в нормальный рабочий режим.
В таком случае я предлагаю при первом исключении, пытающемся заставить сервер SSH работать правильно, и представление простой удаленной оболочки на высоком порте, с помощью утилиты NetCat.
Вы должны:
nohup nc -l -p 1234 -e '/bin/bash' &
Таким образом, Вы получите простую удаленную корневую оболочку без аутентификации безотносительно (опасный!), с которым можно подключить удаленно использование netcat или telnet (nc your.server.address 1234
).
Просто не забудьте уничтожать его и удалять его из системных сценариев запуска, после того как Вы получаете свою работу сервера SSH!