Xác thực SSH-Key không thành công

Tôi đang cố gắng truy cập vào máy chủ CentOS mà tôi không kiểm soát được .. quản trị viên đã thêm khóa công khai của tôi vào máy chủ và khẳng định lỗi thuộc về tôi nhưng tôi không thể tìm ra điều gì sai.

Cấu hình trong .ssh:

tim@tim-UX31A:~$ cat ~/.ssh/config
User root
PasswordAuthentication no
IdentityFile ~/.ssh/id_rsa

Quyền trên các tệp chính của tôi:

tim@tim-UX31A:~$ ls -l ~/.ssh/id_rsa*
-rw------- 1 tim tim 3326 Okt 20 17:28 /home/tim/.ssh/id_rsa
-rw-r--r-- 1 tim tim  746 Okt 20 17:28 /home/tim/.ssh/id_rsa.pub

Nhật ký kết nối mà tôi không thể hiểu được:

tim@tim-UX31A:~$ ssh -vvv root@10.0.12.28
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /home/tim/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "10.0.12.28" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 10.0.12.28 [10.0.12.28] port 22.
debug1: Connection established.
debug1: identity file /home/tim/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/tim/.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1
debug1: match: OpenSSH_6.6.1 pat OpenSSH_6.6.1* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 10.0.12.28:22 as 'root'
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
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
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: 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-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: 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: MACs stoc: 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: compression ctos: none,zlib@openssh.com,zlib
debug2: compression stoc: none,zlib@openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ecdsa-sha2-nistp256
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: MACs ctos: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-sha1,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: curve25519-sha256@libssh.org
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
debug3: send packet: type 30
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug3: receive packet: type 31
debug1: Server host key: 
debug3: hostkeys_foreach: reading file "/home/tim/.ssh/known_hosts"
debug3: record_hostkey: found key type ECDSA in file /home/tim/.ssh/known_hosts:3
debug3: load_hostkeys: loaded 1 keys from 10.0.12.28
debug1: Host '10.0.12.28' is known and matches the ECDSA host key.
debug1: Found key in /home/tim/.ssh/known_hosts:3
debug3: send packet: type 21
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug3: receive packet: type 21
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619ab2b0), explicit, agent
debug2: key: /home/tim/.ssh/id_rsa (0x55ee619bcfa0), agent
debug2: key: tim@Tim-UX31A-Debian (0x55ee619b9370), agent
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,gssapi-keyex,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_lookup gssapi-keyex
debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-keyex
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug3: authmethod_lookup gssapi-with-mic
debug3: remaining preferred: publickey,keyboard-interactive
debug3: authmethod_is_enabled gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available

debug2: we did not send a packet, disable method
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: /home/tim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering RSA public key: tim@Tim-UX31A-Debian
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Điều này thường sẽ giải quyết hầu hết các vấn đề về quyền chính được ủy quyền của SSH ở phía máy chủ , giả sử ai đó đã không thực hiện các thay đổi bổ sung cho các quyền.

sudo chown yourusername:yourusername /home/yourusername/ -R
sudo chmod o-rwx /home/yourusername/ -R

Nếu quản trị viên của bạn đã tạo tệp .ssh / hoặc tệp .ssh / ủy quyền là root (thường là cách thực hiện việc này), thì việc cho phép người dùng khác sở hữu tệp (ngay cả khi root!).

Userify (từ chối trách nhiệm: đồng sáng lập) tự động thực hiện việc này chính xác theo cùng một cách .. https://github.com/userify/shim/blob/master/shim.py#L285

Tôi đã có cùng một vấn đề trên hai máy chủ: Linux chạy Debian và trên NAS (Synology DS715)

Hóa ra trong cả hai trường hợp, quyền của thư mục chính trên máy chủ đều sai

auth.log trên máy chủ rất hữu ích

Authentication refused: bad ownership or modes for directory /home/cyril

trên Linux, nó có bit write / group (drwxrwxr - x), vì vậy tôi phải xóa ít nhất là ghi trên nhóm (chmod gw ~ /) và sau đó nó hoạt động

trên Synology, vì bất kỳ lý do gì, đã có một chút dính

drwx--x--x+ 4 toto users 4096 Jan 6 12:11 /var/services/homes/toto

Tôi đã phải thay đổi nó với

chmod -t ~/

và sau đó tôi có thể kết nối mà không cần mật khẩu

