Synology DSM 5'te diğer (root olmayan) kullanıcılarda parola olmadan (şifresiz) SSH

24

Synology disk istasyonuma parola olmadan (genel anahtar doğrulama), ancak root olmayan bir şekilde ssh yapmaya çalışıyorum.

Parola olmadan root olarak ssh yapmaya çalıştığımda, çalışıyor. Başka bir kullanıcı için aynı adımları takip etmek işe yaramaz. Her zaman şifre ister (ayrıca bir şifre kullanmak da işe yarar).

Bunun için her kılavuzu takip ettim, ancak hepsinin yeni 5.0 sürümü yerine DSM 4.x için olduklarını düşünüyorum.

SSH hata ayıklama günlüğü

-Vvv bayrağıyla denediğimde hata ayıklama günlüğü:

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:

Herhangi bir yardım takdir etti.

Şimdiye kadar denediğim şeyler

/ Etc / ssh / sshd_config (RSA Doğrulama, PubkeyAuthentication, Yetkili AnahtarlarDosyası) kontrol edin.
.Ssh / * izinlerini ve sahipliğini kontrol et. Birkaç kombinasyon denedim.
HOME var ~ / .profile içinde kontrol edin.
Synoservicectl ile yeniden başlatılan sshd - sshd'yi yeniden başlatın ve tüm NAS'ı yeniden başlatarak.

— Vlad A Ionescu
kaynak

Bunu neden yapmak istiyorsun? Korunmasız bir anahtarla ortak anahtar kimlik doğrulaması yeterli olmaz mı?

— Daniel B,

Merhaba Daniel, tam olarak başarmaya çalıştığım şey bu, ancak root olmayan kullanıcılar için işe yaramıyor.

— Vlad A Ionescu

Müşterinizin ortak anahtarı , kullanıcının authorized_keys dosyasında mevcut mu?

— Daniel B

Evet, ssh-copy-id ile kopyaladım. Ve bu, root olduğunda çalışan root kullanıcısının tam olarak aynı yetkili_keys dosyasıdır (fakat doğru izinlerle).

— Vlad A Ionescu

Hesabınızın şimdi bir şifresi var mı? Sisteminizin güvenlik politikalarına bağlı olarak, şifresi olmayan kullanıcıların oturum açması engellenebilir.

— Daniel B

49

Ben de aynı problemi yaşadım. DiskStation'da "/ usr / syno / sbin / sshd -d" komutunu kullanarak hata ayıklama modunda sshd örneğini çalıştırdım, ardından "ssh user @ DiskSation -vvv" kullanarak bağlandım ve sunucuda hata ayıklama bilgisini aldım:

......

hata ayıklama1: geçici olarak_use_uid: 1026/100 (e = 0/0)

debug1: ortak anahtar dosyasını denemek /var/services/homes/user/.ssh/authorized_keys

debug1: fd 5, O_NONBLOCK’u temizliyor

Kimlik doğrulama reddedildi: dizin / hacim1 / evler / kullanıcı için hatalı sahiplik veya modlar

......

Giriş klasörünün de doğru izinlere ihtiyacı olduğunu farkettim:

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

Ve "user" gibi gerçek kullanıcı adı ile değiştirin.

Sonunda sorun çözüldü!

— user334026
kaynak

2

Tıpkı sizin gibi, chmod 755ev

— dizinimde çalışanlar bunu

Hata ayıklama günlüklerini almak her zaman doğru çözümdür. Teşekkürler! Sadece bir ekleme: Arayın /usr/bin/sshd -p 2222(ve bağlanın ssh -p 2222) böylece hata ayıklama için farklı bir bağlantı noktasında çalışır - aksi takdirde ssh deamon'dan ayrılırsanız erişimi kaybetme riskiniz var

— Alex

16

ana dizininizi 755'e chmod etmeniz gerekir (synology varsayılan olarak 777’dedir)

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
kaynak

Bu chmod 755 /home/adminaslında izinleri değiştirdiğini göstermez .

— user20342

Evet doğru. Yine de, yapıştırılan örneği bir araya topladım ve bunu özledim. Cevabı düzenleyeceğim.

— spuriousdata,

5

.sshYetkili ve anahtar_ izinleriniz doğru ayarlandığından, giriş dizininizin ( /home/aether/) doğru ayarlandığından emin olun ( chmod 755 /home/aether/).

Varsayılan izinlerle ( 711) giriş yapamadım ve izinleri değiştirdikten sonra çalıştı.

