SSH không có mật khẩu (không mật khẩu) trên Synology DSM 5 như những người dùng khác (không phải root)

22

Tôi đang cố gắng ssh vào trạm đĩa Synology của mình mà không có mật khẩu (xác thực khóa chung), nhưng là không root.

Khi tôi cố gắng ssh là root mà không có mật khẩu, nó hoạt động. Thực hiện theo các bước chính xác tương tự cho người dùng khác không hoạt động. Nó luôn yêu cầu mật khẩu (đồng thời, sử dụng mật khẩu cũng hoạt động).

Tôi đã làm theo mọi hướng dẫn ngoài kia cho việc này, nhưng tôi nghĩ tất cả chúng đều dành cho DSM 4.x chứ không phải cho phiên bản 5.0 mới.

Nhật ký gỡ lỗi SSH

Đây là nhật ký gỡ lỗi khi tôi thử với cờ -vvv:

aether@aether-desktop:~$ ssh -vvv aether@aether-ds.local
OpenSSH_6.2p2 Ubuntu-6ubuntu0.2, OpenSSL 1.0.1e 11 Feb 2013
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 aether-ds.local [192.168.2.149] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/aether/.ssh/id_rsa" as a RSA1 public key
debug1: identity file /home/aether/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/aether/.ssh/id_rsa-cert type -1
debug1: identity file /home/aether/.ssh/id_dsa type -1
debug1: identity file /home/aether/.ssh/id_dsa-cert type -1
debug1: identity file /home/aether/.ssh/id_ecdsa type -1
debug1: identity file /home/aether/.ssh/id_ecdsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2p2 Ubuntu-6ubuntu0.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v11
debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH_5*
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host "aether-ds.local" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: 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: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,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,arcfour256,arcfour128,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: 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: kex_parse_kexinit: 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: 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: 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: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,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,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
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: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA f1:57:47:37:47:d4:5c:cd:a7:a4:5a:9c:a3:e8:1d:13
debug3: load_hostkeys: loading entries for host "aether-ds.local" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug3: load_hostkeys: loading entries for host "192.168.2.149" from file "/home/aether/.ssh/known_hosts"
debug3: load_hostkeys: found key type RSA in file /home/aether/.ssh/known_hosts:2
debug3: load_hostkeys: loaded 1 keys
debug1: Host 'aether-ds.local' is known and matches the RSA host key.
debug1: Found key in /home/aether/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
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: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/aether/.ssh/id_rsa (0x7f4ee2f47200),
debug2: key: /home/aether/.ssh/id_dsa ((nil)),
debug2: key: /home/aether/.ssh/id_ecdsa ((nil)),
debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
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/aether/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/aether/.ssh/id_dsa
debug3: no such identity: /home/aether/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/aether/.ssh/id_ecdsa
debug3: no such identity: /home/aether/.ssh/id_ecdsa: No such file or directory
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
aether@aether-ds.local's password:

Bất kỳ trợ giúp đánh giá cao.

Những điều tôi đã thử cho đến nay

Kiểm tra / etc / ssh / sshd_config (RSAAuthentication, PubkeyAuthentication, AuthorizedKeysFile).
Kiểm tra .ssh / * perms và quyền sở hữu. Đã thử một số kết hợp.
Kiểm tra HOME var trong ~ / .profile.
Khởi động lại sshd thông qua synoservicectl - bắt đầu sshd và bằng cách khởi động lại toàn bộ NAS.

— Vlad A Ionescu
nguồn

tại sao bạn muốn làm việc này? Sẽ không xác thực khóa công khai với một khóa không được bảo vệ?

— Daniel B

Xin chào Daniel, đó chính xác là những gì tôi đang cố gắng đạt được, nhưng nó không hoạt động đối với người dùng không phải root.

— Vlad A Ionescu

Là khóa công khai của khách hàng của bạn trong người dùng authorized_keys tập tin?

— Daniel B

Yup, tôi đã sao chép nó với ssh-copy-id. Và đó chính là tệp ủy quyền chính xác (nhưng có quyền) từ người dùng root, hoạt động khi root.

— Vlad A Ionescu

Tài khoản của bạn có mật khẩu bây giờ không? Tùy thuộc vào chính sách bảo mật của hệ thống của bạn, người dùng không có mật khẩu có thể bị cấm đăng nhập.

— Daniel B

46

