☰

OpenSSH не принимает ключи ECDSA

tag-icon • tag-icon ssh
OpenSSH не принимает ключи ECDSA

Я только что сгенерировал ключ ECDSA с помощью ssh-keygen:

ssh-keygen -t ecdsa -b 521

Затем я скопировал этот ключ на свой сервер:

cat .ssh/id_ecdsa.pub | ssh myserver "tee -a .ssh/authorized_keys"

Я проверил, что мой ключ находится в файле.

Однако при попытке подключиться мое соединение отклоняется:

ssh -v -i .ssh/id_ecdsa myserver

Журналы:

OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to myserver [192.168.1.1] port 22.
debug1: Connection established.
debug1: identity file .ssh/id_ecdsa type 3
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-521
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-521
debug1: identity file .ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 10:27:b8:78:2c:e1:e3:42:8e:e3:66:c4:cc:4e:f1:c0
debug1: Host 'myserver' is known and matches the RSA host key.
debug1: Found key in /home/naftuli/.ssh/known_hosts:73
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering ECDSA public key: .ssh/id_ecdsa
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Нашел это в журналах сервера:

auth.info sshd[13874]: userauth_pubkey: unsupported public key algorithm: ecdsa-sha2-nistp521 [preauth]

И мой клиент, и мой сервер используют OpenSSH. Версия OpenSSH сервера — OpenSSH 6.1, версия OpenSSH моего клиента — OpenSSH 5.9.

Как узнать, какие ключевые алгоритмы поддерживает мой сервер?

решение1

Как и многие другие встраиваемые системы, OpenWrt используетdropbearкак его ssh-сервер, а не более тяжеловесный OpenSSH, который обычно можно увидеть в системах Linux. Более старые версии dropbear поддерживают только ключи RSA и DSA; поддержка ECDSA не была добавлена ​​доверсия 2013.62(который был выпущен всего несколько дней назад).

Он должен скоро появиться в Barrier Breaker (ствол); но вы не увидите его в Attitude Adjustment.

решение2

ecdsaподдерживается изopenssh-сервер версии 5.7. Какую версию openssh-server вы используете? запустите, dpkg -l | grep openssh-server | awk '{print $3}' | cut -d: -f2чтобы узнать версию.

решение3

Если ваша системаRed Hat Enterprise Linux 6.4(или старше) илиФедора 19(или более ранние), обратите внимание, что ECDSA оттуда был удален. У меня нет никаких подробностей, почему это было (возможно, по юридическим причинам):https://www.mail-archive.com/[email protected]/msg00755.html

решение4

Оставлю это здесь, потому что со мной произошло следующее:

День 1: Настроив новый компьютер, я скопировал ключи (сначала свои) и смог без проблем войти в систему.

День 2: Я не могу войти с моим ключом ed25519. Что? Я добавляю ключ RSA; он работает. Я генерирую новый ключ ed25519 иэтоработает... а мой старый нет. Какого хрена?

Оказывается, после тестирования я установил свой ключ в root's .ssh/authorized_keys в качестве резервной копии... и забыл исправить разрешения на этот файл. Поэтому openssh занес мой ключ в черный список, из-за чего я не смог войти. Исправление разрешений на /root/.ssh/authorized_keys позволило мне войтикак мой пользователь.

Связанный контент