rolfs.no: Experiencing weblogging

A ssh tunnel will slow down the mouse pointer which can result in a slow response on the client machine. But it will encrypt and secure the input information like your passwords typed on the keyboard. Synergy sends these unencrypted over the network.

Here is how to do it:

On the machine you are using(typing on), run synergy bound to the lo (localhost) interface. Synergys will act as a keyboard and mouse server for the machines you want to control. Do it like this:

synergys -a localhost

Remember that you need to have a /etc/synergy.conf for synergys: On the machine you using(typing on). There you need to specify that SynclientName has access to connect to you.

Then, start the ssh port-tunnel by forwarding port 24800 on localhost yourmachine connecting to it’s own localhost on port 24800:

ssh -R localhost:24800:localhost:24800 yourmachine

Start the synergy client on the machine you want to remotely control and connecting it to localhost (which is ssh-tunneled to yourmachine)

DISPLAY=:0 sudo synergyc -n SynclientName localhost

This was only a small howto on connecting two linux machines with synergy.

Find directories in the directory you are standing in:
-maxdepth 1 -type d

Exclude the first ‘.’ :
-mindepth 1

Remove the ./ part from the list:
sed s@^.\/@@gi

Tar-gzip the directory with compression 1 for faster network transfer:
tar -cv $a | gzip -1

Send the file to the dd program:
ssh -l user server "dd of=/path/to/$a.tar.gz"

Wrapping it into a small example script:

for a in `find . -mindepth 1 -maxdepth 1 -type d | sed s@^.\/@@gi`; do 
(tar cv $a | gzip -1) | ssh -l user server "dd of=/path/to/$a.tar.gz" ;
done

I suggest you install a ssh-key before doing this, or you will have to type the user password for each directory. This script does not support spaces in directory names.

The script below handle directories with space in them, just like “Document and Settings”.
I print each file (%p) with a colon at the end. The seperator used by the for-loop is also the colon which is defined by the IFS variable.

IFS=":"
for a in `find . -mindepth 1 -maxdepth 1 -type d -printf '%p:' | sed s@^\".\/@\"@gi`; do
(tar cv $a | gzip -1) | ssh -l username servername "dd of='/outputdir/$a.tar.gz'" ;
done
unset IFS

Boot the ubuntu-live cd, making the network start.
livecd$ ssh-agent
livecd$ ssh -l username server -A
server$ ssh-add

root@ubuntu:/media# dd if=/dev/sda2 | ssh -l username hostname "dd of=/path/to/save/my_backup_sda2.ntfs.disk"
The authenticity of host 'hostname (192.168.1.1)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'hostname,192.168.1.1' (RSA) to the list of known hosts.
username@hostname's password:
38957625+0 records in
38957625+0 records out
19946304000 bytes (20 GB) copied, 2541 s, 7,8 MB/s
37811184+2292882 records in
38957625+0 records out
19946304000 bytes (20 GB) copied, 2532.89 s, 7.9 MB/s
root@ubuntu:/media#

A predictability of the random number is not good. It makes the randomness predictable, which makes it just predictable. This means that it is a lot easier to guess the key a user has created to gain access to a remote system trough services using openssl keys.

http://lists.debian.org/debian-security-announce/2008/msg00152.html

openssl is affected with vulnerability: “predictable random number generator”.
It is a Debian-specific remote vulnerability. It got CVE Id: CVE-2008-0166.

Here is a perl script that holds all the fingerprints of predictable random number (so called compromised. Around 262 thousand keys).
http://security.debian.org/project/extra/dowkd/dowkd.pl.gz

SSH (OpenSSH)

I removed the fingerprints for obvious security reasons: (You should run as root and without piping to the sed command)

root@untuome:/# ssh-vulnkey -a | sed  s/..:..:..:../xx:xx:xx:xx/gi
Not blacklisted: 2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /etc/ssh/ssh_host_rsa_key.pub
Not blacklisted: 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /etc/ssh/ssh_host_dsa_key.pub
COMPROMISED: 2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /home/user/.ssh/id_rsa.pub
Unknown (no blacklist information): 1024 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /home/user/.ssh/authorized_keys

List all users using ssh keys:

ls -al /root/.ssh/authorized_keys
ls -al /home/*/.ssh/authorized_keys

Fix: remove all authorized_keys that are compromised from the system

I will add more info about OpenVPN and other openssl key software here, but I wonder if you know any other ways to clean out and fix a system for these ssl key security issues?

For sysadmins: I will give you an idea of how to test for week passwords on several servers.

First, collect all /etc/shadow from every server into a single directory (”passwordcheck”) on your own machine and name each of the files like the servername.

I assume that you have a ssh key installed on your user account on all of your servers.
Insecure: The ssh-commands below might give away your password to other users.
Continue reading ‘Run john the ripper on several servers / password files’

I wrote this liferea syncing script for liferea yesterday. It seems to work as I wanted.. When I’ve got some problems, the backup that this script implements helps me solving the issues. I’m pleased with how this script makes my RSS more joyful.

I hope you can get some good ideas or that this script helps you sync your RSS feeds.
Continue reading ’sync-liferea.sh syncing script’

I was looking at why my ssh -vvv was giving me some errors and made me wait for some extra seconds when tried to ssh to other machines.

debug1: An invalid name was supplied
Configuration file does not specify default realm
 
debug1: An invalid name was supplied
A parameter was malformed
Validation error
 
debug1: Miscellaneous failure
No credentials cache found

Continue reading ‘SSH debug1: An invalid name was supplied, Configuration file does not specify default realm’

To get any program to be forwarded through your ssh connection, you need xauth installed on the ssh-server that you’re logging into.

After just putting the xauth in /usr/X11R6/bin/ on the server, the X11 forwarding worked fine for me, even when X11/XFree86/X.org wasn’t installed.

The fastest way to get xauth installed is to get the binary from the XFree86 package. The alternative way is to build the XFree86 from source.

Next time you login, you will se:

/usr/X11R6/bin/xauth:  creating new authority file /home/user/.Xauthority
 
$ set
...
DISPLAY=localhost:10.0
...