Error while copying ssh key the error occurred error 106

Добавление нового хоста в пул

Делаю на VPS так:
1. Manage Hosts in the pool > 1. Add new host in the pool
Ввожу «server2» и выдаёт ошибку:

Следую рекомендации и смотрю файл логов

Была такая же проблема при разворорачивании на amazon.
Хотя хост был доступный.

Помог 3 пункт: Reboot host.

Так же самая ситуация. не создается 2й пул!

Пишет:
10-20-15_14:36:25: SSH_INIT — get key text from file
10-20-15_14:36:25: SSH_INIT — root connect to 192.168.10.188:22
10-20-15_14:36:25: SSH_CONNECT — No route to host 192.168.10.188:22

Такая же ошибка, почему молчат разработчики?

Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Перезагружали виртуальную машину?

Нет, ничего не перегружал. Сразу заработало. Нужно лишь дождаться завершения задачи.
Проверить можно чз меню 5.

Никакого фаирвола между машинами нет?

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Перезагружали виртуальную машину?

Нет, ничего не перегружал. Сразу заработало. Нужно лишь дождаться завершения задачи.
Проверить можно чз меню 5.

Никакого фаирвола между машинами нет?

вот ошибка файла ssh_keycopy.log:

12-22-15_20:31:11: SSH_INIT — get key text from file
12-22-15_20:31:11: SSH_INIT — root connect to 192.168.56.102:22
12-22-15_20:31:11: SSH_CONNECT — No route to host 192.168.56.102:22

12-22-15_20:31:11: SSH_INIT — get key text from file
12-22-15_20:31:11: SSH_INIT — root connect to 192.168.56.102:22
12-22-15_20:31:11: SSH_CONNECT — No route to host 192.168.56.102:22

В натройках сети стоит: Тип подключения — Виртуальный адаптер хоста; Имя — Virtualbox Host-Only Ethernet adapter

Пробовал тип ставить NAT — такаяже ошибка.