Tôi đã từng gặp vấn đề tương tự. Tôi chạy một phiên bản của sshd trong chế độ gỡ lỗi trên DiskStation bằng cách sử dụng "/ usr / syno / sbin / sshd -d", sau đó tôi kết nối với nó bằng "ssh user @ DiskSation -vvv" và tôi đã nhận được thông tin gỡ lỗi trên máy chủ:

......

debug1: tạm_use_uid: 1026/100 (e = 0/0)

debug1: thử tệp khóa công khai /var/service/homes/user/.ssh/authorized_keys

gỡ lỗi1: fd 5 xóa O_NONBLOCK

Xác thực bị từ chối: quyền sở hữu hoặc chế độ xấu cho thư mục / volume1 / homes / user

......

Tôi nhận ra rằng thư mục nhà cũng cần có quyền:

cd /var/services/homes/
chown <username> <username>
chmod 755 <username>

Và thay thế bằng tên người dùng thực tế, như "người dùng".

Cuối cùng, vấn đề được giải quyết!

— user334026
nguồn

2

Cũng như cho bạn, chạy chmod 755 trên thư mục nhà của tôi đã giải quyết điều này cho tôi trên DSM 6.

— David Pärsson

Đó luôn là giải pháp phù hợp để lấy nhật ký gỡ lỗi. Cảm ơn! Chỉ cần một bổ sung: Gọi /usr/bin/sshd -p 2222 (và kết nối với ssh -p 2222 ) vì vậy nó chạy trên một cổng khác để gỡ lỗi - nếu không, bạn có nguy cơ mất quyền truy cập nếu bạn thoát khỏi ssh deamon

— Alex

15

bạn cần phải chỉnh lại thư mục chính của mình thành 755 (mặc định synology có ở 777)

nas> ls -al
total 28
drwxrwxrwx  6 root     root  4096 2014-07-13 03:00 .
drwxr-xr-x 13 root     root  4096 2014-07-13 03:00 ..
drwxrwxrwx  3 admin    users 4096 2014-07-13 03:00 admin
...
nas> chmod 755 /home/admin
nas> ls -al
total 28
drwxrwxrwx  6 root     root  4096 2014-07-13 03:00 .
drwxr-xr-x 13 root     root  4096 2014-07-13 03:00 ..
drwxr-xr-x  3 admin    users 4096 2014-07-13 03:00 admin

— spuriousdata
nguồn

Điều này không cho thấy rằng chmod 755 /home/admin thực sự đã thay đổi các quyền.

— user20342

Vâng, đó là sự thật. Mặc dù vậy, tôi chỉ ghép lại ví dụ đã dán và tôi đã bỏ lỡ điều đó. Tôi sẽ chỉnh sửa câu trả lời.

— spuriousdata

5

Là quyền của bạn cho .ssh và ủy quyền được đặt chính xác, chỉ cần xác minh rằng các quyền đối với thư mục chính của bạn ( /home/aether/ ) được đặt chính xác ( chmod 755 /home/aether/ ).

Tôi không thể đăng nhập với quyền mặc định ( 711 ) và nó hoạt động sau khi thay đổi quyền.

Chúc mừng Stephan

— Stephan
nguồn

2

Tôi có cùng một vấn đề, kiểm tra gấp đôi và gấp ba tất cả những điều trên và vẫn không làm việc. Cuối cùng, tôi nhận ra rằng ssh daemon đang tìm tệp ủy quyền ở sai vị trí, vì không có thư mục / home / nonrootuser.

Bạn nên tạo đường dẫn hoặc tạo một liên kết tượng trưng (hai tùy chọn đó đã không hoạt động cho tôi) hoặc điều cuối cùng đã làm là thêm hai dòng đó vào tệp sshd_config:

Match User nonrootuser
AuthorizedKeysFile      /var/services/homes/nonrootuser/.ssh/authorized_keys

Bằng cách này, bạn đảm bảo rằng khóa bạn đang thêm thông qua ssh-copy-id từ máy khách giống với máy chủ (synology) đang cung cấp để thiết lập kết nối cho người dùng không root.

— user334008
nguồn

2

Vấn đề tương tự ở đây với dsm 6.0, đã được giải quyết nhờ chủ đề này trên diễn đàn Synology

Có vẻ như sự cho phép của người dùng quá nhiều cho phép? ???

chmod 755 /var/services/homes/[username]

