This script will generate a recursive, unified diff between the same path on two remote servers. You set the CONNECT1 and CONNECT2 variables as necessary to point to your hosts/paths. Of course, the users you connect as must have read access to the files/directories you’re accessing.
# USAGE: ./sshdiff DIRECTORY
# E.g. ./sshdiff static/css
# Generates a recursive diff between /var/www/css/static/css
# on two separate servers.
scp -rq -P "$PORT1" "$CONNECT1" "$TEMP1"
scp -rq -P "$PORT2" "$CONNECT2" "$TEMP2"
echo -e "\n\n\n\n\n"
diff -urb "$TEMP1" "$TEMP2"
rm -r "$TEMP1"
rm -r "$TEMP2"
Tests for and removes UTF8 BOMs.
for F in $1
if [[ -f $F && `head -c 3 $F` == $'\xef\xbb\xbf' ]]; then
# file exists and has UTF-8 BOM
mv $F $F.bak
tail -c +4 $F.bak > $F
echo "removed BOM from $F"
The magic is
tail -c +4 which strips the first 3 bytes.
Last week I tried to SSH into my webhost account (on Site5) from work and—forgetting my password—it locked me out after several failed attempts. SSHd would just close the connection without asking my password.
work:~$ ssh email@example.com
Connection closed by xx.xx.xx.xx
I could log in from any other location, so I figured it was an IP ban and after a few days and a support ticket, I’d be in, but things got strange.
- The Site5 techs could not find any evidence of a block on my account. They were pretty responsive.
- It couldn’t be an IP block because I could log in from a virtual machine which used my workstation IP as gateway.
- When connected to VPN (different public IP) it still refused me.
- It couldn’t be a port 22 block because I could attempt a login to a different account on the same host and it would give me a password prompt.
- Could it be Snow Leopard? I could log in from another workstation running it.
- My machine? I could log in to several other hosts, including another account on a different Site5 host.
On the server I had an
~/.ssh/authorized_keys file with an old public key—the file hadn’t been touched for 2 years. I deleted it and—voila—SSHd would again ask for my password and log me in fine.
Why would the presence of
authorized_keys cause SSHd to refuse to give a password prompt to one particular client’s connection to one particular account? OSX did give me a default RSA keypair, but even if the public key had been forwarded, SSHd should revert to password auth if it doesn’t find it in
Our Ubuntu web host, hosted with OSG, was not able to send mail (using PHP mail) outside of UF. An OSG tech said our From: header should be a valid address at UF (check) and that the logs at smtp.ufl.edu showed those messages never made it there.
The solution was to configure sendmail to use smtp.ufl.edu as the “smart” relay host (as it’s described in the config file):
$ sudo nano /etc/mail/sendmail.cf
Ctrl+w and search for
smart. On the line below, add
smtp.ufl.edu directly after
DS with no space. The result should be:
# "Smart" relay host (may be null)
Ctrl-x and save the buffer.
$ sudo /etc/init.d/sendmail restart
As soon as I did this, the queued messages were sent out. I still don’t know why messages to ufl.edu succeeded while others sat in the queue.