Да я же уже все написал:
В натройках сети виртуальной машины стоит: Тип подключения — Виртуальный адаптер хоста; Имя — Virtualbox Host-Only Ethernet adapter
Виртуальная машина: VMBitrix5.1.5-virtualbox — в самой машине (linuxe) вообще ничего не трогал, все по умолчанию. Если нужен лист какогото файла — скажите какого.
IFCONFIG машины:
eth0 Link encap:Ethernet HWaddr 08:00:27:A9:8C:3B
inet addr:192.168.56.101 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fea9:8c3b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1180 (1.1 KiB) TX bytes:1298 (1.2 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

До 192.168.56.101 с компа пингутеся. Да и сайт на этом адресе нормально работает. А вот второй хост никак не создать.

2я машина точно сконфигурирована заранее — пароли юзерам root и bitrix сменены при первом входе?

Источник

Устранение неполадок SSH – ошибки работы протокола

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

Какие бывают ошибки протокола SSH?

Когда SSH-клиенты получают ошибки сброса соединений, неполадки с шифрованием, а также наблюдаются проблемы, связанные с «неизвестным» или «изменённым» хостом, то это, как правило, ошибки работы протокола SSH. Подобного рода неполадки часто возникают на этапе согласования зашифрованного соединения протоколом SSH посредством создания доверия между сервером и клиентом.

Невозможность проверки ключа хоста

При создании SSH-соединения протокол требует, чтобы стороны идентифицировали себя. Бывает так, что от сервера поступает следующая ошибка:

Эта ошибка может возникать по нескольким причинам:

• переустановка SSH-сервера и неполная его конфигурация;
• восстановление сервера из резервной копии;
• изменение IP-адреса сервера.

Очистка ключей хостов помогает решить эту проблему. Сами эти ключи хранятся на стороне клиента в файле

/.ssh/known_hosts . Для очистки можно удалить все записи вручную. Либо можно использовать команду:

Эта команда попытается очистить соответствующую информацию о ключе хоста в файле known_hosts:

После этих действий можно попробовать снова выполнить подключение к серверу SSH.

Закрытие или сброс соединения

Бывает так, что соединение с SSH-сервером устанавливается, однако на этапе проверки ключей сбрасывается. Эта ошибка выглядит следующим образом:

Часто такая ошибка возникает по нескольким причинам:

• программный сбой работы SSH-сервера или он не запущен;
• невозможность инициализировать соединение из-за отсутствия или недоступности ключей.

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

В данном случае необходимо проверить, есть ли в каталоге /etc/ssh набор файлов с именами sshd_host_*_key. Один из них должен иметь расширение *.pub.
В случае, если таких файлов нет, их нужно сгенерировать:

Теперь можно снова попытаться подключиться к серверу.

Ошибка взаимодействия с хостом

Для работы протокола SSH на этапе его инициализации генерируется общий закрытый ключ. Он создаётся на основе шифрования, которое согласуется при создании подключения между сервером и клиентом. Иногда на этом этапе возникают несоответствия и на стороне клиента это приводит к следующей ошибке:

Эта ошибка говорит о том, что сервер и клиент друг друга «не понимают». Это может быть вызвано следующими причинами:

• список шифрования сервера был изменён или сервер его не поддерживает;
• различные реализации (версии) протокола SSH на сервере и у клиента.

Как можно видеть, для устранения этой ошибки необходимо привести в соответствие версию клиента SSH, а также настроить шифрование для него. Если сервер использует устаревший метод шифрования, например SHA1, а у клиента по-умолчанию задействованы более совершенные методы, то это также будет вызывать ошибки протокола SSH. Для начала необходимо выяснить, действительно ли у сервера и клиента используются разные методы шифрования.
Для клиента использование методов шифрования можно настроить, используя опцию KexAlgorithms:

Эта проблема не такая распространённая, поскольку возникает, когда версия реализации SSH-клиента более новая, чем используемая на сервере.

Заключение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Почему не могу скопировать свой ssh на другую ноду?

Простой 2 комментария

Потому что после опции -i должен идти путь к файлу с открытым ключом.

Use only the key(s) contained in identity_file (rather than looking for identities via ssh-add(1) or in the default_ID_file). If the filename does not end in .pub this is added. If the filename is omitted, the default_ID_file is used.

Note that this can be used to ensure that the keys copied have the comment one prefers and/or extra options applied, by ensuring that the key file has these set as preferred before the copy is attempted.

Что вы сказали — то команда и пытается сделать: использовать ключ root@192.168.1.150 которого не находит, о чем вам и сообщает.

Источник

Глава 10: Common error messages

This chapter lists a number of common error messages which PuTTY and its associated tools can produce, and explains what they mean in more detail.

We do not attempt to list all error messages here: there are many which should never occur, and some which should be self-explanatory. If you get an error message which is not listed in this chapter and which you don’t understand, report it to us as a bug (see appendix B) and we will add documentation for it.

10.1 «The server’s host key is not cached in the registry»

This error message occurs when PuTTY connects to a new SSH server. Every server identifies itself by means of a host key; once PuTTY knows the host key for a server, it will be able to detect if a malicious attacker redirects your connection to another machine.

If you see this message, it means that PuTTY has not seen this host key before, and has no way of knowing whether it is correct or not. You should attempt to verify the host key by other means, such as asking the machine’s administrator.

If you see this message and you know that your installation of PuTTY has connected to the same server before, it may have been recently upgraded to SSH protocol version 2. SSH protocols 1 and 2 use separate host keys, so when you first use SSH-2 with a server you have only used SSH-1 with before, you will see this message again. You should verify the correctness of the key as before.

See section 2.2 for more information on host keys.

10.2 «WARNING — POTENTIAL SECURITY BREACH!»

This message, followed by «The server’s host key does not match the one PuTTY has cached in the registry», means that PuTTY has connected to the SSH server before, knows what its host key should be, but has found a different one.

This may mean that a malicious attacker has replaced your server with a different one, or has redirected your network connection to their own machine. On the other hand, it may simply mean that the administrator of your server has accidentally changed the key while upgrading the SSH software; this shouldn’t happen but it is unfortunately possible.

You should contact your server’s administrator and see whether they expect the host key to have changed. If so, verify the new host key in the same way as you would if it was new.

See section 2.2 for more information on host keys.

10.3 «SSH protocol version 2 required by our configuration but remote only provides (old, insecure) SSH-1»

By default, PuTTY only supports connecting to SSH servers that implement SSH protocol version 2. If you see this message, the server you’re trying to connect to only supports the older SSH-1 protocol.

If the server genuinely only supports SSH-1, then you need to either change the «SSH protocol version» setting (see section 4.19.4), or use the -1 command-line option; in any case, you should not treat the resulting connection as secure.

You might start seeing this message with new versions of PuTTY (from 0.68 onwards) where you didn’t before, because it used to be possible to configure PuTTY to automatically fall back from SSH-2 to SSH-1. This is no longer supported, to prevent the possibility of a downgrade attack.

10.4 «The first cipher supported by the server is . below the configured warning threshold»

This occurs when the SSH server does not offer any ciphers which you have configured PuTTY to consider strong enough. By default, PuTTY puts up this warning only for Blowfish, single-DES, and Arcfour encryption.

See section 4.22 for more information on this message.

(There are similar messages for other cryptographic primitives, such as host key algorithms.)

10.5 «Remote side sent disconnect message type 2 (protocol error): «Too many authentication failures for root»»

This message is produced by an OpenSSH (or Sun SSH) server if it receives more failed authentication attempts than it is willing to tolerate.

This can easily happen if you are using Pageant and have a large number of keys loaded into it, since these servers count each offer of a public key as an authentication attempt. This can be worked around by specifying the key that’s required for the authentication in the PuTTY configuration (see section 4.23.8); PuTTY will ignore any other keys Pageant may have, but will ask Pageant to do the authentication, so that you don’t have to type your passphrase.

On the server, this can be worked around by disabling public-key authentication or (for Sun SSH only) by increasing MaxAuthTries in sshd_config .

10.6 «Out of memory»

This occurs when PuTTY tries to allocate more memory than the system can give it. This may happen for genuine reasons: if the computer really has run out of memory, or if you have configured an extremely large number of lines of scrollback in your terminal. PuTTY is not able to recover from running out of memory; it will terminate immediately after giving this error.

However, this error can also occur when memory is not running out at all, because PuTTY receives data in the wrong format. In SSH-2 and also in SFTP, the server sends the length of each message before the message itself; so PuTTY will receive the length, try to allocate space for the message, and then receive the rest of the message. If the length PuTTY receives is garbage, it will try to allocate a ridiculous amount of memory, and will terminate with an «Out of memory» error.

This can happen in SSH-2, if PuTTY and the server have not enabled encryption in the same way (see question A.7.3 in the FAQ).

This can also happen in PSCP or PSFTP, if your login scripts on the server generate output: the client program will be expecting an SFTP message starting with a length, and if it receives some text from your login scripts instead it will try to interpret them as a message length. See question A.7.4 for details of this.

10.7 «Internal error», «Internal fault», «Assertion failed»

Any error beginning with the word «Internal» should never occur. If it does, there is a bug in PuTTY by definition; please see appendix B and report it to us.

Similarly, any error message starting with «Assertion failed» is a bug in PuTTY. Please report it to us, and include the exact text from the error message box.

10.8 «Unable to use key file», «Couldn’t load private key», «Couldn’t load this key»

Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) when trying public-key authentication, or given by Pageant when trying to load a private key.

