После обновление openssh до 1:5.1p1-6.maemo2 с repository.maemo.org перестало пускать на таблетку по ssh. Откатился на 1:4.7p1-12.maemo2 — снова пускает. Проверял оба раза как с ноута, так и с самой таблетки (на localhost). Содержимое ~/.ssh и /etc/ssh ни там, ни там не менялось. Хочу узнать: у кого-то ещё воспроизводится, или это у меня что-то локальное? В системе много чего переделано, но с ssh это напрямую никак не связано.
На всякий случай добавляю конфиг:
$ egrep -v '^($|#)' /etc/ssh/sshd_config
Port ****
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
UsePrivilegeSeparation yes
KeyRegenerationInterval 3600
ServerKeyBits 768
SyslogFacility AUTH
LogLevel INFO
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
IgnoreRhosts yes
RhostsRSAAuthentication no
HostbasedAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
PasswordAuthentication no
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
Ну как бе и не должно пускать то!
PermitRootLogin no
О чём говорит? Рута не пускать!
и еще:
PasswordAuthentication no
И? Я разве сказал, что пытаюсь заходить рутом, или что логинюсь по паролю? Авторизация по ключу. Повторюсь: со старым openssh-server всё работает, с новым нет, конфиги не меняются.
Ну тогда ssh -vvv user@n810 и смотреть вывод
1:5.1p1-6.maemo2 работает без проблем и по ключу тоже
Как я понимаю по этим ответам, у вас проблема не воспроизводится?
svs57:Ну тогда ssh -vvv user@n810 и смотреть вывод
1:5.1p1-6.maemo2 работает без проблем и по ключу тоже
Что-то я стормозил… Настолько привык к логам, что про -vvv и забыл как-то. Сейчас посмотрю, спасибо.
svs57:1:5.1p1-6.maemo2 работает без проблем и по ключу тоже
Ключ rsa? Судя по выводу, у меня dsa ключ проверяется, а rsa — нет.
debug2: key: /home/user/.ssh/identity ((nil))
debug2: key: /home/user/.ssh/id_rsa (0x5bbf0)
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug3: no such identity: /home/user/.ssh/identity
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug1: Trying private key: /home/user/.ssh/id_dsa
debug3: no such identity: /home/user/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
Вот это выключите: PasswordAuthentication no
Вот же проверка RSA:
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
Попробуйте заново скопировать public
ssh-copy-id
Mitrandir:Вот это выключите: PasswordAuthentication no
Не должно оно влиять на авторизацию по ключу. И не хочу я, чтобы ко мне ломились подбирать пароли. Проходил уже через это на ББ лет пять назад ещё. Даже нестандартный порт не всегда спасает.
svs57:Вот же проверка RSA:
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
Это мне как раз не совсем понятно: есть упоминание о посылке ключа, но не упоминается хоть какой-то ответ.
svs57:Попробуйте заново скопировать public
ssh-copy-id
Пробовал уже, без толку.
Вот для сравнения аналогичный кусок ответа от сервера 4.7:
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/identity
debug3: no such identity: /home/user/.ssh/identity
debug1: Offering public key: /home/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug2: input_userauth_pk_ok: fp ****
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
t.t:И не хочу я, чтобы ко мне ломились подбирать пароли. Проходил уже через это на ББ лет пять назад ещё. Даже нестандартный порт не всегда спасает.
Вы немного путаете причину и следствия. Если захотят ломиться - то ломиться будут. И метод авторизации от самого факта ломления не спасает. Фактически внешне это выглядит одинаково - не удаётся авторизоваться злоумышленнику по паролю. Просто с выключенной опцией долбящемуся никогда пароль не подобрать, а с включённой - это уже зависит от качества логина и пароля. Но от самой \"долбёжки\" это никак не защитит. Чтобы долбёжка не мешала - её надо на пограничном роутере отсекать. Ещё до таблетки :)))
Если ключ не подходит так и будет:
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 528 bytes for a total of 1655
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
gLobster:[quote=t.t]И не хочу я, чтобы ко мне ломились подбирать пароли. Проходил уже через это на ББ лет пять назад ещё. Даже нестандартный порт не всегда спасает.
Вы немного путаете причину и следствия. Если захотят ломиться - то ломиться будут. И метод авторизации от самого факта ломления не спасает. Фактически внешне это выглядит одинаково - не удаётся авторизоваться злоумышленнику по паролю. Просто с выключенной опцией долбящемуся никогда пароль не подобрать, а с включённой - это уже зависит от качества логина и пароля. Но от самой \"долбёжки\" это никак не защитит. Чтобы долбёжка не мешала - её надо на пограничном роутере отсекать. Ещё до таблетки :)))[/quote]
Я ничего не путаю. По опыту от содержимого сообщения после неудачного входа «(publickey)» либо «(publickey, password)» интенсивность долбёжки всё же зависит. Да и больше беспокоит не само долбление, а шансы на успех. А насчёт отсечения — дома-то отсекается на ноуте (через usb хожу в сеть), а вот в публичных вайфай сетях или на gprs-е ничего до таблетки не отсечёшь.
svs57:Если ключ не подходит так и будет:
debug2: we sent a publickey packet, wait for reply
debug3: Wrote 528 bytes for a total of 1655
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
Это-то понятно. Непонятно другое: каким образом «подходящесть» ключа может зависеть от версии сервера. Кроме неё ведь ничего не меняется.
Но у других же работает.
А пакет из маемовского репозитория?
Попробуйте еще с dsa ключами.
PS
Может попробовать с портом 22 ?
t.t:По опыту от содержимого сообщения после неудачного входа «(publickey)» либо «(publickey, password)» интенсивность долбёжки всё же зависит.
каким образом? взломщик снаружи не может знать какие методы доступны. Сервер ведь не говорит о том, что используется неразрешённый метод авторизации - он просто отказывает в ней всегда одинаково. С точки зрения защиты - это глупость сообщать какую ошибку делает авторизующийся. Примерно как сказать: вы ошиблись в 3ьей букве пароля.
Ну и про взлом в общественных сетях - это параноя. На взлом нужно несколько часов, если не суток. При этом нужно ещё и \"вычислить\" кого ломать. А все публичные сети - это NAT. И как за ним Вас ловить? доступны только компьютеры с внешним IP... Параноя это.
Согласен с gLobster по поводу NAT. Нечего здесь защищать.
Точно также как и попытки установить файервол на таблетке.
Она все время за NAT находится.
svs57:Но у других же работает.
Так это-то и странно. Если бы у всех не работало, написал бы баг-репорт и успокоился.
svs57:А пакет из маемовского репозитория?
Да, я писал, откуда ставил, в первом посте.
svs57:Попробуйте еще с dsa ключами.
Завтра попробую.
svs57:PS
Может попробовать с портом 22 ?
Пробовал. Не помогает.
gLobster:[quote=t.t]По опыту от содержимого сообщения после неудачного входа «(publickey)» либо «(publickey, password)» интенсивность долбёжки всё же зависит.
каким образом? взломщик снаружи не может знать какие методы доступны. Сервер ведь не говорит о том, что используется неразрешённый метод авторизации - он просто отказывает в ней всегда одинаково. С точки зрения защиты - это глупость сообщать какую ошибку делает авторизующийся. Примерно как сказать: вы ошиблись в 3ьей букве пароля.[/quote]Взломщик не знает, спрашивают ли у него пароль или отказывают сразу? (: Конечно сервер не говорит, используется ли неразрешённый способ авторизации — он просто его _не_ использует, да и всё. И «вычисляется» это на раз, в т.ч. и программно.
gLobster:Ну и про взлом в общественных сетях - это параноя. На взлом нужно несколько часов, если не суток. При этом нужно ещё и \"вычислить\" кого ломать. А все публичные сети - это NAT. И как за ним Вас ловить? доступны только компьютеры с внешним IP... Параноя это.
Не все NAT. Мне известна пара с динамическими внешними айпишниками. А также известны случаи, когда ломали из той же сети, если она большая. И gprs не забывайте. А «вычислить», кто из прощупанных вчера машин на каком адресе висит сегодня — тоже дело двух минут. Начиная с того, что в сети мобильного оператора или даже на общественном вайфае машин с поднятым ssh в принципе будет совсем не много.
Вообще я заметил, что людей, склонных к компьютерной паранойе крайне сложно убедить в излишестве каких-либо средств защиты. Максималисты :)
Ломать и даже просто сканировать адреса GPRS-абонентов крайне невыгодно — у них мизерная скорость отдачи.
Имхо, хороший пароль решает 99.9% проблем
Mitrandir:Вообще я заметил, что людей, склонных к компьютерной паранойе крайне сложно убедить в излишестве каких-либо средств защиты. Максималисты :)
Ломать и даже просто сканировать адреса GPRS-абонентов крайне невыгодно — у них мизерная скорость отдачи.
Имхо, хороший пароль решает 99.9% проблем
Начнём с того, что кроме проблем есть ещё и удобство. Мне удобнее работать с ключом, чем с паролем. Причём намного удобнее. А «хороший пароль» в смысле удобства ещё хуже. (;
А gprs был упомянут лишь для полноты картины. Повторюсь: мне достоверно известны случаи вскрытия ssh в публичных вайфай-сетях. Да, единичные. Но не попытки, а именно вскрытия. А значит попытки как минимум в сотни раз чаще; а они мне тоже не нужны.
Итого. Первый аргумент: удобство. А вероятность успешной атаки, хоть и мизерная, — лишь из серии «пусть будет до кучи». Не пойму, где вы здеь паранойю увидели.
Mitrandir:Ломать и даже просто сканировать адреса GPRS-абонентов крайне невыгодно — у них мизерная скорость отдачи.
Насколько я помню - в сетях GPRS абоненты просто не видят друг друга. Передача возможна только от терминала во внешнюю сеть. Можете попробовать войдя одновременно с двух коммуникаторов в операторскую сеть и увидев свои айпи, пингануть - не дойдут пакеты :)
Ну и ещё про один миф инициатора флейма :) О безопасности авторизации по ключам. С некоторых пор это считается одним из самых опасных методов :) Компрометация ключа более вероятна, чем подбор сложного пароля :) Поясню. Мало кто соблюдает все правила работы с персональным ключём. Он не запаролен и не хранится на внешнем криптованном носителе. Мало того, гореадмины любят иметь один ключ на все сервера и не паролируя его, держать в стандартном каталоге на виндовой машине. А дальше, при необходимости, это просто дело техники - со сквозьдырявойвинды из домашнего каталога пользователя из папочки .ssh утянуть всё с расширением *.ppk.... Чтобы взять у винды даже пароля подбирать не надо :)))
Так что верно только одно утверждение \"мне удобно\". И оно самое законное и правильное. А всё остальное - притянуто за уши, как и фраза \"мне лично известны\". А я лично утверждаю, что в публичных сетях взломать логин/пароль возможно только в том случае, если они \"user/password\". Каждая проба пароля на ssh - от 10-ти секунд. БЫстро можно сделать только если одновременно с большого количества компьютеров - с сетевой атаки. Ну и на фига это делать на пользовательский ПК только если это владелец не держатель пароля к красной кнопке? Так что позвольте не поверить и считать такой аргумент \"притянутым за уши\". Или дайте методику по кторой аккаунт был взломан за столь короткое время.
t.t: Конечно сервер не говорит, используется ли неразрешённый способ авторизации — он просто его _не_ использует, да и всё. И «вычисляется» это на раз, в т.ч. и программно.
А фактически это на сервере просто на один If больше - т.е. мизернопринебрежимо!
If(проверять пароль?) {if(call проверить пароль) { пустить; } }
выйти не пустив;
gLobster:Ну и ещё про один миф инициатора флейма :) О безопасности авторизации по ключам. С некоторых пор это считается одним из самых опасных методов :) Компрометация ключа более вероятна, чем подбор сложного пароля :) Поясню. Мало кто соблюдает все правила работы с персональным ключём. Он не запаролен и не хранится на внешнем криптованном носителе. Мало того, гореадмины любят иметь один ключ на все сервера и не паролируя его, держать в стандартном каталоге на виндовой машине. А дальше, при необходимости, это просто дело техники - со сквозьдырявойвинды из домашнего каталога пользователя из папочки .ssh утянуть всё с расширением *.ppk.... Чтобы взять у винды даже пароля подбирать не надо :)))
Так что верно только одно утверждение \"мне удобно\". И оно самое законное и правильное. А всё остальное - притянуто за уши, как и фраза \"мне лично известны\". А я лично утверждаю, что в публичных сетях взломать логин/пароль возможно только в том случае, если они \"user/password\". Каждая проба пароля на ssh - от 10-ти секунд. БЫстро можно сделать только если одновременно с большого количества компьютеров - с сетевой атаки. Ну и на фига это делать на пользовательский ПК только если это владелец не держатель пароля к красной кнопке? Так что позвольте не поверить и считать такой аргумент \"притянутым за уши\". Или дайте методику по кторой аккаунт был взломан за столь короткое время.
Методик взлома я не знаю, эти случаи вообще не анализировал, мне только известно, что они были, не более.
Способы кражи ключа мне известны. А за виндовой машиной я последний раз работал лет шесть назад.
Предлагаю остановиться на том, что удобство здесь ключевой аргумент.
gLobster:[quote=t.t] Конечно сервер не говорит, используется ли неразрешённый способ авторизации — он просто его _не_ использует, да и всё. И «вычисляется» это на раз, в т.ч. и программно.
А фактически это на сервере просто на один If больше - т.е. мизернопринебрежимо!
If(проверять пароль?) {if(call проверить пароль) { пустить; } }
выйти не пустив;[/quote]
Не понял, при чём здесь это? Я говорил о том, что когда авторизация по паролю не используется, взломщик не долбится с попытками подбора. Т.е. что это ещё и способ избавиться от этой долбёжки. Про кпк здесь, пожалуй, действительно перебор. Но на ноуте у меня, пока не отключил авторизацию по паролю, сообщения о неудачных попытках входа сыпались в лог от двух до сорока раз в час. Сейчас разве только раз в несколько недель что-то прилетит. Я, правда, и порт на нестандартный сменил тогда же; но по опыту других людей, одна только смена порта такого эффекта обычно не даёт.
t.t:Не понял, при чём здесь это? Я говорил о том, что когда авторизация по паролю не используется, взломщик не долбится с попытками подбора.
А я пишу о том, что снаружи понять какой метод авторизации доступен - не возможно.
gLobster:[quote=t.t]Не понял, при чём здесь это? Я говорил о том, что когда авторизация по паролю не используется, взломщик не долбится с попытками подбора.
А я пишу о том, что снаружи понять какой метод авторизации доступен - не возможно.[/quote]
$ mv .ssh/id_rsa .
$ ssh -p *** localhost
Permission denied (publickey).
$ sudo sed -i '/^PasswordAuth/ s/no$/yes/' /etc/ssh/sshd_config
$ sudo /etc/init.d/ssh restart
Restarting OpenBSD Secure Shell server: sshd.
$ ssh -p *** localhost
user@localhost's password:
Permission denied, please try again.
user@localhost's password:
Permission denied, please try again.
user@localhost's password:
Permission denied (publickey,password).
Что-то непонятно?
А локальным клиентом по ключу заходит?
Может в клиенте дело?
Наверно это уже посмотрели, но на всякий случай спрошу - а хостключ клиента не в блэк листе? При обновлении openssh сервера на какую-то версию он резко преставла принимать старые ключи от своих же клиентов предыдущих версий. Там была какя-то проблема с псевдорандомной последовательностью. Но он правда тогда сразу в лог об этом пишет.
Хорошо бы удалить пакет с конфигами и ключи, установить заново, создать ключи и не меняя конфигов проверить.
svs57:А локальным клиентом по ключу заходит?
Может в клиенте дело?
Не в клиенте. Я тоже писал в первом посте. На таблетку не могу зайти ни с неё, ни с ноута. На ноут нормально захожу и оттуда, и оттуда.
gLobster:Наверно это уже посмотрели, но на всякий случай спрошу - а хостключ клиента не в блэк листе? При обновлении openssh сервера на какую-то версию он резко преставла принимать старые ключи от своих же клиентов предыдущих версий. Там была какя-то проблема с псевдорандомной последовательностью. Но он правда тогда сразу в лог об этом пишет.
Мысль интересная, спасибо. Сейчас попробую сгенерить новый ключ и проверить.
Удалил /etc/ssh/ и ~/.ssh/, переустановил пакет, сгенерил новые ключи, проблема решилась. Всем спасибо.
Прошу прощения за поднятие старой темы, хочется кое-что добавить.
gLobster:Насколько я помню - в сетях GPRS абоненты просто не видят друг друга. Передача возможна только от терминала во внешнюю сеть. Можете попробовать войдя одновременно с двух коммуникаторов в операторскую сеть и увидев свои айпи, пингануть - не дойдут пакеты :)
Сейчас я временно вышел с gprs мтс-Украина. Получил белый динамический айпишник и без проблем зашёл на него по ssh с машины, расположенной вообще в другой стране.
Во избежание недопонимания раскрою ещё раз причины своих предосторожностей. Я представляю, что такое подбирать пароль на gprs-соединении. Но ботам обычно без разницы, кого ломать, да и не в курсе они, что у меня gprs — в них таких проверок как правило вообще нет (ssh-сервер на кпк или телефоне явление редкое). А мне долбёж, пусть даже и безуспешный, на gprs тем более не нужен, чем на широком канале.
Всё зависит от оператора. В России у МТС абоненты находятся за NAT'ом например.
Понятно, что зависит. Я это к тому и написал, что бывает по-разному. А на мой взгляд, в такой ситуации, как говорится, «лучше перебдеть, чем недобдеть». Тем более, что с особыми сложностями это не связано — даже наоборот, как уже говорилось, так ещё и удобнее.
М.б. имеет смысл сделать файервол (iptables)?
svs57:М.б. имеет смысл сделать файервол (iptables)?
Я как увидел белый айпишник, тоже об этом подумал. Если буду постоянно пользоваться мтс, надо будет заняться.
Закрываюсь, когда приходится выходить через Скайлинк.
Если ssh сервер нужен на компе, то только сложный пароль.
svs57:Закрываюсь, когда приходится выходить через Скайлинк.
Если ssh сервер нужен на компе, то только сложный пароль.
По большому счёту, если на компе крутится что-то ещё, тогда как раз скорее firewall и нужен. Если при этом заходы по ssh могут быть только с наперёд известных адресов, то пароля более чем достаточно. Для таблетки я насчёт фаервола возможно и погорячился: зачем он там, если кроме ssh порты никто не слушает? Т.е. строго говоря есть два варианта: если опять же адреса возможных заходов известны наперёд, перекрыть остальное iptables; либо, в более общем случае, уйти на нестандартный порт и закрыть авторизацию по паролю. На мой взгляд, второй вариант и более удобный, и куда менее морочливый.
Не соглашусь с Вами.
Во-первых, если известны адреса, с которых всегда заходите, то их и нужно будет задать файерволу. Пароль здесь не при чем.
По поводу того что открыт лишь ssh - так этого более чем достаточно. Все в Юниксе управляется через него.
Нестандартный порт не поможет, т.к. сканеры очень просто определяют что сидит на порту.
Нестандартный порт сканируется очень легко, это как-то несерьёзно
А отключение авторизации по паролю не поможет в борьбе с паразитным трафиком, т.к. клиенту извне неизвестно, закрыт у вас пароль или нет, и соответственно ломиться он не перестанет
Может просто отключать sshd при включенном ГПРС?
svs57:Не соглашусь с Вами.
Во-первых, если известны адреса, с которых всегда заходите, то их и нужно будет задать файерволу. Пароль здесь не при чем.
По поводу того что открыт лишь ssh - так этого более чем достаточно. Все в Юниксе управляется через него.
Нестандартный порт не поможет, т.к. сканеры очень просто определяют что сидит на порту.
Вы меня неверно поняли. Я и имел ввиду, что, зная адреса, можно задать их фаерволу и открыть доступ по паролю. Если же адреса неизвестны, а кроме ssh ничего нет, то установка фаервола лишена смысла: ssh прикрывать нельзя, а больше прикрывать нечего. А раз прикрывать ssh нельзя, то я бы получше озаботился его собственной безопасностью. И вот здесь уже вход только по ключу в сочетании с соблюдением всех требований надёжности хранения этого ключа — наиболее приемлемый вариант. А нестандартный порт — лишь дополнительная мелочь для отсечения флуда запросов: боты, умеющие сканировать порты, как правило достаточно умны и для того, чтобы отвалиться, если вход по паролю закрыт.
В гпрс вы всегда за натом оператора, прямой айпи стоит денег и простым юзерам вообще не выдается.
Bolt123:В гпрс вы всегда за натом оператора, прямой айпи стоит денег и простым юзерам вообще не выдается.
у теле2 (петербург) выдаются прямые шведские IP адреса безо всяких дополнительных услуг