SSH không chấp nhận khóa công khai


4

Khi thiết lập các phím ssh giữa hai máy, xác thực chỉ hoạt động một chiều. Một máy chủ không chấp nhận khóa chung của máy chủ kia khi cố gắng kết nối. Có ý kiến ​​gì không? Đây là đầu ra dài dòng.

debug1: Reading configuration data /usr/local/etc/ssh_config

debug1: Rhosts Authentication disabled, originating port will not be trusted.

debug1: Connecting to xxxxxx.com [xx.xx.xx.xx] port 22.

debug1: Connection established.

debug1: identity file /root/.ssh/identity type -1

debug1: identity file /root/.ssh/id_rsa type 1

debug1: identity file /root/.ssh/id_dsa type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5

debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_3.6.1p2

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: server->client aes128-cbc hmac-md5 none

debug1: kex: client->server aes128-cbc hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST 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: Host 'xxxxxx.com' is known and matches the RSA host key.

debug1: Found key in /root/.ssh/known_hosts:17

debug1: ssh_rsa_verify: signature correct

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug1: SSH2_MSG_NEWKEYS received

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey,password

debug1: Next authentication method: publickey

debug1: Trying private key: /root/.ssh/identity

debug1: Offering public key: /root/.ssh/id_rsa

debug1: Authentications that can continue: publickey,password

debug1: Trying private key: /root/.ssh/id_dsa

debug1: Next authentication method: password

CHỈNH SỬA: Nếu nó quan trọng, đây là cho root


Tôi giả sử đăng nhập gốc được cho phép trong sshd_config của bạn?
heavyd

Đây có phải là một vấn đề cụ thể cho máy chủ này? Bạn đã thiết lập thành công ủy quyền khóa ssh trước đây chưa?
Doug Harris

Có những tài khoản khác xác thực theo cách này tốt, chỉ cần không root
Zurahn

Tôi đã kết thúc bằng một tài khoản khác đang hoạt động và sudoing. Ok, không thanh lịch, nhưng tôi đã dành đủ thời gian cho việc này.
Zurahn

Câu trả lời:


1

Kiểm tra các giá trị của các tùy chọn sau trên máy chủ ssh:

PubkeyAuthentication Yes
RSAAuthentication Yes
PermitRootLogin Yes

RSAAuthentication có PubkeyAuthentication yes
Zurahn

Kiểm tra xem PermitRootLogin không được đặt thành không, nếu nó được đặt thành không đặt thì thành nopwd
radius

1
Nó đã được đặt thành yes và tôi đã đổi nó thành without-password và khởi động lại ssh mà không có bất kỳ ảnh hưởng nào - nó vẫn yêu cầu mật khẩu. Đó, bạn của tôi, là quyết tâm.
Zurahn

@radius không có nopwd. Và đặt nó thành không có mật khẩu chỉ làm cho nó an toàn hơn một chút, theo đó họ vẫn cần một khóa. Và dù sao chìa khóa cũng đến đầu tiên. Nếu anh ta không thể lấy được chìa khóa, anh ta vẫn không thể vào được bằng chìa khóa. Tôi không biết, có thể anh ta đã không sao chép khóa công khai của mình hoặc có thể anh ta đã không đăng nhập đúng người dùng trên máy chủ ssh.
barlop

8

Tôi vừa gặp trường hợp SELinux ngăn sshd đọc tệp /root/.ssh/authorized_keys. / var / log / message sẽ cho bạn thấy rằng quá trình sshd đã bị từ chối truy cập cho hoạt động đọc trên tệp ủy quyền.

Sau khi tôi chạy restorecon -v /root/.ssh/authorized_keys, SSH với khóa công khai hoạt động tốt.


Nhật ký của tôi không cho thấy gì về việc từ chối truy cập nhưng dù sao tôi cũng chạy lệnh này. Và những gì bạn biết, nó đã làm việc. Cảm ơn!
Kaivosukeltaja

5

Thay đổi StrictModes thành "không" trong /etc/ssh/sshd_config đã làm cho tôi.

sysadmin@suselinux1:~> con sysadmin kaiser
Welcome to Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-25-generic i686)

 * Documentation:  https://help.ubuntu.com/

Last login: Fri Nov  9 15:40:11 2012 from 10.1.3.25
sysadmin@kaiser:~$ date
vie nov  9 17:53:11 CST 2012
sysadmin@kaiser:~$ 

Thay vì vô hiệu hóa StrictModes bạn có thể sửa các quyền của tệp trong .ssh (và .ssh thư mục chính nó) thay vào đó.
Flimm

1

Khóa của tôi không được chuyển tiếp, hóa ra tôi đã khởi động tác nhân SSH trong một cửa sổ đầu cuối khác, vì vậy, $SSH_AUTH_SOCK biến môi trường không có sẵn trong thiết bị đầu cuối mà tôi đang thực hiện kết nối.

Vì vậy, nếu bạn đang bắt đầu đại lý theo cách thủ công, hãy đảm bảo bạn thực hiện kết nối trong cùng một phiên cuối.


0

Kiểm tra quyền và chủ sở hữu của thư mục .ssh, tệp ủy quyền_key và thư mục chính, /var/log/auth.log sẽ cung cấp cho bạn nhiều tin nhắn hơn khi bạn cố gắng đăng nhập.


1
/var/log/auth.log trên máy chủ, không phải máy khách (trong trường hợp ai đó giả định sau).
Daniel Beck
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.