If you see one of these messages, it often indicates that you’ve tried to load a key of an inappropriate type into PuTTY, Plink, PSCP, PSFTP, or Pageant.

You may have tried to load an SSH-2 key in a «foreign» format (OpenSSH or ssh.com ) directly into one of the PuTTY tools, in which case you need to import it into PuTTY’s native format ( *.PPK ) using PuTTYgen – see section 8.2.12.

Alternatively, you may have specified a key that’s inappropriate for the connection you’re making. The SSH-2 and the old SSH-1 protocols require different private key formats, and a SSH-1 key can’t be used for a SSH-2 connection (or vice versa).

10.9 «Server refused our key», «Server refused our public key», «Key refused»

Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) when trying public-key authentication.

If you see one of these messages, it means that PuTTY has sent a public key to the server and offered to authenticate with it, and the server has refused to accept authentication. This usually means that the server is not configured to accept this key to authenticate this user.

This is almost certainly not a problem with PuTTY. If you see this type of message, the first thing you should do is check your server configuration carefully. Common errors include having the wrong permissions or ownership set on the public key or the user’s home directory on the server. Also, read the PuTTY Event Log; the server may have sent diagnostic messages explaining exactly what problem it had with your setup.

Section 8.3 has some hints on server-side public key setup.

10.10 «Access denied», «Authentication refused»

Various forms of this error are printed in the PuTTY window, or written to the PuTTY Event Log (see section 3.1.3.1) during authentication.

If you see one of these messages, it means that the server has refused all the forms of authentication PuTTY has tried and it has no further ideas.

It may be worth checking the Event Log for diagnostic messages from the server giving more detail.

This error can be caused by buggy SSH-1 servers that fail to cope with the various strategies we use for camouflaging passwords in transit. Upgrade your server, or use the workarounds described in section 4.28.11 and possibly section 4.28.12.

10.11 «No supported authentication methods available»

This error indicates that PuTTY has run out of ways to authenticate you to an SSH server. This may be because PuTTY has TIS or keyboard-interactive authentication disabled, in which case see section 4.23.4 and section 4.23.5.

10.12 «Incorrect MAC received on packet» or «Incorrect CRC received on packet»

This error occurs when PuTTY decrypts an SSH packet and its checksum is not correct. This probably means something has gone wrong in the encryption or decryption process. It’s difficult to tell from this error message whether the problem is in the client, in the server, or in between.

In particular, if the network is corrupting data at the TCP level, it may only be obvious with cryptographic protocols such as SSH, which explicitly check the integrity of the transferred data and complain loudly if the checks fail. Corruption of protocols without integrity protection (such as HTTP) will manifest in more subtle failures (such as misdisplayed text or images in a web browser) which may not be noticed.

Occasionally this has been caused by server bugs. An example is the bug described at section 4.28.8, although you’re very unlikely to encounter that one these days.

In this context MAC stands for Message Authentication Code. It’s a cryptographic term, and it has nothing at all to do with Ethernet MAC (Media Access Control) addresses, or with the Apple computer.

10.13 «Incoming packet was garbled on decryption»

This error occurs when PuTTY decrypts an SSH packet and the decrypted data makes no sense. This probably means something has gone wrong in the encryption or decryption process. It’s difficult to tell from this error message whether the problem is in the client, in the server, or in between.

If you get this error, one thing you could try would be to fiddle with the setting of «Miscomputes SSH-2 encryption keys» (see section 4.28.10) or «Ignores SSH-2 maximum packet size» (see section 4.28.5) on the Bugs panel.

10.14 «PuTTY X11 proxy: various errors»

This family of errors are reported when PuTTY is doing X forwarding. They are sent back to the X application running on the SSH server, which will usually report the error to the user.

When PuTTY enables X forwarding (see section 3.4) it creates a virtual X display running on the SSH server. This display requires authentication to connect to it (this is how PuTTY prevents other users on your server machine from connecting through the PuTTY proxy to your real X display). PuTTY also sends the server the details it needs to enable clients to connect, and the server should put this mechanism in place automatically, so your X applications should just work.

A common reason why people see one of these messages is because they used SSH to log in as one user (let’s say «fred»), and then used the Unix su command to become another user (typically «root»). The original user, «fred», has access to the X authentication data provided by the SSH server, and can run X applications which are forwarded over the SSH connection. However, the second user («root») does not automatically have the authentication data passed on to it, so attempting to run an X application as that user often fails with this error.

If this happens, it is not a problem with PuTTY. You need to arrange for your X authentication data to be passed from the user you logged in as to the user you used su to become. How you do this depends on your particular system; in fact many modern versions of su do it automatically.

10.15 «Network error: Software caused connection abort»

This is a generic error produced by the Windows network code when it kills an established connection for some reason. For example, it might happen if you pull the network cable out of the back of an Ethernet-connected computer, or if Windows has any other similar reason to believe the entire network has become unreachable.

Windows also generates this error if it has given up on the machine at the other end of the connection ever responding to it. If the network between your client and server goes down and your client then tries to send some data, Windows will make several attempts to send the data and will then give up and kill the connection. In particular, this can occur even if you didn’t type anything, if you are using SSH-2 and PuTTY attempts a key re-exchange. (See section 4.20.2 for more about key re-exchange.)