Khi sử dụng CentOS 7 và tôi cũng tự tin áp dụng cho các hệ điều hành Linux khác bằng sshd. Với quyền truy cập root, bạn có thể xác định thêm về lý do tại sao xác thực có thể bị lỗi. Để làm điều này:

1. Cho phép đăng nhập cho sshd: vi /etc/ssh/sshd_config
2. Đang đăng nhập uncomment:

SyslogFacility AUTH LogLevel INFO

1. Thay đổi LogLevel INFO thành LogLevel DEBUG
2. Lưu và thoát
3. Khởi động lại sshd systemctl restart sshd
4. Xem tập tin tin nhắn tail -l /var/log/messages
5. Sử dụng một thiết bị đầu cuối khác, cố gắng kết nối với ssh
6. Cố gắng kết nối với ssh
7. Xem lại nhật ký xác thực để biết nguyên nhân chính xác

Ví dụ, tôi đã gặp một số vấn đề tương tự như đã đề cập ở trên.

Authentication refused: bad ownership or modes for file /home/user/.ssh/authorized_keys

Sử dụng các bước này tôi có thể xác nhận sự cố là quyền trên tệp ủy quyền. Bằng cách đặt chmod thành 644 trên tệp khóa được ủy quyền của người dùng của tôi, sự cố đã được khắc phục.

Có vẻ như các quyền trên .sshthư mục của bạn đã không sao chép + dán chính xác. Bạn có thể vui lòng thêm nó một lần nữa?

Nếu chế độ nghiêm ngặt được bật thì chúng tôi phải đảm bảo .sshcó quyền chính xác của:

