升级Fedora 33后ssh许可被拒绝(公钥) [英] ssh Permission denied (publickey) after upgrade Fedora 33
问题描述
我已经在这个Stackoverlow问题上尝试了许多答案,就像我现在问的一样,但仍然无法解决我的问题,我正在尝试通过 ssh 进行克隆,但总是获得 Permission拒绝(公钥)
i have been trying many answers on this Stackoverlow questions same like i am asking now, but still can't resolve my problem, i am trying to clone by ssh but always got Permission denied (publickey)
当我运行 GIT_SSH_COMMAND ="ssh -vvv"时,git clone git@bitbucket.org:myusername/my-api.git
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ssh-rsa
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: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug1: kex: curve25519-sha256@libssh.org need=64 dh_need=64
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: ssh-rsa SHA256:kkXQOXSRBEiUtuE8AikLLLwbHaxvSc0ojez9YXaGp2A
debug3: hostkeys_foreach: reading file "/home/alienwarepocket/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/alienwarepocket/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys from bitbucket.org
debug3: hostkeys_foreach: reading file "/home/alienwarepocket/.ssh/known_hosts"
debug3: record_hostkey: found key type RSA in file /home/alienwarepocket/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 18.205.93.2
debug1: Host 'bitbucket.org' is known and matches the RSA host key.
debug1: Found key in /home/alienwarepocket/.ssh/known_hosts:1
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug1: SSH2_MSG_NEWKEYS received
debug2: set_newkeys: mode 0
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/alienwarepocket/.ssh/id_rsa RSA SHA256:ktMzaalYyvU9Ev1bgELXatabkUkdcT828O0PppnNiV4M explicit agent
debug2: pubkey_prepare: done
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred 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 public key: /home/alienwarepocket/.ssh/id_rsa RSA SHA256:ktMzaalYyvU9Ev1bgELXatabkUkdcT828O0PppnNiV4M explicit agent
debug1: send_pubkey_test: no mutual signature algorithm
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
git@bitbucket.org: Permission denied (publickey).
fatal: Could not read from remote repository.
升级Fedora 33后,出现此问题,在Fedora 32上没有问题
after i upgrade Fedora 33, i got this issue, it was no issue on Fedora 32
推荐答案
这可能与"更改有关Fedora33中的/StrongCryptoSettings2 "
默认策略的更改为:
The changes for default policy are:
- 仅保留TLS 1.2(以及可用时的TLS 1.3)作为已启用的协议,并将TLS 1.x,x< = 1移至旧版.
- 在默认设置中需要2048以上的有限字段参数(RSA,Diffie-Hellman)
- 禁用SHA1支持在签名(X.509证书,TLS,IPSEC握手)中使用
"升级/兼容性影响"前面提到的链接部分明确提到:
The "Upgrade/compatibility impact" section of the aforementioned link clearly mentions:
新设置可能会破坏连接到使用弱算法的服务器的软件.
可以通过将系统切换到Fedora 32策略级别来获得兼容性:
It may be that the new settings break software that connects to servers which utilize weak algorithms.
Compatibility can be obtained by switching the system to Fedora 32 policy level:
update-crypto-policies --set DEFAULT:FEDORA32
不推荐:如果您可以使用ed25519,那就更好了.
NOT RECOMMENDED though: if you can use an ed25519, this is better.
如 Peque 的 sshd_config
As mentioned in Peque's answer, you can add on your ~/.ssh/config
an option initially found in sshd_config
PubkeyAcceptedKeyTypes
Specifies the key types that will be accepted for public key
authentication as a list of comma-separated patterns.
因此,如果您不能使用ed25519,则可以针对一个特定主机,通过以下方式允许使用 id_rsa
键:
So if you cannot use ed25519, you can, for one specific host, allow the use of id_rsa
keys with:
Host aHost
Hostname a.hostname.com
PubkeyAcceptedKeyTypes +ssh-rsa
最后:升级后,请仔细检查您的权限:
Finally: Double-check your permissions after upgrade:
-
〜/.ssh
是775
drwxrwxr-x
. -
〜/.ssh/id_rsa
是600
-rw -------
. -
〜/.ssh/id_rsa.pub
是644
-rw-r--r-
. -
〜/.ssh/config
是600
-rw -------
. 远程服务器上的 -
〜/.ssh/authorized_keys
是600
-rw -------
~/.ssh
is775
drwxrwxr-x
.~/.ssh/id_rsa
is600
-rw-------
.~/.ssh/id_rsa.pub
is644
-rw-r--r--
.~/.ssh/config
is600
-rw-------
.~/.ssh/authorized_keys
on remote server is600
-rw-------
但是现在似乎建议使用 ssh-keygen -t ed25519
键.
But using ssh-keygen -t ed25519
keys seems to be recommended now.
这篇关于升级Fedora 33后ssh许可被拒绝(公钥)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!