LINUX.ORG.RU

Проблема SSH


0

0

Народ, подскажите пожалуйста, а то я уже замучился! Когда логинишься в SSH, прежде чем спросить пароль он тупит с минуту. Пинг 1, локалка. Проверил все настройки - все чисто. От чего может быть зависание?


reverse DNS

адрес, с которого ты заходишь не резольвится сервером в обратной зоне.

ansky ★★★★★
()
Ответ на: комментарий от power

Результат: OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 ssh: server: Temporary failure in name resolution

Думаю, может как раз проблема в DNS? Пробовал его ставить yum install bind-chroot caching-nameserver, ошибка. Выдали правда какой-то DNS 80.92.161.67, но я не знаю как его использовать/настраивать...

barrio
() автор топика

там что-то, связанное с GSS надо в конфиге отключить. или соответственно, включить.

scaldov ★★
()
Ответ на: комментарий от power

т.е. добавить строчку в /etc/hosts localdomain 80.92.161.67 верно?

[root@localhost ~]# cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail. 127.0.0.1 localhost.localdomain localhost ::1 localhost6.localdomain6 localhost6

barrio
() автор топика
Ответ на: комментарий от barrio

нет. надо дописать туда:

search свой_днс_суффикс
nameserver 8.8.8.8

вместо 8.8.8.8 можешь взять тот адрес днс, что дал тебе провайдер, но и этот будет работать.

Komintern ★★★★★
()
Ответ на: комментарий от barrio

Нет же. В /etc/hosts на сервере напиши:

192.168.0.1 client1
Или че там у тебя. Адрес в локальной сети, короче.

power
()
Ответ на: комментарий от Komintern

Блин, извините за глупость, где узнать днс-суфикс? Я просто недавно в Линуксе работаю. В итоге получим: [root@localhost ~]# cat /etc/hosts

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1 localhost.localdomain localhost

::1 localhost6.localdomain6 localhost6

search свой_днс_суффикс

nameserver 80.92.161.67

правильно?

barrio
() автор топика
Ответ на: комментарий от barrio

Цитируем barrio

search свой_днс_суффикс nameserver 80.92.161.67 правильно?

Нет. Это надо писать в /etc/resolv.conf.
Суффикс можешь не писать.

power
()
Ответ на: комментарий от power

сделал cat /etc/resolv.conf search farpost.loc nameserver 172.16.4.7

перезапустил сервис sshd

тупит.

ssh server -vv OpenSSH_4.3p2, OpenSSL 0.9.8b 04 May 2006 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 ssh: server: Temporary failure in name resolution

как исправить?

barrio
() автор топика
Ответ на: комментарий от barrio

Блджад...

/etc/resolv.conf - какой-то сервер тут лагает, и ssh пробует следующий.

anonymous
()
Ответ на: комментарий от barrio

нет
search и nameserver нужно прописывать в /etc/resolv.conf.

в /etc/hosts прописываешь то, какому IP соответствует машина, с которой заходишь на ssh-сервер. например
# CLIENTS
172.16.6.11 client0

sprutos ★★★
()
Ответ на: комментарий от power

Возрадуйтесь на будущее! проблема была в параметре #GSSAPIAuthentication no GSSAPIAuthentication yes

нужно no

/etc/ssh/sshd_config

Напомните, приветствие где выставляется? А то я поставил, а где забыл...

barrio
() автор топика
Ответ на: комментарий от barrio

cat /etc/resolv.conf

search localdomain

nameserver 80.92.161.67

barrio
() автор топика

А на сервере, а который логинишься DNS поднят?

Если да в /etc/resolv.conf

написать строчку: nameserver localhost

Если нет будем копать дальше.

mr_D
()
Ответ на: комментарий от barrio

>проблема была в параметре #GSSAPIAuthentication no GSSAPIAuthentication yes

Странно... Буду знать спасибо.

mr_D
()
Ответ на: комментарий от barrio

Если сервер на который конектишься является днс-сервером (назовем его - server1), то лучше будет, если он будет ДНС сервером для самого себя (чтоб не дергать днс провайдера) и днс сервером для локальной сети. Так оно лучше и правильнее.

Для этого на server1 в файле /etc/resolv.conf пишем:

nameserver localhost

А на клиентских машинах в файле /etc/resolv.conf пишем:

nameserver IP_of_server1

На виндовых машинах в свойствах подключения пишем ипшник нашего server1 в поле «первичный DNS»

mr_D
()
Ответ на: комментарий от mr_D

>На самом сервере? 127.0.0.1? или какой?

nameserver 127.0.0.1

На спор, что с «nameserver localhost» будет работать?


А что спорить, когда я на эти грабли всего пару месяцев назад наступал. Было:
nameserver localhost
nameserver 8.8.8.8

Потом смотрю однажды, локальные изменения в DNS почему-то не видны. Проверил - а оно через Гугль ищет. Прописал 127.0.0.1 - стал локальный работать. Что, в общем, логично :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>А что спорить, когда я на эти грабли всего пару месяцев назад наступал.

Сударь, это ваша персональная карма.

Что, в общем, логично :)


Ну, конечно логично. Кто бы сомневался что оно так _тоже_ заработает:)

mr_D
()
Ответ на: комментарий от mr_D

