ssh keys

ssh keys can be configured to enhance security, with password-less logins. no password is typed or transmitted.

the basic steps are:
- generate your keys at local end
- secure your private key
- gather your public key
- add public key to remote end

we will look at my two preferred tools:
(1) putty
(2) dropbear

i don't seem to prefer openssh, the seemingly defacto standard, as i consider it bloatware. too big does obscure/obfuscate vulnerabilities. look at my preferred alternatives - so tiny, so beautiful :-)

---

putty-tools are rather quirky to get right the first time. but once you have them setup right, and understand what you are doing, you'll love 'em. i like them also because they are much smaller and efficient than openssh-client, the supposedly defacto standard. putty, though, is very much the defacto choice on windows.

generate your rsa key file on the ssh client
$ puttygen -t rsa -b 4096 -o puttygen_rsa

do not modify puttygen_rsa. copy the Public-Lines from the key file to another file, say puttygen_rsa.pub.

ensure all puttygen_rsa.pub is one word on one line, i.e. join all lines together, with no spaces in between.

now insert "ssh-rsa" and a space in front. you may optionally add your id at the end, ie a space and "ssh-user@ssh-client". there should be a space in between each of these three items. and this file still contains everything on one line only - your public key.

send your puttygen_rsa.pub to ssh servers
$ pscp -v ~/.ssh/puttygen_rsa.pub ssh-user@ssh-server:/home/ssh-user/.ssh/

at the ssh-server
$ cd .ssh
$ cat puttygen_rsa.pub >> authorized_keys

ssh config is now complete, and we can test it from the client.
$ plink -v -i .ssh/puttygen_rsa ssh-user@ssh-server
$ plink -v -X -i .ssh/puttygen_rsa ssh-user@ssh-server
$ pscp -v -i .ssh/puttygen_rsa source-files ssh-user@ssh-server:/destination-directory

---

dbclient is much simpler, generate your rsa key file on the ssh client
$ cd ~/.ssh
$ dropbearkey -t rsa -s 4096 -f dropbearkey_rsa

copy/paste the generated Public key portion to dropbearkey_rsa.pub and send it to the remote end.
$ scp -S dbclient dropbearkey_rsa.pub ssh-user@ssh-server:/home/ssh-user/.ssh/

at the remote end, add your public key to ~/.ssh/authorized_keys.
$ cd ~/.ssh
$ cat dropbearkey_rsa.pub >> authorized_keys

now you can ssh from your client
$ dbclient -i ~/.ssh/dropbearkey_rsa ssh-user@ssh-server
$ scp -S dbclient -i ~/.ssh/dropbearkey_rsa source-file ssh-user@ssh-server:/directory

ssh clients

my last post was about my preferred ssh-server. and this post is about my preferred ssh-clients.

ssh-client configuration has to be done at both endpoints - (i) ssh-client computer, and (ii) ssh-server.

dbclient is included within dropbear.

$ dbclient ssh-user@ssh-server
$ scp -S dbclient source-file ssh-user@ssh-server:/directory

though dbclient is very efficient, you might find it lacking sometimes. i couldn't figure out how to forward X.
also, if you do not have dropbear installed, you might not want to install the dropbear server, just to get dbclient.

i much prefer putty, and specifically the cmdline putty-tools. they are a bit quirky to get right the first time. but once setup correctly, you'll love 'em. i like them also because they are much smaller and efficient than openssh-client, the supposedly defacto standard.
putty, though, is very much the defacto choice on windows. there aren't many alternatives.

$ pscp source-file ssh-user@ssh-server:/destination-directory
$ plink ssh-user@ssh-server

enable X!! forwarding
$ plink -X ssh-user@ssh-server
$ xeyes

enjoy! :-)

dropbear ssh server

i prefer dropbear, because it is much smaller and more efficient than openssh.

install dropbear in debian, with
# apt-get install dropbear

this package contains an ssh server called dropbear and an ssh client called dbclient.

ssh keys

(re)generate your keys

# dropbearkey -t dss -s 1024 -f /etc/dropbear/dropbear_dss_host_key
# dropbearkey -t rsa -s 4096 -f /etc/dropbear/dropbear_rsa_host_key
# /etc/init.d/dropbear restart

remember to save both the private keys and the public keys.

dropbear can be configured in /etc/default/dropbear.

netcat tar backup

debian netcat-openbsd is leaner, cleaner & more efficient than debian netcat-traditional. if you get a choice, prefer the openbsd version.

i now use busybox wherever i can, including nc and tar. small, simple, clean, standard, available the same everywhere.

$ busybox nc

Usage: nc [-iN] [-wN] [-l] [-p PORT] [-f FILE|IPADDR PORT] [-e PROG]

Open a pipe to IP:PORT or FILE

-e PROG Run PROG after connect
-l      Listen mode, for inbound connects (use -l twice with -e for persistent server)
-p PORT Local port
-w SEC  Timeout for connect
-i SEC  Delay interval for lines sent
-f FILE Use file (ala /dev/ttyS0) instead of network

$ busybox tar

Usage: tar -[cxtZzJjahmvO] [-f TARFILE] [-C DIR] [FILE]...

Create, extract, or list files from a tar file

Operation:
        c       Create
        x       Extract
        t       List
        f       Name of TARFILE ('-' for stdin/out)
        C       Change to DIR before operation
        v       Verbose
        Z       (De)compress using compress
        z       (De)compress using gzip
        J       (De)compress using xz
        j       (De)compress using bzip2
        a       (De)compress using lzma
        O       Extract to stdout
        h       Follow symlinks
        m       Don't restore mtime

at {destination}:

$ nc -l -p {port} | tar xpv[z|j]f -

at {source}:

$ tar cpv[z|j]f - {directory} | nc {destination host/ip} {port}

[z|j] compression: use over slower networks. ignore for faster networks and/or slower computers.

tar streams much faster copying than scp 'ping-pong', especially when you have lots of files.

copy files from {some-server} to your machine:

$ ssh {some-server} ‘cd /some/dir && tar cz dir’ | tar xz

and the other direction:

$ tar cz dir | ssh {some-server} `cd /some/dir && tar xz`

image a disk across the network from {box1} to {box2}:

at {box2}:

$ nc -l {port} [-vv] | dd of={disk.img} bs=1M

at {box1}:

$ dd if=/dev/sda bs=1M | nc {box2 host/ip} {port} [-vv] -q 10

[-vv] use at the box1 (and/or box2, if fast enough)

restore this image in {box2} to {box3}:

at {box3}:

$ nc -l {port} [-vv] | dd of=/dev/sda bs=1M

at {box2}:

$ dd if={disk.img} bs=1M | nc {box1 host/ip} {port} [-vv]

compressed backup

at {box1}:

$ tar cpvJf - {directory} | nc {box2 host/ip} {port}

at {box2}:

$ nc -l -p {port} | dd of={directory}.tar.xz bs=1k

---

references:
http://nc110.sourceforge.net/
http://sans.org/security-resources/sec560/netcat_cheat_sheet_v1.pdf
http://wikipedia.org/wiki/netcat
http://saurorja.org/2012/04/06/network-file-transfer-using-netcat/
http://compsoc.dur.ac.uk/~djw/tarpipe.html

SSH From Behind a Firewall via HTTP Proxy

Terminally Incoherent wrote a fantastic blog post, which I want to file away.

SSH From Behind a Firewall via HTTP Proxy