Дружок, а iptables ты должным образом настроил??

>>в каких-либо загрузочных скриптах?

Если ставил из пакета, то всё должно работать их коробки

sudo /etc/init.d/sshd start ?

> Из панели управления могу только ребутить сервер и смотреть/редактировать файлы.
Значит, при помощи cron'а можно выполнять некоторые простые команды.
Начнём с iptables-save, netstat -nlp и ps aux.

если поможет:
sudo update-rc.d sshd default - пропишет запуск sshd.

До настройки iptables дойти ещё не успел. SSHD стандартный, с хостерского образа. aptitude update & upgrade было сделанно сразу. Установлен только банальный LAMP набор.

Попробовал добавить в crontab скрипт, не помогло:

Jun 12 23:45:01 /USR/SBIN/CRON[13966]: (root) CMD (/bin/ps aux >> /tmp/1f.txt)
Jun 12 23:45:01 /USR/SBIN/CRON[13984]: (root) CMD (/etc/init.d/sshd start)
Jun 12 23:45:01 /USR/SBIN/CRON[13973]: (CRON) error (grandchild #13984 failed with exit status 127)

Такое чувство, что sshd не может запуститься. На всякий случай прикладываю логи (auth.log), во время форса в них хоть что-то появилось:

Jun 12 23:53:01 site1 CRON[21709]: pam_unix(cron:session): session closed for user root
Jun 12 23:53:01 site1 CRON[21715]: pam_unix(cron:session): session closed for user root
Jun 12 23:54:01 site1 CRON[22074]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 12 23:54:02 site1 CRON[22077]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun 12 23:54:02 site1 CRON[22074]: pam_unix(cron:session): session closed for user root
Jun 12 23:54:02 site1 CRON[22077]: pam_unix(cron:session): session closed for user root

ps aux пустоват: http://pastebin.com/bYQ0a1ca

Так ты под рутом ломишься что ли?
А ты в курсе, что так делать нельзя и в sshd_config специальная опция PermitRootLogin установленная в значение no не позволяет таким админам локалхоста как ты создавать угрозы безопасности как на твоём сервере, так и на площадке хостера в целом???

Это не shared-хостинг, это vps. Про рута знаю, просто сейчас там дефолтный конфиг - в нем рут включен, должно пускать. Не из под рута тоже не работает... ну и я думаю, раз даже соединение не может установиться, sshd скорее всего не запущен и ему без разницы кому приглашение давать.

Ну ладно, ладно. AITap выше уже написал, что надо увидеть. Кто какие порты слушает, полную таблицу процессов (кстати у тебя xinetd запущен - показывай его конфиг), настройки файрвола.

/etc/passwd случайно не редактировал ручками?

Забыл про порты, но в них тоже все хорошо.

netstat -nlp

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      513/sendmail       
tcp        0      0 127.0.0.1:3306          0.0.0.0:*               LISTEN      959/mysqld             
tcp        0      0 127.0.0.1:587           0.0.0.0:*               LISTEN      601/sendmail          
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1139/apache2             
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node    Path
unix  2      [ ACC ]     STREAM     LISTENING     364379497  /var/run/mysqld/mysqld.sock
unix  2      [ ACC ]     STREAM     LISTENING     364379870  /var/run/sendmail/mta/smcontrol

xinetd.conf

# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{

# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
# log_type = SYSLOG daemon info

	disable		= yes
}

includedir /etc/xinetd.d

# default: off
# description: An RFC 868 time server. This protocol provides a
# site-independent, machine readable date and time. The Time service sends back
# to the originating source the time in seconds since midnight on January first
# 1900.
# This is the tcp version.
service time
{
	disable		= yes
	type		= INTERNAL
	id		= time-stream
	socket_type	= stream
	protocol	= tcp
	user		= root
	wait		= no
}                                                                               

# This is the udp version.
service time
{
	disable		= yes
	type		= INTERNAL
	id		= time-dgram
	socket_type	= dgram
	protocol	= udp
	user		= root
	wait		= yes
}                                                                               

Нет, а зачем? Там ведь и паролей то нету :)

Системные логи смотрел? Если там нет ничего, попробуй запустить в кроне с выхлопом в standard error
/usr/sbin/sshd -e 2>/tmp/sshd_error

Ох, [code] /bin/sh: /usr/sbin/sshd: No such file or directory [/code] Как такое вообще могло случиться... и где взять бинарник?

ОхЛОЛ :D

Пинай поддержку, которая собирала пакеты. В системе поищи всё-таки sshd.
locate sshd или find / -name sshd
Не найдёшь-собирай.

а переустановить тупо пакетик ssh и openssh-server не помогло?

>Так ты под рутом ломишься что ли?

не вижу проблемы, если нормальный пароль или используются ssh ключи.

а ты можешь посмотреть стартовал ли у тебя ssh демон ?
ps auxw | grep sshd

Перепроверь конфиг, пинай поддержку, выпей чаю, успокойся :) Может тупо технические работы? :)

Технические работы, в процессе которых исчезают бинарники? Возможно он просто в другое место установлен, нет?

whereis sshd

упс. попутал с ТС'ом..

ну, если я правильно понимаю ситуацию, у него кроме доступа к фс через кривой веб-интерфейс сейчас ничего нет и командочку он не выполнит.

>Технические работы, в процессе которых исчезают бинарники? Возможно он просто в другое место установлен, нет?

На внешнем файрволле порт ssh закрыли например :)

Пичалька..

Ну он же как-то брал логи, какие-то команды выполнял.. Подождем ответа ТСа

Всем спасибо. Хостер проснулся и пофиксил.

Проблемы были с их виртуальными машинами. Как я понял нода OpenVZ имеет некие базовые общие пакеты для всех хостов, как sh/sshd/wget, и вот с ними что-то у них случилось.