##SOCKS Proxy##
#Set up a SOCKS proxy on 127.0.0.1:1080 that lets you pivot through the remote host (10.0.0.1):
#Command line:
ssh -D 127.0.0.1:1080 10.0.0.1

#~/.ssh/config:
Host 10.0.0.1
DynamicForward 127.0.0.1:1080

#You can then use tsocks or similar to use non-SOCKS-aware tools on hosts accessible from 10.0.0.1:
tsocks rdesktop 10.0.0.2


##SSH Remote Forward##
#The SSH server will be able to access TCP port 80 on 172.16.0.99 (a host accessible from the SSH client) by connecting to 127.0.0.1:8000 on the SSH server.
#Command line:
ssh -R 127.0.0.1:8000:172.16.0.99:80 10.0.0.1

#~/.ssh/config:
RemoteForward 127.0.0.1:8000 172.16.0.99:80

#opens tunnel to 10.3.3.99 on port 80 when you connect to your localhost on 8080 -- 443 is the port ssh is running on the attacking machine
ssh -l ryan -R 8080:10.3.3.99:80 192.168.12.45 -v -p 443

##SSH authorized_keys
~/.ssh/authozied_keys
#During a pentest or audit, you might want to add an authorized_keys file to let you log in using an SSH key.
#The authorized_keys file lives in a user’s home directory on the SSH server.  It holds the public keys of the users allowed to log into that user’s account.

#Generate a public/private key pair like this:
ssh-keygen -f mykey
cat mykey.pub # you can copy this to authorized_keys

#If you want to shortest possible key (because your arbitrary-file-write vector is limited), do this:
ssh-keygen -f mykey -t rsa -b 768
cat mykey.pub # copy to authorized_key.  Omit the trailing user@host if you need a shorter key.

#Connect to the target system like this (you need to know the username of the user you added an authorized key for):
ssh -i mykey user@10.0.0.1

#Caveat: The authorized_keys file might not work if it’s writable by other users.  If you already have shell access you can “chmod 600 ~/.ssh/authorized_keys”.  However, if you’re remotely exploiting an arbitrary file-write vulnerability and happen to have a weak umask, you may have problems.