ctrap script

#!/bin/bash
ctrap(){
echo -ne "\033]0;"puppet"\007"
}
if [ $# -eq 1 ];then
trap ctrap SIGINT
echo -ne "\033]0;"$1"\007"
ssh $1
ctrap
exit 0
fi
ssh $*

compare directory trees

ssh server1 "find /usr/local/apache2/sites/htdocs/ -type f -exec basename {} \; | sort" > server1.txt; ssh server2 "find /usr/local/apache2/sites/htdocs/ -type f -exec basename {} \; | sort" > server2; comm -3 ./server1 ./server2

Installing sshfs on RHEL5

installing sshfs on rhel5
yum install kernel-devel gcc
wget http://downloads.sourceforge.net/fuse/fuse-2.7.4.tar.gz
tar xvf fuse-2.7.4.tar.gz
cd fuse-2.7.4
./configure
make
make install
modprobe fuse
echo "modprobe fuse" > /etc/sysconfig/modules/fuse.modules
ls -la
wget http://dag.wieers.com/rpm/packages/fuse-sshfs/fuse-sshfs-1.9-1.el5.rf.i386.rpm
wget http://dag.wieers.com/rpm/packages/fuse/fuse-2.7.3-1.el5.rf.i386.rpm
rpm -Uvh ./fuse-2.7.3-1.el5.rf.i386.rpm
rpm -Uvh ./fuse-sshfs-1.9-1.el5.rf.i386.rpm

Using SSH Remote and Local Tunnels

The following example demonstrates how to use Remote and Local SSH tunneling to access a service on your highly secure home computer (that's not exposed explicitly through a firewall at your home) from a remote location.

For example:

On Home Computer, before traveling:
ssh -R 44444:localhost:22 user@remote.computer.ip.address

On Remote Computer, after arriving at work:
ssh -L 22222:localhost:44444 user@remote.computer.ip.address (possibly rfc1918 ip)
ssh user@localhost -p22222

Wa la, you now have a SSH session to your home computer from work.

 

SSH Remote Command Execution

The following example allows you to execute a command on a remote system and return the results of the command without a shell session.

Simply include the command immediately after the normal ssh session request. Here's an easy one for a periodic secure rule integrity check on openBSD using pf.

ssh someuser@ip.add.re.ss 'pfctl -s rules | openssl sha1'

 

Use sshfs to Securely Mount Remote File Systems

The following commands can be used on *BSD systems.

# pkg_add -r fusefs-sshfs
# kldload /usr/local/modules/fuse.ko
# sysctl vfs.usermount=1
# mkdir /mnt/docs
# sshfs user@x.x.x.x:/some/remote.dir /mnt/local.dir

 

SSH pubkey on a NetScaler Application Switch

I like to take a backup of all my device configurations on a regular basis. Its usually pretty straight-forward, simply add a scp command to cron, but with the NetScaler there's a little gotcha.

The default location of the authorized_keys file is in '/flash/nsconfig/ssh'. After you append your public key into the file, you'll need to copy the 'authorized_keys' file to '/root/.ssh/'.

This filecopy will need to be done after every reboot of the NetScaler because the / mount point is on volatile media.

If you want to script this action, or any other post-boot commands on a NetScaler device, create or edit the file '/flash/nsconfig/rc.netscaler', set the perms on the file to 755, and start adding commands to the file.

 

Screen

Screen is probably my favorite application. It's a perfect example of the unix philosophy.

It's simply a window manager for terminal sessions, a great tool for developers, engineers and researchers that use multiple ssh sessions to perform their work.

Install it:

# pkg-add -r screen

The way I use it is by (re)connecting to a server where screen is installed, usually in a openbsd or freebsd vm that I run on a desktop or server machine. During the time I was disconnected (travelling to/from work, etc) screen maintained my many ssh sessions for me, and when reconnect I execute the following command:

# screen -d -r

-d : any existing screen processes are detached
-r : screen then reattaches the detached screen session and attaches it to your current tty/ssh session.

Most useful commands while using screen:
Crtl - A, Shift - C : Create a new tty session
Crtl - A, Shift - A : Edit the name for display in session manager
Crtl - A, Crtl - " : invokes the session manager, use arrow keys
Ctrl -A, Ctrl -A : Toggle between two tty sessions

See the manpage for lots more on commands and customization.

Using passwords that are good only once (OTP)

Using One Time Password (OTP) is a good idea these days. Luckily, its very easy to set up.

make sure /etc/skey directory exists

jack:/jack:37# sudo skeyinit -E
jack:/jack:38#skeyinit

in the output of the second command is a command that's been generated for you similar to:

otp-md5 100 bdsd523700

execute that command, adding the -n switch such that a list of passwords are generated that you can take with you.

jack:/jack:39# otp-md5 -n 50 100 bdsd523700
Reminder - Do not use this program while logged in via telnet.
Enter secret passphrase:
51: JILT YARD DARE WORM LARK CASE
52: GOOD VOTE NAN ITCH PUP DAM
53: BETH WAKE LACK MIT HANS DARE
54: MORT MAIL BANE LAP RODE YANG
[...snip...]

when you attempt to log in, use the following command structure.

ssh -l jack:skey [ip.ad.dr.ess]

a special prompt will also appear when the server recognizes that your user has a skey configuration. it will tell you which password to enter, counting down from 100.

jack/jack:45#> ssh -l jack:skey 10.200.1.254
otp-md5 97 bdsd29579
S/Key Password:

its asking for the password on line 97.

i don't quite understand the method of he counting, but it doesn't really matter much.

I got all this info from here
I wonder if I can restrict sshd to only accept skey authentication?

Double-Hop SSH

Sometimes I need to access a server that's behind two or more firewalls. I use SSH tunneling to accomplish this, and in this example I show port specifics for MySQL.

First, I establish a ssh session with a local tunnel to 'Server A' that's NAT'd through a firewall. 'Server A' sits in a DMZ.

Second, I establish another ssh session with a local tunnel from 'Server A' to 'Server B' that's NAT'd through another firewall. 'Server B' sits on the INSIDE network. The local port of the tunnel in the first session on 'Server A' corresponds to the referenced port on 'Server B' in the second session. A "plumbing" of sorts has been configured.

Session 1 - Client to 'Server A'
> ssh -L 44444:localhost:9999 user@serverA

Session 2 - 'Server A' to 'Server B'
> ssh -L 9999:ServerC:3306 user@serverB

As you can see, to get to 'Server C', the client application would connect to localhost:44444, sshd would bitpump traffic from TCP:44444 on the client to TCP:9999 on 'Server A'. Then through the second ssh tunnel between 'Server A' and 'Server B', sshd would bitpump traffic arriving at port TCP:9999 on 'Server A' and bitpump traffic to TCP:3306 on 'Server C' through 'Server B'.

Be responsible, make good choices. Have fun and don't kill anybody.

Using PKI with SSH

If you're concerned about the global increase in brute-force SSH login attempts, you can use PKI to prohibit successful unauthorized authentication through password guessing.

Generate key pair
# keygen -b 1024 -t rsa -f ./rsa_id_clientname

Add/append public key to ~/.ssh/authorized_keys file on the target

Add/append a few lines to ~/.ssh/config on the client
Host
User
IdentityFile ~/.ssh/

Attempt new SSH session

Configuring SSH in Windows

Install Cygwin
Select additional component: openSSH
Launch cygwin prompt
Run ssh-host-config
Start sshd

An decent walkthough is here.

Configuring SSH in Cisco IOS

To Configure SSH

1. Configure AAA
2. Configure SSH
3. Configure VTY


Configure AAA
aaa new-model
aaa authentication login default local
aaa authorization exec default local
aaa authorization network default local


Configure SSH
hostname
ip domain-name somedomain.com
crypto key generate rsa
ip ssh version 2
no ip ssh timeout


Configure VTY
line vty 0 4
login
transport input ssh
password 0


Check SSH Configuration

show ssh
show ip ssh
show ip ssh vty