Permission denied (publickey)
Привет!
На сервере настроил подключение по ssh-ключу и запретил вход по паролю.
Все работало нормально несколько месяцев, но внезапно при коннекте получаю ошибку «Permission denied (publickey)».
Как решить данную проблему?
Сделай подключение к серверу с ключом -vvv и покажи вывод сюда. И есть ли физический доступ к серверу? И пробовал ли подключаться с других компьютеров/клиентов?
/.ssh/server_rsa -vvv user@user.ddns.net -p5555
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t 3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to user.ddns.net [46.98.89.152] port 55555.
debug1: Connection established.
debug1: identity file /home/sergey/.ssh/server_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/sergey/.ssh/server_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4p1 Debian-10+deb9u1
debug1: match: OpenSSH_7.4p1 Debian-10+deb9u1 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug3: put_host_port: [user.ddns.net]:55555
debug3: load_hostkeys: loading entries for host «[user.ddns.net]:55555» from file
«/home/sergey/.ssh/known_hosts»
debug3: load_hostkeys: found key type ECDSA in file /home/sergey/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: server->client aes128-ctr umac-64-etm@openssh.com none
debug2: mac_setup: setup umac-64-etm@openssh.com
debug1: kex: client->server aes128-ctr umac-64-etm@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA 95:5a:25:6f:16:3f:7c:aa:f0:54:af:bf:7b:f7:87:be
debug3: put_host_port: [46.98.89.152]:55555
debug3: put_host_port: [user.ddns.net]:55555
debug3: load_hostkeys: loading entries for host «[user.ddns.net]:55555» from file «/home/sergey/.ssh/known_hosts»
debug3: load_hostkeys: found key type ECDSA in file /home/sergey/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host «[46.98.89.152]:55555» from file «/home/sergey/.ssh/known_hosts»
debug3: load_hostkeys: found key type ECDSA in file /home/sergey/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host ‘[user.ddns.net]:55555’ is known and matches the ECDSA host key.
debug1: Found key in /home/sergey/.ssh/known_hosts:1
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/sergey/.ssh/server_rsa (0x7f82967e2e10), explicit
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred gssapi-keyex,gssapi-with-mic,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: Offering RSA public key: /home/sergey/.ssh/server_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
2. Физический доступ есть.
3. С других клиентов в сети та же история. Правда, слово-пароль для ключа все-же спрашивает, но итог один — «Permission denied (publickey)».
Источник
How to login by ssh in Alpine Linux without passwords?
I’m using a Android cell phone. I write python program and run the program in Termux. But there some lib can’t be installed or use in Android cell phone, sklearn and tensorflow for example. So I decided to try to use a docker container for my programing envirment. I create a docker image and update it to docker-hub: zwdnet/mypython. Then I installed qemu in Termux，and installed Alpine Linux (alpine-virt-3.10.1-x86_64) in Termux. I followed this pages’ method(It is a Chinese blog, not English): https://stageguard.top/2019/08/15/run-docker-on-qemu-alpine/#1-Docker After this, I use the command
start the alpine linux in back and
login. (After then I installed the docker and run the container success, that is another question.) Now I want to login Apline linux without enter the passwords. First I use
generate the key, and use
to sent the pub key to the Apline linux and changed the /etc/ssh/sshd_config file. At last I restarted the sshd service and logout. But when I login again, It is ask me to enter the password again. I thought maybe that is because I login in with root. So I login and create a new username, and repeat the ahead operators. But I failed. The ssh ask me to enter password again. This is my mod of
/.ssh and the key files.
and this is my /etc/ssh/sshd_config file:
The login information is
I copyed the mykey and mykey.pub to /data/data/com.termux/files/home/.ssh/ , no use. Could you please help me to see how to sovle this problem? Thanks! I’m a Chinese and my English is poor. Please forgive me for the words errors.
Thanks @MarcoLucidi ,but the -i in ssh dose not work.
/.ssh/mykey -p 2222 zym@localhost
/.ssh/authorized_keys file for the user you are trying to login with ( zym )
/.ssh/authorized_k» zym@localhost’s password: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDbOULZS8unYCDJt $
3 Answers 3
i discovered that alpine linux image is shipped with a root user that has no password set yet. And for some reason it seems like not having a password set for root prevents the public key authentication from succeeding when trying to ssh on root account.
try setting a password to root user: ex:
now the command should work with the public key authentication. don’t ask me why.
note: i discovered that because i could connect to a normal user session but not to root session with the same sshd_config, on the same machine, and with the same authorized_keys file (with correct permissions and correct ownership). that was the only thing i could think of and it made the difference.
You indicated in a comment that this user «zym» has UID 0. You also show that zym’s home directory and .ssh directory are owned by UID 1000:
/.ssh/authorized_keys Lists the public keys (DSA, ECDSA, Ed25519, RSA) that can be used for logging in as this user. The format of this file is described above. The content of the file is not highly sensitive, but the recommended permissions are read/write for the user, and not accessible by others.
If this file, the
/.ssh directory, or the user’s home directory are writable by other users, then the file could be modified or replaced by unauthorized users. In this case, sshd will not allow it to be used unless the StrictModes option has been set to “no”.
The actual permissions-checking performed by sshd is complicated. But basically it checks for two things:
- The authorized_keys file must be owned by the user logging in, and it must not be group- or world-writable.
- The directory containing authorized_keys, the .ssh directory, and the home directory must be owned by root or the user logging in, and must not be group- or world-writable.
The OpenSSH server is probably ignoring your authorized_keys file because these requirements aren’t being met. You’re trying to log in as a user with UID 0, while the authorized_keys file, .ssh directory, and home directory are owned by a different UID.
You can fix this by making the UIDs match. Either set «zym» to have UID 1000, or change zym’s home directory and the files contained there to be owned by zym’s actual UID of 0.
Alternately, you can disable this permissions check by setting StrictModes to «no» in sshd_config on the server and restarting sshd.
Источник
Ошибка SSH в Linux. Исправление разрешения denied (publickey)
Главное меню » Операционная система Linux » Ошибка SSH в Linux. Исправление разрешения denied (publickey)
В этом кратком руководстве вы узнаете, как исправить ошибку ssh. “sign_and_send_pubkey: signing failed: agent refused operation Permission denied (publickey)” в Linux.
Е сли вы пытаетесь подключиться к удаленному серверу через SSH, вы можете столкнуться с ошибкой, отказано в доступе. Эта ошибка может произойти по ряду причин. И исправление этой проблемы зависит от причины ошибки.
В нашем случае у нас были общедоступные и закрытые ключи, хранящиеся на рабочем столе Ubuntu 16.04. После выпуска Ubuntu 18.04 мы решили перейти на эту новую версию. Мы предпочитаем новую установку поверх обновлений дистрибутива.
Итак, мы сделали резервную копию основных папок моего домашнего каталога, включая папку .ssh, на которой были открытые и закрытые ключи на внешнем диске. После установки Ubuntu 18.04 мы восстановили все, включая ключи SSH.
Теперь, когда мы попытались подключиться к удаленному серверу с помощью ssh, то подумали, что это сработает сразу, потому что были такие же публичные и закрытые ключи.
Но это не сработало. SSH выдал эту ошибку:
Если вы находитесь в аналогичной ситуации, когда вы скопировали свои SSH-ключи из другого источника, позвольте показать вам, как исправить эту ошибку SSH.
Ошибка исправления отказа от прав (publicickey)
Поэтому проблема заключается в разрешении файлов. Видите ли, когда мы копировали файлы, USB флешка была в формате файла FAT Microsoft. Этот файл не поддерживает разрешения файлов UNIX/Linux.
И, следовательно, разрешения на скопированные ключи ssh были изменены на 777.
Для SSH права доступа к файлу слишком открыты. Просто не разрешено иметь 777 для открытых или закрытых ключей. И вот почему SSH отказался от подключения.
Закрытый ключ должен иметь права на чтение и запись только для пользователя и другие разрешения для группы и других.
Вы должны изменить разрешение, используя команду CHMOD:
Аналогично, открытый ключ не должен иметь права на запись и выполнение для группы и других.
Теперь, когда вы установили правильные разрешения, вы можете снова подключиться к ssh. Он попросит пароль администратора чтобы разблокировать ключи. Введите пароль администратора.
Это также научило нас одному уроку, копирование и вставка файлов – плохая идея, и правильная резервная копия должна быть сделана иначе, все файлы будут иметь опасные разрешения 777 на них. Мне пришлось рекурсивно менять права доступа к файлу во всем каталоге Home и поверьте мне, это было не очень приятно.
Как мы сказали ранее, для этой ошибки могут быть разные причины. Для проблемы, связанной с разрешением на открытие файла, это исправление должно помочь вам исправить ошибку, Permission denied (publickey) в SSH.
Дайте нам знать в разделе комментариев, исправление работает для вас или нет. Также предложите свое мнение о копировании ключей ssh на другие компьютеры.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Источник
