ssh encrypt/decrypt

[fabrice_035]

#######
##EDIT##

finally it works but I used simply ssh-keygen and not ssh-keygen -o
Strange.
#
EDIT_2 https://superuser.com/questions/1455735 ... eygen-o-do

Code: Select all

 -o Causes ssh-keygen to save private keys using the new OpenSSH format rather than the more compatible PEM format. The new format has increased resistance to brute-force password cracking but is not supported by versions of OpenSSH prior to 6.5. Ed25519 keys always use the new private key format.

hello,

I can try example here

https://sshenc.sh/

First you need edit script because mktemp command from busybox is not working properly and install recent version from the Puppy Package Manager

replace mktemp by /usr/bin/mktemp ( line 43 and next )

Code: Select all

temp_dir="$(/usr/bin/mktemp -d -t $me.XXXXXX)"
temp_file_key="$(/usr/bin/mktemp -u $temp_dir/$me.XXXXXX.key)"
temp_file="$(/usr/bin/mktemp $temp_dir/$me.XXXXXX.cypher)"

Now, Generating public/private rsa key pair.

Code: Select all

root# ssh-keygen -o

then I try the script, encrypt working, but decrypt never.

Code: Select all

root# ./sshenc.sh -p ~/.ssh/id_rsa.pub < test.txt > test.txt.enc

ok, test.txt.enc is well created

but :

Code: Select all

root# ./sshenc.sh -s ~/.ssh/id_rsa < test.txt.enc
no valid decryption key supplied

I can't explain that.

Any idea ?

Thanks

[rufwoof]

For your keygen command of ssh-keygen -o ... instead use

Code: Select all

ssh-keygen -t rsa -b 4096

[rufwoof]

sshenc.sh is ok for exchanging encrypted data between remote/local, remote system encrypts using your public key, you read it using the private key. But if used to encrypt local files then that is only as secure as however secure your private ssh key is. If someone has root access then they can see/copy your private ssh key(s).

With full blown ssh you can add a password to your private keys. Not so sure how secure that is however, and that's beside the point when using dropbear for ssh, so personally I use ccrypt (compiled a musl version and upx'd that weighs in at around a 60KB filesize) that I use/run within initrd. I keep my ssh key ccrypt encrypted and open it up for a short duration (20 seconds) whenever the keys are required. For dropbear (that I use in my initrd boot i.e. Fatdog's "Bulldog") ...

Code: Select all

cd /.ssh
ccrypt -c db_id_rsa.cpt >db_id_rsa 
echo "#!/bin/sh" >/tmp/cleanup 
echo "sleep 20" >>/tmp/cleanup 
echo "rm /.ssh/db_id_rsa" >>/tmp/cleanup 
echo "rm /tmp/cleanup" >>/tmp/cleanup 
chmod +x /tmp/cleanup 
/tmp/cleanup & 
chmod 0600 /.ssh/db_id_rsa 
cd /
ssh -i /.ssh/db_id_rsa someuserid@somewhere.com

Running the above uses ccrypt to decrypt db_id_rsa.cpt to db_id_rsa (that command prompts for the password), and then it creates a script in /tmp that removes the db_id_rsa file after a 20 second sleep interval. Having created that script (and made it executable) the script is run in the background (& after the command) and then the ssh command is run. Once ssh connected the keys are no longer required and after the backgrounded scripts 20 second sleep interval the db_id_rsa (unencrypted keys) is deleted.

That way, even if the usb is lost/stolen, the ssh key is ccrypt encrypted. And even if the system is compromised the only time the keys are decrypted is for a brief period whenever a ssh connection is being established. As typically I only ssh connect immediately after booting a known clean system (boot from usb where the usb is disconnected immediately after bootup), then the window of opportunity for a cracker is as good as closed.

A benefit of ssh with keys is that both the server and client have pre-established keys, which mitigates any man-in-middle attacks. If immediately after bootup a keys based ssh connection is made to a known server then that would immediately highlight if a man-in-middle exploit was being attempted.

Recently I've been compiling a machine specific kernel using localyesconfig. That produces a small (less than 20MB) kernel ... that includes wifi network connection, and kexec. Typically boots in a few seconds (using usb) to cli network connected, a second or two more to ssh connect and validate that the network connection is 'clean' ... and after that kexec can boot any other kernel/system (i.e. main Puppy/Dog system). Or if the network is 'dirty' (man in middle attack) - then no harm done, other than the main system not being loaded and having to move on to another wifi hotspot where a clean connection is available. Once a clean ssh link to a server is established, then you can route all your internet traffic through that ssh (secure) tunnel.