... Và bây giờ nó hoạt động!

— Gonzalo Cao
nguồn

1

Nó trông rất giống với câu hỏi đó:

https

Tôi nghi ngờ rằng thư mục hoặc tệp .ssh của bạn không có thuộc tính phù hợp.

Đây là của tôi:

-rw-r--r--  1 root root   393 Aug 13  2012 if_rsa.pub
-rw-------  1 root root  1675 Aug 13  2012 if_rsa
-rw-r--r--  1 root root   393 Aug 20  2012 id_rsa.pub
-rw-------  1 root root  1675 Aug 20  2012 id_rsa
-rw-------  1 root root  4606 Aug  7  2013 authorized_keys
drwx------  2 root root  4096 Feb 24 09:59 .
-rw-r--r--  1 root root 11354 Mar 25 17:28 known_hosts

Ngoài ra, vui lòng kiểm tra nội dung của /etc/pam.d/sshd mà có thể đặt một số hạn chế trên không root. Chỉ trong trường hợp. Liên kết này giải thích PAM trong trường hợp của RHEL. Nó có thể giúp: https://access.redhat.com/site/documentation/en-US/Red_Hat_ Entryprise_Linux / 6

Đây là nơi mà vấn đề cho thấy cái đầu xấu xí của nó:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/aether/.ssh/id_rsa
debug1: Authentications that can continue: publickey,password

Nó không chấp nhận id_rsa và tiếp tục:

debug1: Trying private key: /home/aether/.ssh/id_dsa
debug1: Trying private key: /home/aether/.ssh/id_ecdsa

Nó từ bỏ, và dựa vào mật khẩu

debug1: Next authentication method: password

Vì vậy, bây giờ, câu hỏi là tại sao nó không thích id_rsa?

— Grzegorz
nguồn

Xin chào Grzegorz, thư mục .ssh có perm 700 và .ssh / ủy quyền có khóa 600.

— Vlad A Ionescu

@VladAlexandruIonescu: Tôi đã cập nhật phản hồi của mình hiển thị các thuộc tính khác và thông tin liên quan đến PAM có thể cung cấp cho bạn thêm khu vực để kiểm tra.

— Grzegorz

Cảm ơn, Grzegorz, nhưng vẫn không gặp may. Tôi đã thử các perm chính xác như của bạn. Cũng có một cái nhìn xung quanh /etc/pam.d/sshd, nhưng không giống như bất cứ điều gì sẽ phân biệt người dùng root: gist.github.com/vlad-alexandru-ionescu/e6a2ee6133c7e9e45273 .

— Vlad A Ionescu

@VladAlexandruIonescu: Đây có phải là vấn đề cho tất cả người dùng? Bạn đã viết "cho người dùng khác" chỉ có thể chỉ một. Bạn có thể putty sử dụng đăng nhập người dùng này hoặc bạn đang đăng nhập với quyền root và sau đó su nó?

— Grzegorz

Có, cho tất cả người dùng không root. Tôi có thể ssh / putty như bất kỳ người dùng nào (root hoặc không root). Nhưng nó yêu cầu mật khẩu khi không root, mặc dù tôi đã thêm khóa công khai của khách hàng của mình vào ủy quyền trên máy chủ.

— Vlad A Ionescu

1

Tôi có vấn đề này như nhau. Sau khi thiết lập quyền chính xác trên ủy quyền của tôi, hãy gửi thư mục về nhà và .ssh tôi vẫn không thể SSH vào Diskstation của mình.

Sau khi đọc thông tin tại t cơic.net Tôi phát hiện ra rằng tôi cũng phải thiết lập đăng nhập vỏ trong tôi /etc/passwd tập tin. Nó đã được đặt thành /sbin/nologin theo mặc định Sau khi đổi nó thành /bin/sh Tôi đã có thể SSH vào Diskstation của mình thành công.

— Rob Szumlakowski
nguồn

0

Tôi chỉ gặp vấn đề tương tự với DSM 5.1 thay vì 5.0. Không có giải pháp nào được liệt kê giải quyết vấn đề. Trong trường hợp của tôi, các quyền cho /var/services/homes/<user>/.ssh/authorized_keys đã không đúng Chạy sau đây đã giải quyết vấn đề

chmod 600 /var/servieces/homes/<user>/.ssh/authorized_keys

— Steven C. Howell
nguồn