(It can also occur if you are using keepalives in your connection. Other people have reported that keepalives fix this error for them. See section 4.14.1 for a discussion of the pros and cons of keepalives.)

We are not aware of any reason why this error might occur that would represent a bug in PuTTY. The problem is between you, your Windows system, your network and the remote system.

10.16 «Network error: Connection reset by peer»

This error occurs when the machines at each end of a network connection lose track of the state of the connection between them. For example, you might see it if your SSH server crashes, and manages to reboot fully before you next attempt to send data to it.

However, the most common reason to see this message is if you are connecting through a firewall or a NAT router which has timed the connection out. See question A.7.8 in the FAQ for more details. You may be able to improve the situation by using keepalives; see section 4.14.1 for details on this.

Note that Windows can produce this error in some circumstances without seeing a connection reset from the server, for instance if the connection to the network is lost.

10.17 «Network error: Connection refused»

This error means that the network connection PuTTY tried to make to your server was rejected by the server. Usually this happens because the server does not provide the service which PuTTY is trying to access.

Check that you are connecting with the correct protocol (SSH, Telnet or Rlogin), and check that the port number is correct. If that fails, consult the administrator of your server.

10.18 «Network error: Connection timed out»

This error means that the network connection PuTTY tried to make to your server received no response at all from the server. Usually this happens because the server machine is completely isolated from the network, or because it is turned off.

Check that you have correctly entered the host name or IP address of your server machine. If that fails, consult the administrator of your server.

Unix also generates this error when it tries to send data down a connection and contact with the server has been completely lost during a connection. (There is a delay of minutes before Unix gives up on receiving a reply from the server.) This can occur if you type things into PuTTY while the network is down, but it can also occur if PuTTY decides of its own accord to send data: due to a repeat key exchange in SSH-2 (see section 4.20.2) or due to keepalives (section 4.14.1).

10.19 «Network error: Cannot assign requested address»

This means that the operating system rejected the parameters of the network connection PuTTY tried to make, usually without actually trying to connect to anything, because they were simply invalid.

A common way to provoke this error is to accidentally try to connect to port 0, which is not a valid port number.

Источник

Почему не могу скопировать свой ssh на другую ноду?

Простой 2 комментария

Потому что после опции -i должен идти путь к файлу с открытым ключом.

Use only the key(s) contained in identity_file (rather than looking for identities via ssh-add(1) or in the default_ID_file). If the filename does not end in .pub this is added. If the filename is omitted, the default_ID_file is used.

Note that this can be used to ensure that the keys copied have the comment one prefers and/or extra options applied, by ensuring that the key file has these set as preferred before the copy is attempted.

Что вы сказали — то команда и пытается сделать: использовать ключ root@192.168.1.150 которого не находит, о чем вам и сообщает.

Источник

Bitrix error while copying ssh key

Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов в рунете Pyatilistnik.org. В прошлый раз мы с вами разобрали ошибку, что для устройства не установлены драйверы (код 28). Идем далее и сегодня хочу с вами поделиться практическими знаниями, по устранению ошибки в open ssh клиенте Windows. Звучит она вот так, что на секретный ключ id_rca bad permissions (WARNING: UNPROTECTED PRIVATE KEY FILE, Permission denied publickey). В результате подключиться не получается. Давайте переходить от слов к делу.

Как выглядит ошибка id_rsa bad permissions

В командной строке Windows при попытке подключения выскакивает ошибка:

Как устранить ошибку Permission denied (publickey)

Проблема тут в том, что файл id_rca, который располагается в директории пользователя от имени которого запускается команда, имеет в списке доступа другие группы и пользователей, и вам это нужно избежать. Тут три варианта решения задачи:

Используем скрипт PowerShell

# Устанавливаем переменную для ключевого файла:
New-Variable -Name Key -Value «$env:UserProfile.sshid_rsa»

# Удаляем наследование:
Icacls $Key /c /t /Inheritance:d

# Делаем владельцем файла текущего пользователя:
# Key’s within $env:UserProfile:
Icacls $Key /c /t /Grant $:F

# Ключ вне $env:UserProfile:
TakeOwn /F $Key
Icacls $Key /c /t /Grant:r $:F

# Удаляем всех пользователей, кроме владельца из ACL:
Icacls $Key /c /t /Remove:g Administrator «Authenticated Users» BUILTINAdministrators BUILTIN Everyone System Users

# Проверка:
Icacls $Key

# Удаляем переменную:
Remove-Variable -Name Key

Иногда, данный скрипт все же не всех удалят пользователей из ACL, так, что если опять получаете ошибку, то зайдите и проверьте через графический интерфейс.

Редактирование ACL через графический интерфейс

Тут все просто, переходите в расположение файла:

Щелкаем по файлу правым кликом, из контекстного меню выбираем пункт свойства и переходим на вкладку «Безопасность«. Нажмите кнопку «Дополнительно (Advanced)«

