LINUX.ORG.RU

вопрос по ssh

 


0

1

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

user@vak:~$ ssh -v 10.0.2.102
OpenSSH_8.2p1 Ubuntu-4ubuntu0.11, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /home/user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 10.0.2.102 [10.0.2.102] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type 0
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/user/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk type -1
debug1: identity file /home/user/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.11
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.11
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.11 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.0.2.102:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:emLRZvLhXrrnSMWGMS/5eTgV8aUODlW5petNODQJtgk
debug1: Host '10.0.2.102' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:9
debug1: resetting send seqnr 3
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: resetting read seqnr 3
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/user/.ssh/id_rsa RSA SHA256:x2m1vaFO24i5LdVcU2O603mlMN4v5RMRaP6TffrB6Bk
debug1: Will attempt key: /home/user/.ssh/id_dsa 
debug1: Will attempt key: /home/user/.ssh/id_ecdsa 
debug1: Will attempt key: /home/user/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /home/user/.ssh/id_ed25519 
debug1: Will attempt key: /home/user/.ssh/id_ed25519_sk 
debug1: Will attempt key: /home/user/.ssh/id_xmss 
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/user/.ssh/id_rsa RSA SHA256:x2m1vaFO24i5LdVcU2O603mlMN4v5RMRaP6TffrB6Bk
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Trying private key: /home/user/.ssh/id_ed25519_sk
debug1: Trying private key: /home/user/.ssh/id_xmss
debug1: Next authentication method: password
user@10.0.2.102's password: 

как убрать пароль?

Ответ на: комментарий от PRN

смотрел, сервер говорит:

Mar 29 18:16:29 bel02 sshd[20615]: Authentication refused: bad ownership or modes for directory /home/kuzmin/.ssh

root@bel02:/var/log# ls -la /home/user/.ssh
total 88
drwxrwxrwx  3 user user  4096 мар 28 20:29 .
drwxrwxrwx 96 user user 12288 мар 29 18:16 ..
-rw-------  1 user user  4066 мар 28 20:19 authorized_keys
-rw-------  1 user user  4066 мар 28 20:29 authorized_keys_old
-rw-r--r--  1 user user   208 дек  4 15:53 config
-rw-------  1 user user  1679 фев  4  2022 id_rsa
-rw-------  1 user user  3381 фев  4  2022 id_rsa_git.jinr
-rw-------  1 user user  2590 мар 11  2022 id_rsa_gitjinr
-rw-------  1 user user   744 фев  4  2022 id_rsa_git.jinr.pub
-rw-------  1 user user   564 мар 11  2022 id_rsa_gitjinr.pub
-rw-------  1 user user   392 фев  4  2022 id_rsa.pub
-rw-r--r--  1 user user  3550 фев 26 23:25 known_hosts
-rw-r--r--  1 user user  3326 ноя 28 14:43 known_hosts.old
-rw-------  1 user user 14204 ноя 28 14:47 known_hosts_old
-rw-------  1 user user  1464 сен 24  2020 maxi_maxim
drwxrwxrwx  3 user user  4096 фев  4  2022 w
-rw-rw-r--  1 user user   101 фев  4  2022 wconfig

Однако, тут все абсолютно правильно, непонятки

valentin630
() автор топика
Последнее исправление: valentin630 (всего исправлений: 1)

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

У меня как-то переставали работать ключи RSA - на сервере в логах увидел, что они отвергаются из-за малой длины. В новых версиях повысили требования к минимальной длине ключа.
Или переходить на ED25519 - Ключи для SSH: ED25519 vs RSA

sigurd ★★★★★
()
Последнее исправление: sigurd (всего исправлений: 2)
Ответ на: комментарий от bugfixer

По логике «chmod 700 .ssh» только уменьшит права доступа, поэтому не должно помочь, что и произошло, т.е. не помогло. Единственное, что могу предположить:
/home/user что не нравится owner, хотя по имени совпадает по названию совпадает. Часть директории восстанавливалась через tar.

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

Сервер: Authentication refused: bad ownership or modes for directory /home/user

/home/user что не нравится owner, хотя по имени совпадает по названию совпадает

bad ownership or modes

or modes

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от valentin630

хотя по имени совпадает по названию совпадает

Ну батенька, что Вы тут нас за нос то водите:

bad ownership or modes for directory /home/kuzmin/.ssh

/home/kuzmin/.ssh

И при этом:

root@bel02:/var/log# ls -la /home/user/.ssh

Как это понимать?

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

Просто понимать, что «прокол». Я нашел в чем дело. Начал с «чистого листа» Пара ключей на сервере и хосте были одинаковыми. Если я посылаю с хоста ключ на сервер, он приходит неправильным. Послал с сервера на сервер - заработало и с хоста на сервер. В authorized_keys сейчас 2 разных ключа для одного и того же имени компа.

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

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

предположу что открытый ключ записался прост неверно…

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

Ничего не понял, к каким результатам?

Вообще все это странно, что произошло. Тот «сервер», который перестал работать на вход по ключу, его диски были восстановлены по копии, сделанной ранее через dd (ssd HIKVISION приказал долго жить после года эксплуатации). И вот после восстановления вход по ключу перестал работать со всех других моих компов, а в обратную сторону все хорошо.

Факт: сервер выдает диагностику от фонаря о «bad ownership or modes», а ssh-copy-id посылает на этот сервер неправильный ключ. Все компы имеют одинаковые пары ключей.
ssh-copy-id с «сервера» на самого себя послало правильный ключ, что дало возможность входить по этому ключу и с других компов. Вот такой «компот» неожиданно сварился.

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

Мне кажется у тебя перепутаны ключи. ssh-copy-id просто добавляет в authorized_keys pub часть пары. Возможно ты это делал из под разных пользователей с разными ключами, но это уже гадание на кофейной гуще. Кстати, на всякий случай, у authorized_keys пользователя на сервере тоже должны быть правильные права.

PRN
()
Последнее исправление: PRN (всего исправлений: 1)