Does anybody know a way of either converting (on android) a putty key to something I can use in ConnectBot, or a good android SSH app that can use Putty keys natively?
I am away from home without my laptop, which I would usually use. I only have my android phone with me.
A few months ago I tried creating RSA key pairs to use with Putty on my laptop and ConnectBot but for some reason I just could not crack it so gave up. I also used puttygen to create an RSA key but it would not work on ConnectBot
Install termux [edit: grab from f-droid or their website, their play store version has been out of date for some time and repos likely wont work on it] on your phone and run
pkg install x11-repo
followed bypkg install putty-tools
which should put a copy of puttygen on your phone. Open your file manager and “Termux” should appear like a USB drive (in Google files it’s under “other storage” at the bottom of the home screen), copy your key file there and Termux will be able to access it.puttygen keyfile.ppk -O private-openssh -o id_rsa
Should let you convert to OpenSSH format and connect to trusted computers. You can also install OpenSSH in Termux to use it as an ssh clientIt also looks like you can install putty in Termux as well, if that’s more convenient for younvm, it needs an x11 server, you’re likely better off with the aforementioned method
You are amazing, thank you so much! It all worked apart from the last one, which said it needs an output file specified so added -o after a quick search. I really appreciate the quick response to, I got in very quickly but only just managed to respond here.
Glad to hear it worked! I edited the comment in case anybody stumbles across it with the same issue
Why are you trying to reuse an ssh key? That seems like a really bad practice. It’s just not the way key pair authentication is supposed to work. Passing around and sharing private keys is BAD. Client devices create their own private keys and only share public keys. Just create a new key from ConnectBot and get it to your server via other methods. If you’re already away from home without any other means of connecting, that last part is admittedly tricky and you may be SOL.
Isn’t ConnectBot a dead project anyway?
Last I checked, it hadn’t been updated in years.Well, I guess I was wrong here. I can’t find a simple full list of all the past updates, but I seem to remember moving away from ConnectBot because it lacked some feature I wanted and no longer worked on my new Android device. I’ve been satisfied with JuiceSSH, but I’m happy that ConnectBot is still alive since it was one of the first apps I installed on the first generation Android phone.I use the same identity file for all of my computers. I don’t have password auth enabled on my server and it’s an extreme inconvenience when I’m on a new machine and have to dig out a different machine to get a copy of my new key to the server. Best practice? Probably not, but I’d rather that than having password auth enabled. I keep an encrypted copy of my id_rsa on my thumb drive so I’ve always got it when I need it.
I had never personally heard of ConnectBot, but it says last updated in February of this year on Google Play. I don’t see a real reason to use it over Termux however.
If you want to stick with that “one key” approach - get a hardware token like a Nitrokey or a Yubikey. That should also work with most Android SSH clients.
This is actually quite handy, I’ve got a yubikey already and didn’t know they could be used for ssh
Unless you have one of the dumbed down Fido or whatever only versions yubikey is just a smartcard with key storage, and multiple different applications for interfacing with the keys - and as everybody (at least everybody sane) uses the same crypto algorithms those can be shared for whatever needs that.
For SSH you’ll have at least two options - if you have a GPG key on that thing just use the auth-key on there (create one if you don’t have that yet) for SSH, if not maybe adding a PIV key is the better option, that should be available via PKCS#11 then. There might be additional options as well, though.
No, you’re missing the point and creating a false choice here. You’re supposed to generate new keys for each client device and load their various public keys into the authorized keys file in your server user’s home folder. Copying around your private key like that is just BAD security and not how public key authentication is designed to work. It’s not as if the only two options are your bad way or passwords.
As an example, you copy your single private key to various devices and even carry (a probably un encrypted) copy around with you on a thumb drive, while I generate a fresh key set from each client that I use to connect. When your private key is compromised (when, NOT if), you must remove that public key from your server to lock out the bad actor, but that also completely locks you out. Unless you have physical password access to the machine at the moment its compromised, you’re also locked out. When one of my keys is compromised, I can just exclude that machine’s key from my authorized keys list on the server and continue accessing my machine remotely via any of the other uncompromised clients.
Again, I know it’s not amazing security but it’s not inherently bad. The key (actually encrypted), if (not when) compromised would provide the same level of access to my system as having two keys with one compromised. Assuming I’m an all knowing wizard and can smell when a key is compromised, I can log in remotely and replace the old key with a freshly generated one. More likely however is that if anybody was going to actually do something with my compromised key, they’d clear my authorized_keys file and replace it with a key I don’t have access to. Don’t kid yourself into thinking having multiple keys suddenly makes you 10x more secure.
What’s more likely is someone finds my flashdrive on the ground, goes “oh boy free flashdrive full of Linux ISOs and recovery tools!” And proceeds to wipe it and use it for their own shit, while I regenerate a new key when I notice it missing.
No, it is inherently bad to copy around private keys. You have some fundamental misunderstandings of how key authentication security works. RTFM.
It’s not “best practice”, but a compromised key is a compromised key whether that key is used to connect 1 or 100 computers to a server. No, I can’t shut off access to exactly one machine, I do not however have any difficulty in shutting off access to every machine and replacing it with a new key. Your system and my system are no different with a single compromised key.
If I had 100 computers that I had to change identity files on each time it was compromised, and my keys were being compromised often, I would see a benefit from using multiple different keys.
Quit acting like I’ve left the front door to my house open when the door is locked but my roommate and I share the same key.
None of what you’ve just said here is true. They don’t work like house keys. Your system and my system are VERY different because I’m not making copies of my private keys anywhere. They never leave the safe place I created them. I only ever transfer the public keys. I could post my public keys here and there would be no security compromise for me. You came here asking for help. I tried to help you. I’m sorry it wasn’t what you wanted to hear. Your attitude sucks.
The best practice is that the device private key should never leave the device. One device, one key. A device is lost or compromised? Remove that device’s key from your list.
I also use ConnectBot and importing a private key generated elsewhere never worked for me, so I generate directly in ConnectBot itself and add its public key to my server, which is what I should do anyway.