Posts tagged ssh
I recently updated my version of DD-WRT from 14xxx to the latest and greatest 18946
I know that they recommend you do the 30/30/30 reset, but you know what, I didn’t want to lose all my settings.
What I found when the router restarted, is that everything worked fine, Except for SSH
It seems that as of version 17xxx the guys are DD-WRT switched from OpenSSH to Dropbear. No big deal really, exept the SSH keys are not compatible with each other, thus preventing SSH from running.
To fix SSH:
- Enable Telnet
- Telnet into your router and run the following commands:
- cd /tmp/root/.shh/
- rm authorized_keys
- rm ssh_host_dss_key
- rm ssh_host_rsa_key
- nvram unset sshd_rsa_host_key
- nvram commit
Once the Router Restarts, SSH should be working, and when you try to login, you will get a prompt to accept the new Key Generated by DropBear
Don’t Forget to Disable Telnet
Disclaimer: I am not responsible for any damage you may cause your device for doing this
Disclaimer: I am responsible for any AWESOMENESS that comes from your device for doing this
Every time I get a new toy, like any techie I have to see whats under the hood. And this time it was the Javelin S4 Media Server NAS by Patriot.
I bought this NAS to help solve my storage needs. I’m into photography, and currently I have 4 different External HD’s to store my photos. Problem is, they all get out of sync with each other, and there was no real easy way to maintain them all. My solution was to get a NAS that would support RAID and thus, thanks to a nice rebate from newegg I got the Javelin S4.
The *ONLY* problem I had found was that the S4 didn’t support SSH (like it was listed on Newegg.com’s website), and I wanted/needed to be able to SFTP/SSH.
I had 2 problems to overcome. First, gain access to the console on the NAS, second, add SSH to the device.
The solution to my first issue was found in the Patriot Memory Forums and a few posts by a user called “BadIntentions”
BadIntentions was kind enough to release a plugin called “Rooter” which allowed “root” access to the console via telnet port 2380, and also it included a new, enhanced version of busybox that he compiled for the device.
Once I was in, I started to look around the NAS and found that getting SSH on this thing wasn’t going to be easy. Most of the files in /etc are replaced every time the device gets rebooted, and the partition of the OS where all the utility scripts reside is set to read-only.
So I went about searching for a way to get SSH on this thing, and through my poking around the system I realized that the only way I was going to get SSH was going to be by creating a “plugin”.
Now the S4 is a little box, but it packs a nice punch
[nas]# cat /proc/cpuinfo
processor : 0
cpu : 460EX
clock : 800.000010MHz
revision : 24.170 (pvr 1302 18aa)
bogomips : 1600.00
timebase : 800000010
platform : PowerPC 44x Platform
model : amcc,canyonlands
Memory : 256 MB
so I wasn’t worried about ssh running, the only issue was, were to get it from.
I automatically thought about the optware project. These guys have been around for a while, and knowing the work that they have done with the NSLU2, and other NAS devices, I figured it was only a matter of finding the right “feed” (this is what they call the package repositories) that would work on the S4. Through some searching, I found that the Synology DS101G has a “similar” PowerPC processor, so I took the risk of giving the packages from the ds101g a try.
Created all the necessary folders and symlinks, placed all the binaries where they were expected, ran the ssh command, and voila, I now had SSH, and I was done (but not quite).
Now I could have called it a day, maybe try to create a plugin for SSH on the S4, but I though, why not get the whole IPKG system working on the S4. Really contribute to the community, plus with optware running on the S4, It would open up this device to way more binaries besides SSH, and make this a very powerful box.
So I went about taking apart the Optware Install Script for the DS101G also known as the DS101Bootstrap. Since there are two versions of the DS101, we specifically target the DS101*G* which has a powerpc processor.
The DS101Bootstrap script does the following in a nutshell:
- runs a bootstrap script that creates a temp ipkg install environment
- creates and mounts the /opt folder structure
- installs the necessary libraries for ipkg
- installs ipkg
- installs openssl
- installs wget-ssl
- sets up the environment so that on every reboot, the /opt folder gets mounted and all the other PATH and ld.so.conf variables get set
What I did, in order to get optware to install on the S4 is:
- Note: REQUIRED TO ALSO HAVE THE ROOTER PLUGIN BY BADINTENTIONS Installed
I created a plugin folder called Optware with a configuration file telling the system where to find the init script
- I took apart the bootstrap.sh script, the bootstrap.ipk, and the ipkg.sh temporary install script and modified them to work on the S4 (mostly Capitalization, and instead of mounting /VOLUME1, mounting my Plugin Directory)
- I ran the install process, which surprisingly ran pretty smoothly, except for a missing library that needed to be installed before wget-ssl, and also symlinking wget to the /bin directory, after fixing those two things, it finished without a problem
- After that was completed, I took the postintall.sh script from the bootstrap.ipk, modified it to fit the S4, and used that as a script to mount and initialize optware
After a reboot of the S4, my optware plugin’s init script gets called, /opt gets mounted, all the init.d scripts for optware run if needed (ssh being one of them) and the system works perfect
I can now SSH to my NAS via port 2222, and If I need to install any other packages, its as easy as “ipkg install <packagename>” (you must be root, so sudo su – if you login as “admin”)
The only thing left now if for me to package all this up into a nice .ppg that the S4 will recognize and automatically install via the webpanel. The day you want to get rid of optware, its as easy as deleting the plugin from the web panel as well.
As for what else is compatible with the S4, well, so far I’ve only tested the SSH package, the wakelan, openssl, and wget-ssl. I read somewhere that the bash package will brick your device, but that was referring to another device, so YMMV
The Link to the Optware Plugin for the Javelin S4:
Optware for Javelin S4 - Optware Installation Modified to work with the Javelin S4 NAS by Patriot Memory
The Link to the Rooter Plugin for the Javelin S4 (needed to install Optware): Rooter Plugin PPG (you must sign up for the forums to download)
If you Enjoy Optware, please consider donating to the guys at the NSLU2 Project (I am not affiliated with them, and I do not receive a “cut” from them, FYI)
None of this would have been possible without BadIntentions and his Rooter plugin
If you ever needed to troubleshoot login issues with the Netscaler, you know that you have to drop down to the Command Line Interface (shell) in order to trace the aaad.debug log.
But what if you need to give your helpdesk access to the same logs so that they can troubleshoot login issues? Well, that requires that you give them shell access.
But, as per Citrix, “If a user goes to the shell, that user is already a root user”, and we sure wouldnt want our helpdesk techs having root access to our Netscalers. So how do we give them enough access to troubleshoot but not have root, we can create a “Command Policy”
A “Command Policy” is what tells the Netscaler what a user can and cant do, for example, the command policy for “superuser” is “ALLOW .*” (that’s a period and an asterisk which is Regular Expression for “Any Character”), that means the user with the command policy of superuser can execute any command.
Now to create the command policy for the Helpdesk
- Log in to our NetScaler using a superuser account
- Under the System Folder, select “Command Policies”
- Click the “Add” button and name your new policy “HelpDesk”, make sure that the “Action” is set to “Allow” and enter the following expression under “Command Spec”
1^shell (cat (/tmp/|/var/log/)[a-zA-Z]*\.(log|debug)|ls (/tmp|/var/log))$
Now we have to assign our new policy to our Helpdesk group. Since my NetScaler is “LDAP enabled” for login in, all I have to do is create a group, assign my new policy, and done. (If your Netscaler is not LDAP enabled, then you will have to go and create users manually and assigning them to the group we are going to create bellow)
- Under the same “System” folder, Select “Groups”
- Click the “Add” button and name your new group “NetScaler-HelpDesk” (It has to match exactly what your helpdesk group is called in LDAP, in my case I have a group called “NetScaler-HelpDesk”)
- Under the “command policies” window, pick your newly created “HelpDesk” Policy, then hit the “Create” and then the “Close” button
- Now Fire up putty and try to login with one of your HelpDesk user ID’s, you will see that you can only trace “log” or “debug” files and only in the “/var/log” and “/tmp” directories
Thats all there is to it. Now your Helpdesk can troubleshoot NetScaler log in issues while you concentrate on fixing other things