• .ssh/ nên có uốn 0700/rwx------
• .ssh/*.pub tập tin nên 644/rw-r--r--
• .ssh/* (các tệp khác trong .ssh) 0600/rw-------

Làm thế nào để mọi thứ tìm kiếm sự cho phép của bạn?

Chỉ trong trường hợp ai đó vấp phải câu trả lời này - không có khuyến nghị nào hoạt động trong kịch bản của tôi. Cuối cùng, vấn đề là tôi đã tạo một tài khoản không có mật khẩu. Khi tôi đặt mật khẩu bằng cách sử dụng usermod -p "my password" usernamevà sau đó buộc mở khóa tài khoản, usermod -U usernamemọi thứ đều rất đẹp.

Tôi đã gặp một vấn đề tương tự , trong đó kết nối ssh thử phím ~/.ssh/id_rsatrước khi dừng đột ngột:

debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password

Trong trường hợp của tôi, đó là do một tệp khóa công khai cũ nằm xung quanh trong .sshthư mục:

[gitlab-runner@validation-k8s-1 ~]$ ll .ssh/id_rsa*
total 16
-rw------- 1 gitlab-runner gitlab-runner 1675 Sep 18 18:02 id_rsa      --> new private key
-rw-r--r--. 1 gitlab-runner gitlab-runner  423 Jun 12 13:51 id_rsa.pub --> old public key

Di chuyển / xóa id_rsa.pubtừ .sshthư mục đã giải quyết vấn đề.

Theo những gì tôi hiểu: khi có khóa công khai ở phía máy khách, SSH 1st xác nhận khóa riêng chống lại nó. Nếu thất bại, nó sẽ không thử sử dụng khóa riêng để kết nối từ xa.

Tôi đã gửi e-mail đến danh sách gửi thư của openssh: https://lists.mindrot.org/pipermail/openssh-unix-dev/2016-April/035048.html .

Chúng tôi đã gặp phải vấn đề này. Quyền và quyền sở hữu trên các tệp .ssh đều đúng. Trong / var / log / message chúng tôi tìm thấy:

Mar 29 15:45:36 centos70 setroubleshoot: SELinux is preventing /usr/sbin/sshd from read access on the file authorized_keys. For complete SELinux messages run: sealert -l 05963b94-f318-4615-806c-b6c3a9066c82

SO, giải pháp cho nhà phát triển vm mà chúng tôi không quan tâm về bảo mật là vô hiệu hóa selinux. Chỉnh sửa / etc / sysconfig / selinux và thay đổi SELINUX = bị vô hiệu hóa và khởi động lại.

Cũng gặp phải vấn đề này. setroubledhoot dường như không hoạt động trong môi trường của tôi nên không có bản ghi nhật ký như vậy trong / var / log / message. Vô hiệu hóa SELinux không phải là một lựa chọn cho tôi, vì vậy tôi đã làm

restorecon -Rv ~/.ssh

Sau đó đăng nhập bằng khóa rsa hoạt động tốt.

Chỉ trong trường hợp này cũng cứu ai đó. Tôi đã cố gắng sao chép một khóa từ Máy Ubuntu 18.04 của mình sang 2 Máy chủ CentOS 7. Tôi đã sử dụng ssh-copy-idđể chuyển chúng. Một làm việc, một không. Vì vậy, tôi đã trải qua tất cả các quyền gỡ lỗi và không tìm thấy gì. Vì vậy, cuối cùng tôi đã kéo tập tin /etc/ssh/sshd_configlên cả hai máy chủ và từng bước từng bước qua chúng. Cuối cùng tôi đã tìm thấy nó, có lẽ là thứ mà ai đó đã sửa đổi từ lâu trước khi tôi bắt tay vào công việc.

Một lần đọc: AuthorizedKeysFile .ssh/authorized_keys

Và một thông tin khác : AuthorizedKeysFile ~/.ssh/authorized_keys, trên máy chủ không chấp nhận khóa của tôi. Rõ ràng tìm kiếm giữa hai tệp và lưu ý nhận xét cho biết các mẫu tìm kiếm mặc định không bao gồm hàng đầu ~/tôi đã xóa nó và khởi động lại sshd. Vấn đề được giải quyết.

Nhật ký lỗi phía máy khách kết thúc như thế này:

Enter passphrase for key '/root/.ssh/id_rsa':
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey,password
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
root@x.x.x.x's password:

có thể được gây ra bởi một hạn chế phía máy chủ (từ xa) khi đăng nhập root khi tệp cấu hình sshd chứa:

PermitRootLogin: no

Đề xuất của JonCav để cho phép ghi nhật ký rất hữu ích trong việc gỡ lỗi một vấn đề như vậy. Trong khi spew gỡ lỗi phía máy khách là không có ích đáng kể, đặt phần sau vào tệp sshd_config của máy chủ sshd :

SyslogFacility AUTH
LogLevel DEBUG

đã kết thúc việc tạo ra các thông điệp tường trình hữu ích:

Jul 19 19:16:38 500265-web1 sshd[21188]: Found matching RSA key: ...
Jul 19 19:16:38 500265-web1 sshd[21188]: ROOT LOGIN REFUSED FROM ...
Jul 19 19:16:38 500265-web1 sshd[21188]: Failed publickey for root from ... port ... ssh2
Jul 19 19:16:38 500265-web1 sshd[21189]: ROOT LOGIN REFUSED FROM ...

Trong trường hợp chỉ đăng nhập root không thành công và cung cấp rằng chỉ sử dụng xác thực dựa trên khóa để đăng nhập root được chính sách bảo mật của bạn cho phép, một thay đổi đối với tệp sshd_config có thể giúp:

 PermitRootLogin without-password

Số dặm của bạn có thể thay đổi, mặc dù điều này thường giúp ích, một số cấu hình khác vẫn có thể can thiệp theo nhận xét được tìm thấy trong một số tệp sshd_config :

# Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".

Ngay cả khi bạn không thể dễ dàng thay đổi cấu hình máy chủ từ xa để gỡ lỗi theo cách này, người ta có thể chứng minh cấu hình phía máy khách ở một mức độ nào đó bằng cách sử dụng cùng một tệp nhận dạng để ssh vào tài khoản không root trên cùng một máy chủ từ xa.

Lý do trong trường hợp của tôi là một tùy chọn được thiết lập tùy chỉnh AuthorizedKeysFiletrong tệp /etc/ssh/sshd_config. Nó được đặt thành thư mục nhà của người dùng khác ( /home/webmaster/.ssh/authorized_keys), vì vậy người dùng mà tôi đang cố đăng nhập không có quyền truy cập vào tệp / thư mục đó.

Sau khi thay đổi nó và khởi động lại ssh-server ( service ssh restart), mọi thứ trở lại bình thường. Tôi có thể đăng nhập bằng khóa riêng của mình bây giờ.

Tôi có thể thấy tại sao an ninh có thể làm phiền mọi người. Tôi chỉ có ssh won't use my keyvấn đề một lần nữa. Tôi đã giải quyết nó bằng cách đăng nhập vào máy chủ từ xa và chạy

/usr/sbin/sshd -sDp 23456

và sau đó từ máy tính để bàn của tôi, (cố gắng ssh đến máy chủ)

ssh -vvvv server -p 23456

Trên máy chủ tôi có Authentication refused: bad ownership or modes for directory /

Một số sysadmin mới đã làm mất quyền và quyền sở hữu mà tôi đã sửa:

chmod 0755 / ; chown root:root /

(Tôi đang sử dụng để cần chmod 0600 ~/.ssh/* ; chmod 0644 ~/.ssh/*.pubnhưng kiểm tra sshd / tìm kiếm các điều khoản gốc là một cái mới đối với tôi.) Bây giờ tôi sẽ kiểm tra một rootkit và sau đó lau và cài đặt lại anyway.

Trong trường hợp của tôi, các vấn đề là với trình thực thi shell không chính xác.

journalctl -f
....
Feb 25 11:45:54 59a02b89e0f6 sshd[]: User user not allowed because shell /usr/bin/env /bin/bash does not exist
....

Thay đổi tập tin / etc / passwd cho người dùng đó

vi /etc/passwd 
....
user:x:1000:1000::/home/user:/bin/bash
....

Tôi gặp vấn đề này trên CentOS 7. Tôi là một người dùng Linux dựa trên Debian thông thường nên tôi là một con cá ra khỏi nước. Tôi nhận thấy rằng trong một số máy chủ, nó hoạt động và chỉ trong một máy chủ thì không. Kiểm toán.log cho biết không có gì hữu ích và Secure.log cũng không cung cấp bất cứ điều gì. Tôi thấy rằng sự khác biệt thực sự duy nhất là một số khác biệt về bối cảnh bảo mật trên các tệp và thư mục giữa những tệp không hoạt động và những thư mục không hoạt động. Nhận bảo mật với

sudo ls -laZ <user-home>/.ssh

của thư mục (Tôi giả sử rất nhiều mặc định trên sshd_config).

Bạn sẽ thấy một số ssh_home_tvà user_home_tthuộc tính. Nếu bạn không, hãy sử dụngchcon lệnh để thêm các thuộc tính bị thiếu.

Ví dụ

home="$(getent passwd <user> | cut -d: -f6)"
sudo chcon -R unconfined_u:object_r:ssh_home_t:s0 "$home".ssh
sudo chcon unconfined_u:object_r:user_home_t:s0 "$home"

Trong trường hợp của tôi, sự nghi ngờ của tôi là người dùng đã được tạo theo cách không chuẩn. Nhà anh là một thư mục trong/var/lib .

Thêm thông tin trong: https://www.linuxquestions.org/questions/linux-security-4/selinux-preventing-ssh-login-with-~-ssh- trái_keys-4175469538 /

Trong trường hợp của chúng tôi, các vấn đề liên quan đến thực tế là các quy tắc tường lửa và NATing của chúng tôi không được thiết lập chính xác.

cổng 22, đã được chuyển đến máy chủ không chính xác nơi khóa và người dùng của chúng tôi không được nhận dạng.

Nếu ai đó đạt đến điểm này. tcpdump và telnet có thể là bạn của bạn

[aaron@aaron-pc ~]$ telnet someserver 22
Trying 1.1.1.1...
Connected to someserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_6.7p1
^]
telnet> 

[aaron@aaron-pc ~]$ telnet someotherserver 22
Trying 1.1.1.2...
Connected to someotherserver.
Escape character is '^]'.
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
^]

Bạn sẽ nhận thấy rằng hai máy chủ này có các phiên bản openssh khác nhau. Điều này giúp tôi phát hiện ra vấn đề khá nhanh. Nếu máy chủ lưu trữ của bạn đang sử dụng các phiên bản ssh tương tự, bạn sẽ phải thử thực hiện theo dõi đóng gói trên đích để xem lưu lượng truy cập có thực sự đến đích không.

Ssh có thể tạo ra rất nhiều lưu lượng truy cập khiến cho tcpdump trở nên khó tìm thấy những gì bạn đang tìm kiếm.

Điều này đã giúp tôi

 tcpdump -i any  "not host [mylocalip] and not localhost and not ip and not arp"

Hãy thử telnet từ 3 máy chủ khác không phải máy tính hiện tại của bạn @ [mylocalip]. Bạn muốn xem lưu lượng truy cập thực sự đến máy chủ của bạn.