Şerefe Stephan

— Stephan
kaynak

2

Aynı problem vardı, yukarıdakilerin hepsini kontrol ediyorum ve üçlü yaptım ve hala işe yaramadı. Sonunda, ssh daemon'un, / home / nonrootuser dizini olmadığından yanlış yerde yetkili_keys dosyasını aradığını fark ettim.

Yolu oluşturmalı ya da bir bağlantı kurmalısınız (bu iki seçenek benim için işe yaramadı) ya da nihayet işe yarayan şey bu iki satırı sshd_config dosyasına eklemekdi:

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

Bu şekilde, istemciden ssh-copy-id ile eklediğiniz anahtarın, sunucunun (synology) yönlendirici olmayan kullanıcı için bağlantıyı kesmeyi teklif ettiği ile aynı olduğundan emin olun.

— user334008
kaynak

2

Buradaki dsm 6.0 ile aynı problem , Synology forumlarındaki bu konu sayesinde çözüldü

Kullanıcı ev izni çok fazla izin veriyor gibi görünüyor iss? ¿?? ¿¿?

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

... ve şimdi çalışıyor!

— Gonzalo Cao
kaynak

1

Bu soruya çok benziyor:

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

.Ssh dizininizin veya dosyalarınızın uygun özniteliklere sahip olmadığından şüpheleniyorum.

İşte benim:

-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

Ayrıca, içeriğinin /etc/pam.d/sshdkök dışı bazı kısıtlamalar getirebileceğini kontrol edin . Her ihtimale karşı. Bu bağlantı RHEL durumunda PAM'yi açıklar. Yardımcı olabilir: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Smart_Cards/PAM_Configuration_Files.html

İşte sorunun çirkin başını gösterdiği yer:

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

İd_rsa'yı kabul etmiyor ve devam ediyor:

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

Bu vazgeçer ve şifreye güvenir

debug1: Next authentication method: password

Öyleyse şimdi, soru id_rsa'yı neden sevmediği?

— Grzegorz
kaynak

Merhaba Grzegorz, .ssh dir 700 perma ve .ssh / onaylı_keys 600 izin verdi.

— Vlad A Ionescu

@VladAlexandruIonescu: Diğer özellikleri ve PAM ile ilgili bilgileri test etmek için daha fazla alan verebilecek olan yanıtımı gösteren yanıtımı güncelledim.

— Grzegorz

Teşekkürler Grzegorz, ama yine de şans yok. Seninle aynı izinleri denedim. Ayrıca /etc/pam.d/sshd dosyasına bir göz attı , ancak hiçbir şeyin kök kullanıcıyı ayırt edeceği gibi görünmüyor: gist.github.com/vlad-alexandru-ionescu/e6a2ee6133c7e9e45273 .

— Vlad A Ionescu

@VladAlexandruIonescu: Bu sorun tüm kullanıcılar için mi? Yalnızca bir tane gösterebilecek "başka bir kullanıcı için" yazdınız. Bu kullanıcı girişini kullanarak macun ya da root olarak giriş yaptınız ve sonra sulayabiliyor musunuz?

— Grzegorz

Evet, root dışı tüm kullanıcılar için. Herhangi bir kullanıcı olarak ssh / putty yapabilirim (root ya da root olmayan). Ancak istemcimin ortak anahtarını sunucudaki yetkili_ anahtarlara eklesem de, root olmadığı zaman şifre ister.

— Vlad A Ionescu

1

Ben de aynı problem vardı. Onaylanmış anahtarlarımda doğru izinleri ayarladıktan sonra, dosya evim ve .ssh dizinlerim hala Diskstation'ımda SSH yapamadı.

En bilgileri okuduktan sonra techanic.net ben de benim ayarlamak zorunda olduğunu keşfetti kabuğunun benim de /etc/passwddosyaya. /sbin/nologinVarsayılan olarak ayarlandı . Bunu değiştirdikten sonra /bin/shbaşarıyla Diskstation'ımda SSH yapabildim.

— Rob Szumlakowski
kaynak

0

Aynı sorunu 5.0 yerine DSM 5.1 ile yaşadım. Listelenen çözümlerin hiçbiri sorunu çözmedi. Benim durumumda, izinler /var/services/homes/<user>/.ssh/authorized_keysdoğru değildi. Aşağıdakileri çalıştırmak sorunu çözdü

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

— Steven C. Howell
kaynak