>Кто бы сомневался что оно так _тоже_ заработает:)

Не _тоже_, а _только_ так :) В мане всё чётко:
[code]
nameserver
адрес сервера имен в Интернет (в нотации xxx.xxx.xxx.xxx), который будет обрабатывать запросы от
резолвера. Серверов имен может быть максимум MAXNS (в данный момент — 3), по одному на каждой
строке. Если задано несколько серверов, то библиотека резолвера опрашивает их в порядке
перечисления. Если записей nameserver нет, то по умолчанию используется сервер имен на локальной
машине. (Используемый алгоритм пытается подключиться к серверу имен и, если запрос не был
обработан через некоторый промежуток времени, делается попытка подключиться к следующему серверу
имен, и так до тех пор пока не будет обработан весь список серверов, затем повторить процедуру,
пока не будет достигнуто максимальное количество повторов).

[/code]

«в нотации xxx.xxx.xxx.xxx»

Иначе - unzip.zip :)

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>«в нотации xxx.xxx.xxx.xxx»

То есть, по-русски: условно обозначенное как «xxx.xxx.xxx.xxx». То есть это условное обозначение, например в примерах, идущих в мане. Что бы юзеры не писали «xxx.xxx.xxx.xxx» в конфиге, а понимали что это условность, которую надо на что-то заменить (как правило на цифры);)

Да-да, в мане все четко.

http://ru.wikipedia.org/wiki/Нотация

mr_D
()
Ответ на: комментарий от mr_D

SSH авторизация по ключу

Делаю SSH авторизация по ключу. На клиенте сижу под пользователем candidate, захожу на сервер под пользователем tech. При подключении 1)смотрит папку пользователя candidate, нужно чтобы он смотрел пользователя tech 2) Как сделать, чтобы пользователь tech мог подключаться с разных машин по разным ключам?

barrio
() автор топика
Ответ на: комментарий от barrio

1. то есть подключался и перенапралял в папку /home/tech вместо /home/candidate. Правильно задачу понял?

2. смотрим

Аутентификация удаленного пользователя по ключу идентична проверке ключа хоста (с посылкой рандомной строки) за тем исключением, что проверяется не адрес клиентской машины, а ключ клиента и имя пользователя. Данному пользователю на сервере может соответствовать его публичный ключ, тогда клиент, имея секретный ключ сможет заходить на сервер без пароля. Механизм работы я только что описал, поэтому сразу же расскажу, каким образом аутентифицировать пользователей по ключу (предполагается, что используется клиент и сервер openssh):

Для генерации пары ключей используйте программу ssh-keygen. Для указания типа ключа укажите ssh-keygen -t {RSA DSA}, например, ssh-keygen -t rsa создаст пару ключей RSA длиной 1024 бита. Для указания файла, в котором следует сохранить ключи, можно использовать опцию -f (традиционно используются файлы $HOME/.ssh/id_rsa и $HOME/.ssh/id_dsa для ключей rsa и dsa соответственно), для указания длины ключа в битах используйте опцию -b:
ssh-keygen -t rsa -b 2048 -f $HOME/.ssh/id_rsa

В результате работы программа запросит ввод пароля для шифрования секретного ключа, чтобы исключить использование его при попадании к посторонним лицам, не знающим пароля (пароль желательно выбирать не короче 10-и символов). После этого вам будет необходимо вводить данный пароль каждый раз при использовании секретного ключа (далее я расскажу, как избежать этого при помощи программы ssh-agent). После работы ssh-keygen создается пара ключей: один секретный (зашифрованный введенным паролем), а другой публичный с расширением .pub (id_rsa.pub). Публичный ключ вам необходимо будет скопировать в домашнюю директорию сервера $HOME/.ssh/authorized_keys. После этого сервер будет знать ключ данного пользователя и сможет аутентифицировать вас без пароля. Файл authorized_keys может содержать несколько публичных ключей, допустимых для данного пользователя: просто поместите их в данный файл по порядку. После этих операций вы сможете входить, имея секретный ключ, на сервер, где размещен ваш публичный ключ, причем под тем пользователем, в чьем домашнем каталоге данный ключ находится. Пароля удаленного пользователя не требуется, необходимо только знать пароль расшифровки секретного ключа. Для переноса своего публичного ключа на сервер надо использовать только безопасные источники, иначе ваш ключ могут подменить. Для переноса публичного ключа клиента служит программа ssh-copy-id. Для начала необходимо сделать следующее:
# ssh-copy-id -i public_key_file user@machine

После соединения с севером machine и передачей имени пользователя user (необходимо указывать, если удаленное имя отличается от локального) происходит парольная аутентификация заданного пользователя(или текущего) на удаленной машине, затем происходит копирование ключа public_key_file (или $HOME/.ssh/identity.pub, если имя файла не указано) на сервер в $HOME/.ssh/authorized_keys. После этого можно входить на сервер, не используя пароль пользователя. При выполнении данной операции учтите, что вы должны скопировать на удаленную машину ПУБЛИЧНЫЙ ключ, иначе все будет очень печально (думаю, ясно почему).

Отсюда вычленяем строки: Файл authorized_keys может содержать несколько публичных ключей, допустимых для данного пользователя: просто поместите их в данный файл по порядку.

Ясно?

mr_D
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.