Synology DSM 5で他の（非ルート）ユーザーとしてパスワードなし（パスワードなし）でSSH

24

パスワード（公開キー認証）なしで、非ルートとしてSynology Disk Stationにsshしようとしています。

パスワードなしでrootとしてsshしようとすると、動作します。別のユーザーに対してまったく同じ手順を実行しても機能しません。常にパスワードを要求します（また、パスワードを使用しても機能します）。

私はこれについてすべてのガイドに従いましたが、それらはすべて新しい5.0バージョンではなくDSM 4.xのためのものだと思います。

SSHデバッグログ

これは、-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:

任意の助けに感謝します。

今まで試したこと

/ etc / ssh / sshd_config（RSAAuthentication、PubkeyAuthentication、AuthorizedKeysFile）を確認します。
.ssh / *パーマと所有権を確認してください。いくつかの組み合わせを試しました。
〜/ .profileのHOME変数を確認してください。
synoservicectl --restart sshdおよびNAS全体を再起動することにより、sshdを再起動しました。

— Vlad A Ionescu
ソース

なぜこれをしたいのですか？保護されていないキーを使用した公開キー認証では十分ではありませんか？

— ダニエルB 14年

こんにちはダニエル、それはまさに私が達成しようとしていることですが、非ルートユーザーには機能しません。

— Vlad A Ionescu 14年

クライアントの公開鍵はユーザーの authorized_keysファイルにありますか？

— ダニエルB 14年

うん、私はそれをssh-copy-idでコピーしました。そして、それはrootユーザーからのまったく同じauthorized_keysファイル（ただし適切なパーマ付き）であり、rootで動作します。

— ヴラドAイオネスク

アカウントにパスワードはありますか？お使いのシステムのセキュリティポリシーに応じて、パスワードを持たないユーザがログインを禁止することができる。

— ダニエルB

49

同じ問題がありました。「/ usr / syno / sbin / sshd -d」を使用してDiskStationでsshdのインスタンスをデバッグモードで実行し、「ssh user @ DiskSation -vvv」を使用して接続し、サーバーでデバッグ情報を取得しました。

......

debug1：temporary_use_uid：1026/100（e = 0/0）

debug1：公開鍵ファイル/var/services/homes/user/.ssh/authorized_keysを試行しています

debug1：fd 5がO_NONBLOCKをクリアする

認証が拒否されました：ディレクトリ/ volume1 / homes / userの所有権またはモードが正しくありません

......

ホームフォルダーにも適切なアクセス許可が必要であることに気付きました。

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

「user」などの実際のユーザー名に置き換えます。

最後に、問題は解決されました！

— user334026
ソース

2

ちょうどあなたのためとして、実行しているchmod 755私のホームディレクトリがDSM 6で私のためにこれを解決するには

— デイヴィッドPärsson

デバッグログを取得するのは常に適切なソリューションです。ありがとう！ただ1つの追加：呼び出し/usr/bin/sshd -p 2222（および接続ssh -p 2222）してデバッグ用に別のポートで実行します-そうしないと、sshデーモンを終了するとアクセスが失われるリスクがあります

— アレックス

16

ホームディレクトリを755にchmodする必要があります（synologyはデフォルトで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

— スプリアスデータ
ソース

これは、chmod 755 /home/admin実際にアクセス許可を変更したことを示していません。

— user20342 14

ええ、それは本当です。しかし、私は貼り付けられた例をまとめただけで、それを見逃しました。答えを編集します。

— spuriousdata 14

5

.sshおよびauthorized_keysのアクセス許可が正しく設定されているため、ホームディレクトリ（/home/aether/）のアクセス許可が正しく設定されていることを確認してください（chmod 755 /home/aether/）。

デフォルトの許可（711）でログインできませんでした。許可を変更すると機能しました。

乾杯ステファン

— ステファン
ソース

2

私は同じ問題を抱えていました。上記のすべてをダブルとトリプルでチェックしても、まだ動作しませんでした。最後に、/ home / nonrootuserディレクトリがないため、sshデーモンが誤った場所でauthorized_keysファイルを探していることに気付きました。

パスを作成するか、シンボリックリンクを作成する必要があります（これらの2つのオプションは機能しませんでした）。

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

この方法では、クライアントからssh-copy-idを介して追加するキーが、サーバー（synology）が非rootuserの接続を確立するために提供しているものと同じであることを確認します。

— user334008
ソース

2

dsm 6.0での同じ問題は、Synologyフォーラムのこのスレッドのおかげで解決しました

ユーザーのホームパーミッションが寛容すぎる¿？¿??¿¿？

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

...そして今、それは動作します！

— ゴンサロ・カオ
ソース

1

それはその質問に非常に似ています：

/programming/12839106/scp-between-2-remote-hosts-without-password/12945060#12945060

.sshディレクトリまたはファイルに適切な属性がないと思われます。

ここに私のものがあります：

-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

また、その内容を確認して/etc/pam.d/sshd、非ルートにいくつかの制限を課す可能性があります。念のため。このリンクは、RHELの場合のPAMについて説明しています。役立つ場合があります：https : //access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/PAM_Configuration_Files.html

ここでは、問題のheadい頭を示しています：

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

id_rsaを受け入れず、続行します。

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

それはあきらめ、パスワードに依存しています

debug1: Next authentication method: password

だから今、質問はそれがid_rsaを好きではない理由ですか？

— グジェゴルツ
ソース

こんにちはグジェゴシ、の.sshディレクトリには、パーマ700を持っているとの.ssh / authorized_keysには、パーマ600がある

— ヴラドAイオネスク

@VladAlexandruIonescu：他の属性を示す応答を更新しました。PAMに関する情報は、テストする領域を増やす可能性があります。

— グジェゴルツ14年

おかげで、Grzegorz、まだ運がない。私はあなたと全く同じパーマを試しました。また/etc/pam.d/sshd周りを見ていたが、rootユーザーを識別することは何も似ていない：gist.github.com/vlad-alexandru-ionescu/e6a2ee6133c7e9e45273を。

— ヴラドAイオネスク

@VladAlexandruIonescu：すべてのユーザーにこの問題はありますか？「別のユーザー用」と書いたのは、1人だけを示している可能性があります。このユーザーログインを使用してパテをしたり、rootとしてログインしてsuすることはできますか？

— グジェゴルツ14

はい、すべての非ルートユーザーに対して。任意のユーザー（ルートまたは非ルート）としてssh / puttyできます。ただし、サーバーのauthorized_keysにクライアントの公開キーを追加した場合でも、非ルートの場合はパスワードを要求します。

— ヴラドAイオネスク

1

同じ問題がありました。authorized_keys、file home、および.sshディレクトリに適切なアクセス許可を設定した後、DiskstationにSSHで接続できませんでした。

techanic.netで情報を読んだ後、ファイルにログインシェルも設定する必要があることを発見しました/etc/passwd。/sbin/nologinデフォルトで設定されていました。に変更した後/bin/sh、DiskstationにSSHで正常に接続できました。

— ロブ・スムラコウスキ
ソース

0

5.0ではなくDSM 5.1でも同じ問題が発生しました。リストされているソリューションはどれも問題を解決しませんでした。私の場合、の許可/var/services/homes/<user>/.ssh/authorized_keysは正しくありませんでした。以下を実行して問題を解決しました

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

— スティーブンC.ハウエル
ソース