Отключаем наследование и сохраняем текущие разрешения «Преобразовать унаследованные разрешения в явные разрешения данного объекта (Convert inherited permission into explicit permissions on this object«.

Далее если вы не являетесь текущим владельцем данного файла, то сделайте себя им и так же удалите потом всех кроме себя в данном списке доступа.

Сохраняем все, после этого у вас должна пропасть ошибка «id_rsa»: bad permissions» и «Permission denied (publickey)».

Используем скрипт командной строки

Во первых вам необходимо создать bat-файл. После чего запустите командную строку от имени администратора и запустите созданный ранее bat-файл.

# Установить переменную ключевого файла::
Set Key=»%UserProfile%.sshid_rsa»

::# Удалить наследование:
Icacls %Key% /c /t /Inheritance:d

::# Установить право собственности на владельца:
:: # Key’s within %UserProfile%:
Icacls %Key% /c /t /Grant %UserName%:F

:: # Ключ outside на %UserProfile%:
TakeOwn /F %Key%
Icacls %Key% /c /t /Grant:r %UserName%:F

::# Удалить всех пользователей, кроме владельца:
Icacls %Key% /c /t /Remove:g «Authenticated Users» BUILTINAdministrators BUILTIN Everyone System Users

Источник

Устранение неполадок SSH: ошибки аутентификации

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:

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

После установления соединения и инициирования протокола система может проверить подключение пользователя к системе. SSH поддерживает множество механизмов аутентификации. В этом руководстве рассмотрены два наиболее распространенных механизма: парольная аутентификация и аутентификация на основе SSH-ключей.

Требования

• Убедитесь, что можете подключиться к виртуальному серверу через консоль.
• Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Отказ в доступе (парольная аутентификация)

Примечание: Если вы настроили на сервере SSH-ключи и отключили PasswordAuthentication, сервер не поддерживает паролей. Используйте SSH-ключ, чтобы подключиться к серверу.

Клиенты PuTTY и OpenSSH выдают такое сообщение:

root@111.111.111.111’s password:
Permission denied (publickey,password).
PuTTY Error output
root@111.111.111.111’s password:
Access denied
Server sent disconnect message
type 2 (protocol error):
«Too many authentication failures for root»

Это значит, что аутентификация прошла неудачно. Ошибка может быть вызвана рядом проблем. Вот несколько советов по устранению этой ошибки:

• Убедитесь, что вы используете правильное имя пользователя. В CoreOS используйте пользователя core. В FreeBSD используйте аккаунт пользователя freebsd.
• Парольная аутентификация пользователя может быть нарушена. Проверьте, поддерживает ли парольную аутентификацию веб-консоль сервера. Если она не поддерживает пароли, вам придется попытаться сбросить пароль или обратиться за помощью к службе поддержки, чтобы восстановить доступ.
• Убедитесь, что сервер поддерживает парольную аутентификацию.

Отказ в доступе (аутентификация на основе SSH-ключей)

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

Читайте также:

Вы можете получить такую ошибку:

Permission denied (publickey).
PuTTY Error output
Disconnected: No supported authentication methods available (server sent: publickey)

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

• Убедитесь, что файл authorized_keys и сам закрытый ключ имеют правильные права доступа и собственности.
• Убедитесь, что сервер поддерживает аутентификацию на основе ключей SSH.
• Убедитесь, что клиент SSH может получить закрытый ключ. Если вы используете PuTTY, убедитесь, что ключи SSH правильно настроены в сессии. Если вы используете OpenSSH, убедитесь, что у закрытого ключа SSH есть соответствующие привилегии.
• Убедитесь, что файл authorized_keys содержит правильный открытый ключ, и что открытый ключ добавлен на сервер.
• Возможно, вы используете закрытый ключ, который больше не поддерживается сервисом OpenSSH. Эта ошибка обычно затрагивает серверы OpenSSH 7+ при использовании закрытого DSA-ключа SSH. Обновите конфигурацию сервера.

Консоль не поддерживает пароли

Если вы не можете восстановить доступ к консоли, это может указывать на проблемы с файловой системой или конфигурацией в подсистеме PAM, которые влияют на механизм аутентификации. Эта ошибка также повлияет на попытки сбросить пароль root и войти в систему через консоль.

В консоли появляется форма аутентификации:

Ubuntu 14.04.4 LTS server tty1
server Login:
Password:

Но после ввода пароля появляется ошибка:

После сброса пароля вы получите:

You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:

Повторно введите текущий пароль. Если соединение закроется, возможно, вы допустили ошибку, повторно вводя пароль. Повторите попытку.

При успешном завершении вам будет предложено дважды ввести новый пароль:

Enter new UNIX password:
Retype new UNIX password:

Однако если после повторного ввода правильного нового пароля сессия перезапустится (т.е. снова вернется форма для входа в систему) или появится сообщение об ошибке, это означает, что проблема в одном из файлов, в котором хранятся данные аутентификации.

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

Устранение неполадок

Проверка доступных методов аутентификации

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

debug1: Authentications that can continue: publickey,password

Если вы не нашли в списке метод аутентификации, который хотите использовать, откройте файл /etc/ssh/sshd_config. В нём часто допускается ошибка: PasswordAuthentication имеет значение yes, а PermitRootLogin – no или without-password для пользователя root.

Исправьте эту ошибку, перезапустите сервис.

Настройка прав доступа и собственности

Сервер и клиент OpenSSH имеют строгие требования к привилегиям и правам собственности на файлы ключей.

Сервер и клиент OpenSSH должны иметь следующие права:

./ssh должен принадлежать текущему аккаунту.

/.ssh/authorized_keys должен принадлежать текущему аккаунту.

Кроме того, клиент должен также иметь такие права:

/ .ssh / config – 600.

Эти изменения можно внести с помощью консоли.

Проверка открытого и закрытого ключа

Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом

Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.

/.ssh/id_rsa
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f

В среде PuTTY команда PuTTYgen.exe загружает интерфейс, в котором можно использовать опцию Load и импортировать закрытый ключ. PuTTY хранит такие файлы в формате .ppk (нужно знать место хранения файла).

Импортировав ключ, вы увидите окно с разделом Public key for pasting into OpenSSH authorized_keys file. В нём и будет искомый открытый ключ. Выделите текст и вставьте его в файл. Он сгенерирует открытый ключ.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key

Можно проигнорировать комментарий после открытого ключа (imported-openssh-key).

В любом случае этот открытый ключ нужно добавить в файл

OpenSSH 7 и устаревшие ключевые алгоритмы

В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.

Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.

Следовательно, в данном случае лучшим решением будет создать новые ключи и добавить их на хосты.

Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.

Заключение

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

Источник

Ssh-copy-id no identities found error

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

Во-первых, на сервере я создал ssh-ключ, как показано ниже, который был успешным

Во-вторых, попробовал скопировать ключ pub, но не с ошибкой идентификации. Я делаю неправильный шаг здесь?

ОТВЕТЫ

Ответ 1

Вам нужно использовать флаг -i :

Если задана опция -i, то используется файл идентификации (по умолчанию —

/.ssh/id_rsa.pub), независимо от того, есть ли какие-либо ключи в вашем ssh-agent. В противном случае, если это: ssh-add -L предоставляет любой вывод, он использует это, предпочитая файл удостоверения

Ответ 2

Выполнить следующую команду

Если он дает следующую ошибку: Не удалось открыть соединение с вашим агентом аутентификации

Чтобы удалить эту ошибку, выполните следующую команду:

Ответ 3

Создание ключей ssh ​​на клиенте разрешило это для меня

Ответ 4

Идентификатор ssh-copy не может найти файл id_rsa.pub, который генерируется ssh-keygen в вашей системе. Для завершения выполните следующую команду:

• найдите путь к файлу .pub: locate *.pub
• скопируйте путь (например:/home/user_name/.ssh/id_rsa.pub) и выполните следующую команду: ssh-copy-id -i /home/user_name/.ssh/id_rsa.pub hostname

Ответ 5

Вам нужно указать ключ, используя опцию -i.

Ответ 6

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

Enter file in which to save the key (/root/.ssh/id_rsa): Я ПРОСТО ХИТ ВВОД

Убедитесь, что если вы делаете это как пользователь root, вы копируете ключ в каталог пользователя, с которым хотите войти. НЕ корневой пользовательский каталог.

Я выполнял эту операцию в машине, поэтому я полагаю, что ssh-copy-id просто указывает на каталог, в который вы вошли, как по умолчанию.

Надеюсь, это кому-нибудь поможет.

Ответ 7

Самый простой способ:

Это очень просто.

В руководстве по «ss-keygen» объясняется:

«ОПИСАНИЕ ssh-keygen генерирует, управляет и преобразует ключи аутентификации для ssh (1). ssh-keygen может создавать ключи RSA для использования по протоколу SSH версии 1 и DSA, ECDSA или RSA для использования по протоколу SSH версии 2. Тип ключа, который должен быть сгенерирован, указан с опцией -t. Если вызывается без любые аргументы, ssh-keygen генерирует ключ RSA для использования в соединениях протокола SSH.«

Ответ 8

наткнулся на этот, на существующей учетной записи с закрытым ключом, который я скопировал вручную из другого места. поэтому ошибка в том, что открытый ключ отсутствует

так просто сгенерировать один из частных

Ответ 9

Я столкнулся с этой проблемой сегодня, когда настраивал ssh между узлом имени и узлом данных в полностью распределенном режиме между двумя виртуальными машинами в CentOS.

Проблема возникла из-за того, что я выполнил указанную ниже команду из узла данных вместо узла имени ssh-copy -i d -i/home/hduser/.ssh/id_ras.pub hduser @HadoopBox2

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

Ответ 10

В моем случае это отсутствовало расширение .pub ключа. Я вставил его из буфера обмена и сохранил как mykey . Следующая команда вернула описанную ошибку:

Источник

If you’ve ever tried to connect to a remote server using ssh, and received an error message that says “Host key verification failed,” you know how frustrating it can be. This article will show you three ways to fix the problem.

What is a Host Key in SSH?

A Host key is a unique identifier that is used to verify the identity of a remote host. When you connect to a remote host, the Host key is verified against a list of known Host keys. If there is a match, the connection will be allowed to proceed. If there is not a match, the connection will be denied.

The Host key is also used to generate a cryptographic signature for each connection. This signature is used to verify the integrity of the data that is transferred between the client and server.

Understanding error message Host key verification failed

If you receive the error message “Host key verification failed”, it means that the key stored for the host you’re trying to connect to has changed. It is often caused by connecting to a different server than the one you originally connected to (for example, your server has been rebuilt by a new one).

Whenever we connect to a server via SSH, that server’s public key is stored in our home directory. The file is called known_hosts. 

This file is local to the user account and contains the known keys for remote hosts. These are collected from the hosts when connecting for the first time.

As with those keys stored in the file, ~/.ssh/known_hosts, these keys are used to verify the identity of the remote host, thus protecting against impersonation or man-in-the-middle attacks.

When we reconnect to the same server, the SSH connection will verify the current public key matches the one we have saved in our known_hosts file. If there is a match, the connection will proceed. If the match fails, ssh will fail with an error message Host key verification failed happens.

Example of Host key verification failed

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is x. Please contact your system administrator.
Add correct host key in /home/ec2-user/.ssh/known_hosts to get rid of this message.

Offending RSA key in /home/ec2-user.ssh/known_hosts:222 RSA host key for www.howtouselinux.com has changed and you have requested strict checking.Host key verification failed.

Methods to fix problem of Host key verification failed

Host key verification failed error occurs when the server’s host key does not match the key that was expected. This can happen when the server’s key has been changed, or when the key has been compromised. 

Here are three ways to fix this Host key verification failed error.

• Manually edit the “~/.ssh/known_hosts” file and remove the old key for the host you’re trying to connect to. This will allow you to connect to the new server without any problems.
• Use the “ssh-keygen -R” command to remove the old key from your “~/.ssh/known_hosts” file. This will allow you to connect to the new server without any problems.
• Use the “-o StrictHostKeyChecking=no” option when connecting to the server. This will prevent ssh from checking the “~/.ssh/known_hosts” file, and will allow you to connect to the new server without any problems.

Remove old host key info from known_hosts file

The easiest way to fix the problem of Host key verification failed is removing the old host key info and reconnect the server.

We can fix this issue with the following steps.

• Locate our known_hosts file
• open in a general text editor with vi /home/user/.ssh/known_hosts
• search the old host name and press “ESC dd” to delete the line.
• save the changes by pressing “esc” and typing “:wq!”.
• reconnect the server

Remove old host key info with ssh-keygen command

We can also remove the old host key with ssh-keygen command.

Open up a terminal session, and type one of the following

• ssh-keygen -R hostname
• ssh-keygen -R ipaddress
• ssh-keygen -f “/home/ec2-user.ssh/known_hosts” -R “192.168.0.106”

Disable SSH stricthostkeychecking option

The stricthostkeychecking option in SSH is a security feature that verifies the host key information for each connection.

If there is a problem with the host key information, the connection will not be allowed to proceed. This option can be disabled, which will allow the connection to proceed even if there is a problem with the host key information.

• Open up a terminal window.
• Type in the following command: ssh -o StrictHostKeyChecking=no hostname

This command removes the old host key for the device in the known_hosts file and replaces old host key with the new host key.

Understanding SSH known_hosts File with Examples

Как исправить ошибку аутентификации SSH

Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.

В чем суть ошибки

У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.

Аутентификация — это проверка подлинности. Например, у вас есть сервер на cloud.timeweb.com . Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы.

Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю.

Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:

Но причины появления ошибки не ограничиваются только неправильным паролем или не теми ключами. Сбой может возникать также из-за повреждения системных файлов или неверно выставленных прав доступа.

Ниже разберемся с наиболее частыми ситуациями.

Ошибка при использовании пароля

Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:

1. Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
2. Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
3. Если в вашем файле конфигурации параметр PasswordAuthentication имеет значение `no`, то подключиться по паролю не получится. Чтобы исправить ситуацию, измените значение на `yes`.

С паролем связано и появление ошибки su authentication failure. Вернее, с отсутствием парольной проверки у пользователя root. Если при такой конфигурации выполнить команду `su` без параметров, то вернется ошибка. Чтобы ее устранить, достаточно назначить пользователю root парольную защиту.

Ошибка при использовании ключей

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

Использование большого количества ключей без явного указания нужного приводит еще к одной ошибке:

Причина сбоя — превышение числа попыток. Это случается из-за того, что SSH-клиент пытается подключиться к хосту, используя все доступные ключи. Исправить ситуацию можно с помощью опций IdentitiesOnly и IdentityFile. Пример запроса на подключение:

Чтобы каждый раз не прописывать это в командной строке при подключении, можно указать необходимую настройку в конфигурационном файле SSH

/.ssh/config. Пример такой настройки:

В этом случае SSH будет использовать только идентификаторы, указанные в файлах ssh_config, плюс идентификатор, указанный в командной строке. Идентификаторы, предоставленные агентом, будут игнорироваться.

При использовании ssh-ключей может возникнуть еще одна ошибка:

Ее причиной может быть ввод неверной ключевой фразы.

Если вы потеряете ключевую фразу, восстановить ее будет невозможно. Вам нужно будет сгенерировать новую пару значений для Secure Shell.

Восстановление открытого ключа

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

Самый просто способ — использовать утилиту ssh-keygen.

Запустите терминал и выполните команду:

/.ssh/id_rsa — это путь к закрытому части, которая хранится на компьютере. В ответ вы получите последовательность символов. Это и есть открытая часть, которую необходимо добавить на сервер.

В среде Windows решить ту же задачу можно с помощью утилиты PuTTYgen, которая входит в набор PuTTY. В ней есть кнопка Load, через которую вы можете загрузить закрытый ключ. Для этого нужно лишь знать директорию, в которой он хранится на компьютере.

После импорта вы увидите окно с полем `Public key for…`. В нём отобразится открытая часть, которую можно скопировать и отправить на сервер.

Восстановить закрытую часть по открытой нельзя — это противоречит основам безопасности.

На что еще обратить внимание

У понятия « authentication failed» перевод дает весьма общее представление о причине сбоя. Проблема может крыться не только в пароле или ключах. Значение имеют также выставленные права доступа и алгоритмы шифрования.

Неправильная конфигурация клиента

Распространенная ошибка — использование клиента SSH/SFTP (SSH, PuTTY, Filezilla) без правильной настройки всех необходимых параметров, таких как хост, порт, имя пользователя или закрытый ключ.

Другая частая проблема возникает, когда вы используете неподдерживаемый сертификат. Например, пытаетесь добавить в PuTTY файл ключа *.pem вместо файла ключа *.ppk.

Противоречия в файле конфигурации

Убедитесь, что в файле /etc/ssh/sshd_config установлены параметры, которые не противоречат друг другу. Такое может быть, например, при отключении парольной проверки или запрете на подключение для пользователя root.

Распространенный пример конфликта: у параметра PasswordAuthentication установлено значение `yes`, а у параметра PermitRootLogin — значение `no` или `without-password`. Из-за этого сервер не понимает, как проверять пользователей, и не пускает никого.

Настройка прав доступа

У OpenSSH строгие правила к тому, кто должен быть владельцем файлов и какие на них должны быть выставлены права доступа.

Убедитесь, что на сервере выставлены следующие доступы:

./ssh принадлежит текущему аккаунту.

/.ssh/authorized_keys принадлежит текущему аккаунту.

На клиенте также проверьте разрешения следующих файлов:

/ .ssh / config – 600.

Почему важен владелец? Например, вы настраивали доступ через Secure Shell от имени одного пользователя, а затем пытаетесь подключиться под другим аккаунтом, у которого нет прав даже на чтение содержимого защищенных директорий с аутентификационными данными.

Использование устаревших алгоритмов

В OpenSSH начиная с седьмой версии не поддерживаются старые ключи, которые используют алгоритм цифровой подписи — DSA. Ключи ssh-dss считаются слишком слабыми для того, чтобы можно было доверять им защиту подключения к серверу.

Если у вас старые ключи, оптимальное решение — сгенерировать и добавить на хосты новые, которые основаны на более стойких алгоритмах.

Есть и альтернатива, но пользоваться ей придется на свой страх и риск. Речь идет об изменении файла конфигурации /etc/ssh/sshd_config. Если установить параметру PubkeyAcceptedKeyTypes значение `+ssh-dss`, то можно будет использовать ключи, сгенерированные с помощью устаревшего алгоритма цифровой подписи.

Дополнительные опции могут понадобиться и на SSH-клиенте. Например, при подключении к серверу с ПО, которое давно не обновлялось. В частности, такие проблемы возникают при подключении к хостам на CentOS 6, поддержка которой прекращена в конце 2020 года. Чтобы исправить эту ошибку, необходимо добавить опцию `-oHostKeyAlgorithms=+ssh-dss`:

Ошибки на сторонних сервисах

Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к VK API пользователи сталкиваются с сообщением user authorization failed invalid session . Устранить такой сбой самостоятельно не получится — нужно обращаться в поддержку.

Заключение

Причина ошибки аутентификации может быть как на стороне клиента, так и на стороне сервера. Начинайте диагностику с самого простого: проверьте правильность имени пользователя и пароля, если он используется, выбор SSH-ключа в агенте. Если это не помогает устранить сбой, проверьте конфигурацию подключения и права доступа к файлам, которые OpenSSH использует для проверки подлинности пользователей.

Источник

Добавление нового хоста в пул

Делаю на VPS так:
1. Manage Hosts in the pool > 1. Add new host in the pool
Ввожу «server2» и выдаёт ошибку:

Следую рекомендации и смотрю файл логов

Была такая же проблема при разворорачивании на amazon.
Хотя хост был доступный.

Помог 3 пункт: Reboot host.

Так же самая ситуация. не создается 2й пул!

Пишет:
10-20-15_14:36:25: SSH_INIT — get key text from file
10-20-15_14:36:25: SSH_INIT — root connect to 192.168.10.188:22
10-20-15_14:36:25: SSH_CONNECT — No route to host 192.168.10.188:22

Такая же ошибка, почему молчат разработчики?

Только что проделал данную процедуру, все ок.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Перезагружали виртуальную машину?

Нет, ничего не перегружал. Сразу заработало. Нужно лишь дождаться завершения задачи.
Проверить можно чз меню 5.

Никакого фаирвола между машинами нет?

Покажите лог из файла, указанного в содержании ошибки у вас на скриншоте.

Перезагружали виртуальную машину?

Нет, ничего не перегружал. Сразу заработало. Нужно лишь дождаться завершения задачи.
Проверить можно чз меню 5.

Никакого фаирвола между машинами нет?

вот ошибка файла ssh_keycopy.log:

12-22-15_20:31:11: SSH_INIT — get key text from file
12-22-15_20:31:11: SSH_INIT — root connect to 192.168.56.102:22
12-22-15_20:31:11: SSH_CONNECT — No route to host 192.168.56.102:22

12-22-15_20:31:11: SSH_INIT — get key text from file
12-22-15_20:31:11: SSH_INIT — root connect to 192.168.56.102:22
12-22-15_20:31:11: SSH_CONNECT — No route to host 192.168.56.102:22

В натройках сети стоит: Тип подключения — Виртуальный адаптер хоста; Имя — Virtualbox Host-Only Ethernet adapter

Пробовал тип ставить NAT — такаяже ошибка.

Да я же уже все написал:
В натройках сети виртуальной машины стоит: Тип подключения — Виртуальный адаптер хоста; Имя — Virtualbox Host-Only Ethernet adapter
Виртуальная машина: VMBitrix5.1.5-virtualbox — в самой машине (linuxe) вообще ничего не трогал, все по умолчанию. Если нужен лист какогото файла — скажите какого.
IFCONFIG машины:
eth0 Link encap:Ethernet HWaddr 08:00:27:A9:8C:3B
inet addr:192.168.56.101 Bcast:192.168.56.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fea9:8c3b/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1180 (1.1 KiB) TX bytes:1298 (1.2 KiB)

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

До 192.168.56.101 с компа пингутеся. Да и сайт на этом адресе нормально работает. А вот второй хост никак не создать.

2я машина точно сконфигурирована заранее — пароли юзерам root и bitrix сменены при первом входе?

Источник