Проблема с SSH (Host key verification failed)

Есть VM Workstation на котором стоит две Ubuntu 10.04: сервер 192.168.1.1 и клиент 192.168.1.20. На сервер установил openssh-server, на клиенте ssh-client по умолчанию стоит. Ни каких настроек в sshd_config не менял ибо говорят что все должно сразу заработать. Т.е. можно будет зайти по паролю

[console]user20@client$ ssh user1@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is 18:6a:fa:1e:e2:09:e8:9b:03:e8:1d:ac:1a:2d:79:cf.
Are you sure you want to continue connecting (yes/no)? yes
Host key verification failed.[/console]

Что это значит?

Почитал в инетах пишут что нужно все удалить из файла ~/.ssh/known_hosts , но у меня такого файла нет и следовательно это не может решить проблему.

Почитал про ключи, но тоже не совсем разобрался

[console]user20@client$ ssh-keygen -t rsa[/console]

Создались два ключа, это понятно. Дальше публичный нужно отправить на сервер.

[console]user20@client$ ssh-copy-id -i ~/.ssh/id_rsa.pub user1@192.168.0.1[/console]

и получаю тоже что и в начале Host key verification failed

Подскажите как заставить SSH работать?

Gizmo написал:

Почитал в инетах пишут что нужно все удалить из файла ~/.ssh/known_hosts , но у меня такого файла нет и следовательно это не может решить проблему.

так создайте его
$touch known_hosts
$chmod 644 known_hosts

Далее, если надо входить по ключам, то должен присутствовать файл: authorized_keys

Создать надо на клиенте? Хотя не совсем понял что мне даст создание файла.

На сервере создал файл ~/.ssh/authorized_keys

[console]$ cat id_rsa.pub > ~/.ssh/authorized_keys [/console]

только от всего этого ничего не изменилось...

Gizmo, покажите вывод команды ifconfig на клиенте и сервере. Что-то мне вот это не понятно:

Gizmo написал:

user20@client$ ssh user1@192.168.0.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.

Lupo Alberto написал:

Что-то мне вот это не понятно:

А что здесь не понятно? О_о, в разных сетях находятся сервер и клиент, может у ТС маска 16я =)
p.s. как вариант ТС напутал адреса =)

Извините, это очепятка. что бы привычнее было написал 0.1 .)) но на всякий случай:

[console]192.168.1.1 ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:a8:30:1c
inet addr:192.168.226.132 Bcast:192.168.226.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fea8:301c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:610 errors:0 dropped:0 overruns:0 frame:0
TX packets:50 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:61536 (61.5 KB) TX bytes:7781 (7.7 KB)
Interrupt:19 Base address:0x2000

eth1 Link encap:Ethernet HWaddr 00:0c:29:a8:30:26
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fea8:3026/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:81 errors:0 dropped:0 overruns:0 frame:0
TX packets:116 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13844 (13.8 KB) TX bytes:25104 (25.1 KB)
Interrupt:19 Base address:0x2080[/console]

[console]
192.168.1.10 ifconfig
eth0 Link encap:Ethernet HWaddr 00:0c:29:42:47:c4
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe42:47c4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:325 errors:0 dropped:0 overruns:0 frame:0
TX packets:394 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:72348 (72.3 KB) TX bytes:56917 (56.9 KB)
Interrupt:19 Base address:0x2000[/console]

Gizmo написал:

user20@client$ ssh-copy-id -i ~/.ssh/id_rsa.pub user1@192.168.0.1

Ну и? :rolleyes:

Так я ж говорю, что пишет тоже самое =(

[console]The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
RSA key fingerprint is 18:6a:fa:1e:e2:09:e8:9b:03:e8:1d:ac:1a:2d:79:cf.
Are you sure you want to continue connecting (yes/no)? yes
Host key verification failed.[/console]

Gizmo написал:

Так я ж говорю, что пишет тоже самое sad

смотрите тогда на наличие конфигурации sshd_config и ssh_config, у вас ключи разные. Вот здесь почитайте. smile

Спасибо, это я читал, но там данной проблемы нет

$ ssh ssh-server.example.com
The authenticity of host 'ssh-server.example.com (12.18.429.21)'
can't be established.
RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
Are you sure you want to continue connecting (yes/no)?

Ответим "да", и подключение продолжится:

$ ssh ssh-server.example.com
Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added 'ssh-server.example.com,12.18.429.21'
(RSA) to the list of known hosts.

Password: (введите пароль)

вот а у меня он пароль то не просит... Ведь по идее все может работать и просто по паролю и без ключей?

Gizmo, плохо читали, дальше идет пунктик проверка ключа, и как раз это и есть ваш случай. Возможно придется почитать как конфигурировать openssh.

Я так понял что когда первый раз соединяешься с сервером нужно в файле /etc/ssh/ssh_config раскомментировать строку StrictHostKeyCheking и вместо ask поставить no. И после $ ssh user1@192.168.1.1 он выдаст:
[console]Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts[/console]

(т.е. мне в файл ~/.ssh/known_hosts запишется содержимое server/etc/ssh/ssh_host_rsa_key.pud. А затем StrictHostKeyCheking в yes)

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

Это и есть самое не безопасное использование ssh и дальше можно уже ключи использовать?
И верно то что я сделал с StrictHostKeyCheking?

если StrictHostKeyChecking=yes и у вас нет ключа, то зайти не удастся.

Gizmo написал:

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

Это и есть самое не безопасное использование ssh и дальше можно уже ключи использовать?

самое главное что бы root не имел возможности войти. Если внутри сети будете использовать данный метод и админить сеть будете только вы, то можно оставить и значение no, это уже на ваше усмотрение. smile

i2ks написал:

если StrictHostKeyChecking=yes и у вас нет ключа, то зайти не удастся.

Ну это само собой. Я имел ввиду нормально ли изменить значение на no для того что бы получить ключ, а затем поставить yes? Как это с точки зрения безопасности или есть другие пути. Или я уже свои мысли не ясно излагаю)))

Gizmo написал:

Ну это само собой. Я имел ввиду нормально ли изменить значение на no для того что бы получить ключ, а затем поставить yes? Как это с точки зрения безопасности или есть другие пути. Или я уже свои мысли не ясно излагаю)))

в данном случае это уместно, а так ключи можно хоть физически перетаскивать с места на место, если уж говорить о безопасности, то о какой безопасности идет речь? Экономической, Пожарной и т.п.? :rolleyes:

Ну на виртуальной машине конечно все уместно :D
Безопасность данных, паролей... от злых товарищей которые сканируют порты, подбирают пароли и прочее.

Gizmo написал:

Безопасность данных, паролей... от злых товарищей которые сканируют порты, подбирают пароли и прочее.

Дык, это целая наука уже, имеет ряд факторов и рисков, проблем и решение их, я больше чем уверен в данной теме данное обсуждение будет не уместно. =)
Ну а так, для начала fial2ban + iptables, это то что бы можно было фильтровать товарищей которые сканируют порты и подбирают пароли удаленно.

Gizmo написал:

Безопасность данных

Изучайте: http://iso27000.ru/

Хорошо. Спасибо больше, i2ks :rolleyes:

Главное чтобы стремление обезопасить себя не перерастало в паранойю.
Я недавно пробовал взломать ssh на виртуалке брутфорсом - не так то просто я скажу, а если добавить в правила iptables:
Брутфорсил медузой (пакет medusa в debian).

# Защищаем 22 порт SSH от брутфорса (перебора паролей)
# Задача следующих правил ограничить соединения на порт ssh 3-мя попытками в течении 10 минут с 1 ip адреса. Создаем новую цепочку правил SSHDROP:
iptables -N SSHDROP
# Все новые соединения на порт 22 пропускаем через цепочку SSHDROP
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHDROP
iptables -A SSHDROP -m recent --set --name SSH
# Если начальные условия нарушены то запретим соединение
iptables -A SSHDROP -m recent --update --seconds 300 --hitcount 3 --name SSH -j DROP

То вообще маловероятно.

И ещё в некоторых случаях вход по ключу может быть более опасным, потому как позволяет автоматом войти на удаленную машину скрипту с правами рута.

newzenon написал:

И ещё в некоторых случаях вход по ключу может быть более опасным, потому как позволяет автоматом войти на удаленную машину скрипту с правами рута.

дык можно вообще закрыть логин рута. зачем он скрипту-то? скрипт делает чётко определённые действия, эти действия можно обернуть в скрипт(на удалённой машине), и разрешить по SSH выполнять только этот скрипт (через sudo).
Кроме того, expect позволяет брутефорсить пароли. Потому вход по ключу более безопасные - ибо ключ == пароль, только
1) очень длинный, и потому его не брутефорснуть в принципе.
2) даже взломав сервер невозможно узнать закрытый ключ. Т.о., если даже админ использует один ключ на все сервера, то сломав один из его серверов, враг не получит доступа к другим.
3) и наконец, ключ невозможно запомнить. Потому одмина можно на куски резать - если он уничтожил ключ - он его уничтожил.