loading...
SSH траблов пост
ПОдскажите плз, что это может быть
при попытке подцепиться к серверу через ssh он надолго задумывается после ввода пароля и отваливается. Резолвинг отключен
ssh -vvv показывает вот что:
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/mag/.ssh/id_dsa
debug3: no such identity: /home/mag/.ssh/id_dsa
debug1: Trying private key: /home/mag/.ssh/id_ecdsa
debug3: no such identity: /home/mag/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred:,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
[email protected]‘s password:
debug3: packet_send2: adding 48 (len 65 padlen 15 extra_pad 64)
debug2: we sent a password packet, wait for reply
Connection closed by 80.252.241.53
Это он чего???
1 предположение: запрещен (не разрешен) root-логин.
2 предположение: на той стороне шелом /bin/false или несуществующий.
А вообще надо смотреть, что в логах на той стороне
В логах сервера пусто
Логин разрешен, до недавнего времени все работало
через kvm рутом захожу влет
: п.2 больше похож на правду
: а максимальный дебг-левел если у sshd включить? обязан же он что-то в логи при таком раскладе прописать.
: ну судя по тому что он консолью заходит, то п.2 отпадает, п.1 зависит от, но скорее всего тоже не коннекшн бы закрывал, а отлуп авторизации делал.
и не мешало бы проверить файл
/etc/hosts.deny
на предмет чего-то вроде
sshd: 1.2.3.4
: на сколько я помню в случае permitrootlogin no тебя бы бесконечно запрашивали пароль, без всяких Connection closed.
cat /etc/passwd | grep root
x-one: точнее пару hosts.deny и hosts.allow, но она по идее раньше отрабатывает, до запроса пароля бы не дошел, по идее.
: не бесконечно, а сколько указано в MaxAuthTries
: все проверенно. увы
ssh [email protected] не работает так же
: я собственно о том же, что hosts.deny и hosts.allow тут вряд ли при чем, включай LogLevel DEBUG3 и смотри на стороне серва логи.
: кстати, в рамках предположения 3, проверь-ка права доступа на хому рута, а то был у меня случай, не с рутовым пользователем, а с оракловым, при g+w (group writable) именно ssh не пускал, и сразу закрывал коннект.
Есть еще два таких же тазика.
Есть доступ по ключам и ложиться доступ по паролю
Разні системы, разные хостеры, разные админы. Эпиемия?
: пароли у них есть? доступ по ключу не противоречит отсутствию пароля.
cat /etc/passwd | grep %username%
: на двух последних – длинная матерная цифробуквенная фраза
покажи permission директории юзеров
По ключу ходишь или пароль?
Обновил систему и мир – все прошло. Подозреваю эксплойт.
На всяк случай сменил ссх порт и порезал разрешенные ИП
: Он при этом в лог пишет, что права на директории с конфигами стрёмные, но по паролю всё равно пускает.
: это зависит от того, что в конфиге в директиве StrictModes, на неверные права для ~/.ssh оно, вроде, всегда варнингом отругивается, а вот при включенном StrictModes если хома g+w или o+w будет отлуп по авторизации давать.
: а по ключам пускать? 🙁
: собственно с момента как ты сказал, что по ключам пускает, я и перестал понимать ситуацию, ибо StrictModes yes и некорретные права, невалидный шел и т.д. все это одинаково давало бы отлуп при любом из способов авторизации.
Вариант, что пользоватль залочен в shadow/master.passwd/и т.д. (звездочка или восклицательный знак перед/вместо хэша), отметался ибо ты ходишь консольно (kvm).
Комментом же выше, я просто отвечал про права на каталогах, и когда и как они проверяются.
: Спасибо, я в курсе.
: Собсно, я сам ее перестал понимать
“до этого все работало, никто ничего не трогал”
После апдейта системы и пересборки всего – все заработало
но это на bsd
линуховый тазик пока не трогал