DroidSCP v1.4 released!
May 11th, 2010DroidSCP v1.4 has been released to the Android Marketplace. New features and fixes are:
- Add soft link support.
- Add DSA public and private key generation and authentication to the unlock version.
- Add time left to the transfer status.
- Fix force close on v2.1 when the screen is quickly rotated.
The key generator is located in the bottom menu when you’re in the connection screen.
May 12th, 2010 at 6:05 pm
How do I supply my own private key that is already on my SD card?
May 12th, 2010 at 6:13 pm
Make the directory “/sdcard/droidscp/” and copy your private key there. Right now you’ll have to name the file “id_dsa” for DroidSCP to recongize it. The private key also needs to be DSA.
May 12th, 2010 at 9:22 pm
I’m still having some trouble with this in general. Note I’ve verified that my own id_dsa key works with ConnectBot ssh to the same server that I’m connecting to with DroidSCP.
I think I have 2 theories on potential problems. First, a procedure to demonstrate my theories, then I’ll explain what I think the problems might be.
My steps were:
a) generate key with DroidSCP, install generated pub key on server side.
b) observe I could connect with generated key
c) copy my id_dsa over /sdcard/droidscp/id_dsa
d) try to reconnect — success (yay?)
e) uninstall generated pub key on server side.
f) try to reconnect — fails to password prompt
g) forcefully kill ‘DroidSCP’ and ‘DroidSCP Unlock Key’
h) start DroidSCP; try to connect — still fails
i) copy generated id_dsa back into /sdcard/droidscp/id_dsa; reinstall generated pub key on server side.
j) try to reconnect — fails to password prompt
k) forcefully kill processes as in (g)
l) start DroidSCP; try to connect — succeeds.
It seems to me that DroidSCP must be reading id_dsa after it is generated and after every time the DroidSCP process starts, but while it is running it will ignore changes to the id_dsa file.
I think the reason for the success in step (d) and failure in step (f) was because DroidSCP had internally cached the generated key, which caused it to fail when the generated pub key was removed from the server side in step (e).
Likewise, my own id_dsa, which doesn’t seem to work, must have been cached in step (j), causing it to fail even though I had copied the generated id_dsa back in place in step (i).
Lastly, I’m not sure what is wrong with my id_dsa. I wonder if it is because it is a different bit strength? It is approximately twice the size of the generated id_dsa so it is definitely a different strength. Do you know if it should support this?
If so, it would be great if it could.
I find ConnectBot SSH’s public key management quite good. You can either import a key from sdcard or generate a key. Then you can choose whether to use a particular key for a given connection, whether each key should be loaded by default, etc.
Those are all nice to haves, but at a minimum I’d find it useful to be able to use my own keys:
i) of different bit strengths
ii) without needing to forcefully restart DroidSCP.
Sorry for the long winded post. I just wanted to provide as much detail as possible.
P.S. I noticed a typo on the screen after generating a key. It says you might have to copy the generated id_das.pub (rather than id_dsa.pub). It also references ‘authorized_keys2′. For my version of OpenSSH (4.0p1), I needed to add it to ~/.ssh/authorized_keys.
May 12th, 2010 at 11:01 pm
Reaper, thanks for taking the time and digging into this problem. Let me get to each of your points.
1. You’re right that DroidSCP caches the keys on the backend. It should be a simple fix to flush the cache during the connection process and reload the key from sdcard.
2. About DSA keys with different lengths, this is going to be a long one. So here goes:
At some point in the past, the US government put restrictions on the exports of crypto products. RSA was limited to 512 bits while DSA was limited to 1024 bits. Those limits has been relax now and RSA could be exported with lengths up to 4096 to most countries and DSA can support 3072 bits.
Those who wrote the encrypt/decrypt engines are the ones on the hook to make sure their product do not violate any export laws. For example, here’s an article about SUN dealt with the export law with JCE.
Google, of course, needs to follow the same restrictions since their SDK provides the cryto engines for RSA and DSA. The problem is that for some reason they decided to follow the old restrictions. My guess is that during the development of SDK v1.0, the restrictions were still in places and they had no choice but to follow them. And now they simply didn’t bother to update it.
How’d I come to that conclusion? To answer that you need to know how DroidSCP works. DroidSCP calls the JSch library, which is a SSH connection package written in Java. JSch then uses java.security.* to encrypt/decrypt its keys. When I compiled JSch under the Android SDK, it cannot connect to servers via RSA or DSA with keys outside the old acceptable range. However, when I compiled JSch with SUN’s latest java compiler it works without any problems. So that tells me that the compiler’s libraries are the ones at fault. So that means to fix it properly I’ll have to write my own security libraries. Something that’ll take a while to do.
I took a look at connectbot and they seem to support RSA. So I imagine they must have wrote their own. I notices that the generation of the DSA keys have the length greyed out, that means they’re using a fix length. I have to play around with that a little more but its difficult to extract the keys from connectbot (why did they choose to implement a copy text instead of saving the file to sdcard?).
I should be able to get out a version of DroidSCP that’ll clear the internal cache and re-read the key from sdcard soon. DSA lengths of bigger than 1024 will take significantly more time. The next feature I want to add before tackling different DSA lengths is recursive directory download.
May 13th, 2010 at 1:17 pm
Thanks for the info Kenny.
I did know about the export restrictions, but I thought that was 10 years gone now. So I’m as surprised as you that Google’s SDK doesn’t support larger keys.
It would be nice to see some kind of notification if a key fails to be loaded. I suppose your intent was not to support keys not generated by DroidSCP, which is why some of these issues cropped up.
I agree that recursive directory copy would be higher priority than RSA support, DSA support for larger keys, and more full-featured key management. That would be pretty hard core to write your own cryptography library from the ground up…
Out of curiosity, do you have plans to support directory sync (like rsync) after recursive directory support?
Just a suggestion for the look and feel of recursive directory support. With other Droid apps I’ve used that support recursive directory copy, I find the status bar implementations weak — they tend to show progress of the current file. It WBN if they figured out the total number of bytes to be copied and showed an overall progress (and if there’s real estate of secondary importance would be status of the current file).
May 13th, 2010 at 3:49 pm
Kenny, I just got curious and did some digging. It looks like ConnectBot uses the Trilead ssh2 library. It seems to have a confusing history that started out known as ganymed ssh2 and is now ganymed ssh2 with a new home.
In any event, it appears as though it has no external dependancies on crypto, as it has all of it’s own crypto code. It also has a BSD-style license like Jsch.
So I don’t know if you already knew all of this or if you’re interested. It might be a big job to migrate to a new library, and/or it might not have some functionality that you need. I just thought I’d pass it along.
Cheers.
May 20th, 2010 at 9:16 pm
Thanks for the links Reaper, let me see how hard it is to swap the libraries around.
June 17th, 2010 at 10:54 pm
Hi, I’m having a problem getting DroidSCP to connnect to Mac OSX 10.6.3. I’m connected to WiFi while attempting to connect to the internal IP – DroidSCP asks if I wish to store the Mac’s fingerprint, when I hit yes it immediately responds with a simple “connection failed” – no timeout or anything. I can connect to the Mac via SCP fine using WinSCP on my laptop on the same network, and there are no obvious problems in the Mac’s /var/log/* files… Are there any known issues you’re aware of?
Thanks.
June 21st, 2010 at 7:20 pm
I can’t think of a reason why I won’t connect to a Mac. I’ll need to find a Mac to test this problem.
August 8th, 2010 at 9:05 pm
Nice app, connects without any problems to my Linux based NAS but simply refuses to show the directory listing so I cant use it for downloading. I’ve tried several different languange codes, ISO-8859-1, CP437, CP850, Unicode, none works. WinSCP works fine with the same server.
August 8th, 2010 at 10:27 pm
It may be that there is a problem with the listing engine. Could you log into your NAS and do a “ls -al –time-style=long-iso” and let me know the results.
August 16th, 2010 at 11:08 am
I’m getting really slow transfer rates downloading from a local server. I have tried several times. I am only getting 30k /sec and the connection gets lost before I can transfer a 350 meg file. the bandwidth is there. If I run swiftp on the phone, then connectbot to the server, I can send the same size file in about a minute. (That’s a lot more annoying to do) I’d use andftp but don’t have FTP on the server.
Any ideas?
Motorola Droid, android 2.1
August 17th, 2010 at 8:11 pm
One of the difference between ftp and scp is that scp requires a lot more CPU power to encode/decode the traffic. 30k is around what I get too on my own phone.
August 20th, 2010 at 2:01 am
Wow I haven’t considered the CPU load of SSH since I upgraded from a 100 MHz Pentium I. Is it possible that a better lib could be used for SSH? I really fell it should be faster.
October 18th, 2011 at 11:20 pm
over the counter birth control…
Buy_generic meds…