Hello, I ran through the usual step in creating keys for passwordless SSH login.
1. ssh-keygen -t rsa -b 1024
2. scp /root/.ssh/id_rsa.pub root@my_cloud_ip:/root/.ssh/authorized_keys
3. chmod -R 700 authorized keys
Problem is I have to provide password when logging in. I even checked the sshd_config file.
Nothing is working, I have to provide a password.
Any help on this would be appreciated.
Hello,
At this point, we are not able to provide you with a solution since SSH is not supported by WD. Perhaps one of the user on the community can assist you with that.
It looks like you are doing everything correct.
Here is my testing, pogo1=client, 192.168.0.44=mycloud
root@pogo1:~# ssh-keygen -t rsa -b 1024
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
root@pogo1:~# cd .ssh
root@pogo1:~/.ssh# ls
. … id_rsa id_rsa.pub known_hosts
root@pogo1:~/.ssh# scp id_rsa.pub 192.168.0.44:/root/.ssh/authorized_keys
root@192.168.0.44’s password:
id_rsa.pub 100% 224 0.2KB/s 00:00
root@pogo1:~/.ssh# ssh 192.168.0.44 <— ssh w/o password… WORKS
Linux WDMyCloud 3.2.26 #1 SMP Thu Aug 22 15:05:37 PDT 2013 armv7l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Jan 2 16:59:45 2014 from 192.168.0.40
WDMyCloud:~# id
uid=0(root) gid=0(root) groups=0(root),33(www-data),1000(share)
WDMyCloud:~# exit
logout
Connection to 192.168.0.44 closed.
root@pogo1:~/.ssh#
Thanks for your post. I have tried that and no success. I cannot login via SSH with keypair and no password.
I even checked my sshd_config file and can’t figure out the problem.
ChallengeResponseAuthentication no
PasswordAuthentication yes
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
UsePAM no
Any other suggestions?
PasswordAuthentication yes
should be:
PasswordAuthentication No
Do you have the following 2 lines in your config as well? If not, add them.
PubkeyAuthentication Yes
RSAAuthentication Yes
Permissions should be like this:
chmod 700 /root/.ssh
chmod 600 /root/.ssh/authorized_keys
Also, be sure to launch an additional ssh client to test the connection after making your changes. This way you won’t lock yourself out of your own box before getting a chance to fix something.
Awesome. Thank you. I will try this now and post results.
First, I probably should have stated I am running OSX 10.8.3
I have spent hours on this and nothing is working. Appears permission problem. I get a “Permission denied (publickey)” error. I have tried creating the public key with both root and with a normal user. Neither one works. Seems like the key passes and then it craps out.
sh-3.2# ssh -vvv root@10.0.1.13 -i mycloud
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.0.1.13 [10.0.1.13] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug3: Incorrect RSA1 identifier
debug3: Could not load “mycloud” as a RSA1 public key
debug1: identity file mycloud type 1
debug1: identity file mycloud-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.0p1 Debian-3
debug1: match: OpenSSH_6.0p1 Debian-3 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host “10.0.1.13” from file “/var/root/.ssh/known_hosts”
debug3: load_hostkeys: found key type RSA in file /var/root/.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: 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,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss
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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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
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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,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: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 130/256
debug2: bits set: 493/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 25:fa:fc:91:e3:7c:84:50:0d:0c:28:4e:18:bc:50:6f
debug3: load_hostkeys: loading entries for host “10.0.1.13” from file “/var/root/.ssh/known_hosts”
debug3: load_hostkeys: found key type RSA in file /var/root/.ssh/known_hosts:1
debug3: load_hostkeys: loaded 1 keys
debug1: Host ‘10.0.1.13’ is known and matches the RSA host key.
debug1: Found key in /var/root/.ssh/known_hosts:1
debug2: bits set: 533/1024
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: mycloud (0x7f847141d0f0)
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred 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: mycloud
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
I don’t understand SSH enough to pinpoint the problem. I am sure I am making a boneheaded mistake somewhere. Any help would be appreciated.
Oh, I didn’t realize you were on mac. The permissions I gave are for the nas itself. Make sure you can still read your own key file if you changed the permissions locally.
“Permission denied (publickey).” means that the account you are signing on with cannot read /root/.ssh/authorized_keys which is progress…
Try just connecting with “ssh root@10.0.1.13” instead of using the mycloud profile option.
My bad for not stating I was using OSX earlier. My apologies.
I am with you on the permissions. I set .ssh to 700 and authorized_keys to 600.
I created the private/public keys with root user and then tranferred them over. Still no go.
I tried to login with ssh root@10.0.1.13 and nothing.
Client (OSX)
-rw------- 1 root wheel 891 Jan 3 23:39 mycloud_1
-rw-r–r-- 1 root wheel 242 Jan 3 23:39 mycloud_1.pub
Server (myCloud)
-rw-r–r-- 1 root root 242 Jan 3 21:42 mycloud_1.pub
I did the chmod 700 and 600:
Server (ls -la)
drw------- 2 root root 4096 Jan 3 21:42 authorized_keys
Server (ls -la)
drwx------ 4 root root 4096 Dec 19 16:06 .ssh
I have literally spent hours and still no go. I know I am making a simple mistake somewhere, I just can’t figure it out.
Are you running the ssh command as root on your end? Try sudo -s
You can always start over if you still have a connection open to your NAS through ssh.
Not familiar with mac, but should be something like this:
ssh-keygen -t rsa
And then hit enter a bunch of times, unless you want a password on the key. Note the location the file is stored at. It may be something like “Your identification has been saved in /User/bob/.ssh/id_rsa.pub”
scp /your/key/location/.ssh/id_rsa.pub root@10.0.1.13:/root/.ssh/authorized_keys
Then try to ssh root@10.0.1.13
You’re basically there, you just need to make sure your local key file is being grabbed when you connect. It doesn’t matter if the local key is made by root or a regular user.
If you are running the command in your terminal it as a local user, like “bob”, it’s looking for a key in your home directory, and not /root/.ssh/id_rsa.pub, which is what you originally copied to the nas.
Hopefully that makes sense, it’s late…
That makes sense. I actually ran SSH as root and normal user.
sudo ssh root@10.0.1.13
and I also copied the mycloud_1 key into both /Users/Aaron/.ssh and /var/root/.ssh to cover both normal and root users.
Also, I deleted both keys from the client and server several times and recreated using the key-gen command. I maybe did this 5 or 6 times. Still it didn’t work.
This is pretty frustratiing. I have a linux router that I SSH into using keys all the time with no troubles.
What’s the output of “ls ~/.ssh”? If it lists “mycloud” keys, try “mv ~/.ssh/mycloud_1.pub ~/.ssh/id_rsa.pub”
Then “scp ~/.ssh/id_rsa.pub root@10.0.1.13:/root/.ssh/authorized_keys”
Check ~/.ssh/config to see if you are using an old key (if it’s not listed, that’s fine)
Then again try to “ssh root@10.0.1.13”
Good idea! Didn’t think to try that.
I will do that and post results. Thanks again for your continued help 
EDIT: **bleep**. I usually keep an extra shell to the mycloud open but forgot to change the ssh_config file and my connection was terminiated. Now I am locked out. Any suggestions on how to get back in?
Ok, I started from scratch. I deleted all old keys on both systems and used default settings to generate new keys.
On client
ARogs-MacBook-Pro:.ssh Aaron$ whoami
Aaron
ARogs-MacBook-Pro:.ssh Aaron$ pwd
/Users/Aaron/.ssh
ARogs-MacBook-Pro:.ssh Aaron$ ls -la
total 40
drwx------ 7 Aaron staff 238 Jan 4 17:14 .
drwxr-xr-x+ 20 Aaron staff 680 Jan 3 23:12 …
-rw------- 1 Aaron staff 887 Jan 4 17:14 id_rsa
-rw-r–r-- 1 Aaron staff 243 Jan 4 17:14 id_rsa.pub
On myCloud
WDMyCloud:~# mkdir ~/.sshWDMyCloud:~# chmod 700 ~/.ssh
WDMyCloud:~# ls -la
total 24
drwx------ 3 root root 4096 Jan 4 15:44 .
drwxr-xr-x 26 root root 4096 Jan 4 15:47 …
-rw------- 1 root root 500 Jan 4 15:58 .bash_history
-rwxr-xr-x 1 root root 463 Oct 28 14:24 .bashrc
-rw-r–r-- 1 root root 140 Nov 19 2007 .profile
drwx------ 3 root root 4096 Jan 4 15:47 .ssh
WDMyCloud:~# cd .ssh/WDMyCloud:~/.ssh# mkdir authorized_keys
WDMyCloud:~/.ssh# chmod 600 authorized_keys
WDMyCloud:~/.ssh/authorized_keys# pwd
/root/.ssh/authorized_keys
WDMyCloud:~/.ssh/authorized_keys# ls -la
total 12
drw------- 2 root root 4096 Jan 4 15:48 .
drwx------ 3 root root 4096 Jan 4 15:47 …
-rw-r–r-- 1 root root 243 Jan 4 15:48 id_rsa.pub
vi /etc/ssh/sshd_config
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile /root/.ssh/authorized_keys
PasswordAuthentication no
On Client
scp id_rsa.pub root@10.0.1.16:/root/.ssh/authorized_keys
ARogs-MacBook-Pro:.ssh Aaron$ ssh root@10.0.1.16
Permission denied (publickey,password).
I’m about to take a hammer to this piece of #$@!
Solved it.
The problem is that I was thinking the authorized_keys was a directory and I put the public key there.
That is not correct. authorized_keys is a file and you have to “cat >>” the contents of id_rsa.public into the authorized_keys file.
Ah, yes. Glad you figured it out.
Do note that if you ever try to ssh in with a username besides root, it will get the same permissions error because it can’t read that file since it’s owned by root. You’ll need to create an authorized_keys file for each user in /etc/ssh/username/authorized_keys but that’s probably something you’ll probably never care about for this NAS.
| Forums | News and Announcements | Register | Help | Forum Guidelines |
Copyright © 2021 Western Digital Technologies, Inc. All rights
reserved.
|
Trademarks
|
Privacy
|
Community Terms of Service
|
Site Terms of Use
|
Copyright
|
Contact WD
|