通过命令行获取NAS 320L权限

  张一帆   2017年03月24日


  5年前买的DLINK的NAS一直在被我用来当做NFS用。当时买回来这货就是看中了可以和远程迅雷绑定,可以是实现在任何地只要知道下载链接就可以通过远程迅雷将下载任务直接拖拽到家中的NAS中,这样我在上班的同时,就可以利用家里的网络下载一些自己喜欢的电影,等到家了以后就可以直接用平板通过SMB协议访问到NAS上,这样就可以直接看电影了。其实这东西还挺好用,给我这几年的生活带来了很大的快乐,但是就是总会有意想不到的事情发生。这玩意在16年中旬的时候坏过一次,拿到DLINK客服那里想修一下,结果发现这货早就停产了,只能从总部发一个新的回来供我置换,并收我160元置换费。我只是怕麻烦,又因为自己已经熟悉了这个产品了所以就答应了他们的提议。可没成想换回来以后发生了一件让我到现在都很头疼的事情,那就是远程迅雷这套脚本增加了安全机制了。貌似是DLINK和迅雷在这款产品上有了分歧,迅雷不让用户在smb协议下直接删除所下载下来的文件了,如果想下载还必须登入他们的远程下载网站去删除。这样让我非常恼火,远程迅雷的用户体验本来就不好,却还逼着用户访问他们网站去删除已经存在自己NAS中的资料。

  就因为这个问题刚开始我还以为是人家客服给我换回来的是一个残次品而我又亲自找他们去了一趟,后来不成我还给他们总部的客服打电话,最后给我转到了他们的高级技术人员才真正证实了这件事不是DLINK的问题,而是迅雷在安装到NAS上的脚本做了些文章。

  接下来我就说说来龙去脉吧。当我想删除NAS上的文件时,总是有报错信息。

  就光凭这种报错信息我很难发现是哪里的权限出了问题,但是优先想到的就是NAS上有什么权限。于是我还特意登录了NAS的浏览器后台去设置了我的用户组。但是,通过很多次测试根本就没有用处。也就是说问题不出在应用层面上的权限问题。而后台中的用户组其实是针对访问内容时的用户设计的。

  接下来我就想看看,到底底层给我返回的是什么状态码,好让我能够有目的性的去排查。结果,我通过wireshark找到了真正原因。

  看到SMB条目下边的 nas NT Status: STATUS_ACCESS_DENIED (0xc0000022)错误代码了吧。这就说明了一切的问题。是由于NAS中的权限配置的原因造成的,而罪魁祸首肯定是迅雷的脚本做的怪。

  好了,问题确定了,我们就要想方设法的去获取NAS的权限。NAS的系统是UNIX的,所以我们需要用ssh区连接。但是,我在连接的时候出现了问题。问题是这样的,在windows上用putty就可以ssh到NAS上,但是在mac上我用ssh就不能够连接上。后来,通过查询报错信息,在网上搜了一下发现了问题所在。

  错误提示说不能与nas进行联通,原因是没有找到匹配的宿主key,而且服务器的宿主协议只接受ssh-dss(DSA)。将这段话作为关键词在搜索引擎上搜了一下,果然找到了这个错误提示的响应的解决办法。

  这说的是openSSH 7.0或者更高版本的应用是默认关闭这个公钥算法的,因为这个算法太容易破解了。而后,这篇文章《OpenSSH Legacy Options》也给出了响应的答案。按照帮助文档的提示下,我迅速的登录到了NAS的系统中,并且获取到了NAS的管理员权限。

  之后,就是要找到迅雷的脚本了,我想这个脚本应该不难找也不难改,无非就是一个.sh的文件而已。等到下次我研究出来,再发一篇文章上来。