ssh – Ryan Schulze

How to find the fingerprints of public keys in authorized_keys

August 15, 2012September 27, 2014Ryanauth, authorized_keys, bash, fingerprint, ssh, ssh keys

If you use keys for SSH authentication (and you should) then you have probably run into the situation that the auth.log shows that someone logged in, even which local user was used (e.g. root), but you have no idea which of the keys in ~/.ssh/autorized_keys was used. The first step you can do to see what is going on, is increasing the log level of the SSH daemon:

/etc/ssh/sshd_config

1	LogLevel VERBOSE

That will spit out the fingerprint of the SSH key used to log in. Example log entry for a successful login:

Aug 15 11:47:40 security sshd[1924]: Connection from 192.168.199.1 port 39648

Aug 15 11:47:41 security sshd[1924]: Found matching DSA key: df:45:12:ea:d2:92:a2:42:aa:ba:25:1a:90:82:1a:1c

Aug 15 11:47:41 security sshd[1924]: Postponed publickey for root from 192.168.199.1 port 39648 ssh2 [preauth]

Aug 15 11:47:42 security sshd[1924]: Found matching DSA key: df:45:12:ea:d2:92:a2:42:aa:ba:25:1a:90:82:1a:1c

Aug 15 11:47:42 security sshd[1924]: Accepted publickey for root from 192.168.199.1 port 39648 ssh2

Aug 15 11:47:42 security sshd[1924]: pam_unix(sshd:session): session opened for user root by (uid=0)

Now that we have the fingerprint of the ssh key used to login, we will need ssh-keygen to spit out the fingerprints of the public keys in ~/.ssh/authorized_keys to be able to compare them. So I wrote a little wrapper called ssh-fingerprint.sh around ssh-keygen to feed it all the public keys from authorized_keys (if you want you can even fit the whole while loop as a oneliner):

#!/bin/bash

initialize() { #{{{

# Treat unset variables as an error

set -o nounset

tempfile=$(mktemp)

authorized_keys="${HOME}/.ssh/authorized_keys"

trap cleanup TERM EXIT # clean up if script exits

} #}}}

cleanup() { #{{{

rm -f ${tempfile}

exit 0

} #}}}

#===============================================================================

# Main

#===============================================================================

initialize

if [ ! -e ${authorized_keys} ]

then

echo -e "\nERROR: ${authorized_keys} file not found\n"

exit

while read line

echo "${line}" > ${tempfile}

ssh-keygen -l -f ${tempfile}

done < ${authorized_keys}

Hackit Server downtime

October 7, 2008Ryanbroken, hackit, linux, ssh

Sorry for the downtime, wasn’t planned. It was late last night when I set up the knock daemon, I somehow managed to accidently copy and past my terminal which resulted in about a quarter of my /etc/init.d/* scripts getting broken. Unfortunatly I didn’t notice it right away. I did notice it when I rebooted the server (kernel change) and lot’s of daemons didn’t come up (oh unimportant stuff like SSH 🙁 ) Well, that’s what backups are for.

knock daemon with INPUT chain set to default ACCEPT

October 6, 2008March 12, 2011Ryanbasg, iptables, knock, linux, Server, ssh

I know there are plenty of pages floating around the Internet about knock daemons that open ports in a firewall after a predefined series of ports are “knocked”. For some reason ALL the pages I found assumed that a) you want the filter in your INPUT chain, and that the INPUT chain defaulted to DROP or REJECT.
In my case, I’m defiantly not going to have a iptables firewall with a default that drops packets. Every few weeks I try out some new software and can’t be bothered with adjusting my firewall every time. All I need it to do is keep pesky people off my ssh, that’s all.

So here is a short tutorial how to set up s knock daemon with a ACCEPT default for INPUT:

/etc/knockd.conf

[options]

UseSyslog

[opencloseSSH]

sequence = 76:udp,123:tcp,7630:tcp,1921:udp

seq_timeout = 25

tcpflags = syn,ack

start_command = /sbin/iptables -I SSH-Knock 2 -s %IP% -p tcp --dport 22 --syn -j ACCEPT

cmd_timeout = 20

stop_command = /sbin/iptables -D SSH-Knock -s %IP% -p tcp --dport 22 --syn -j ACCEPT

iptables:

iptables -N SSH-Knock

iptables -A INPUT -p tcp --dport 22 -j SSH-Knock

iptables -A SSH-Knock -m state --state ESTABLISHED,RELATED -j ACCEPT

iptables -A SSH-Knock -j REJECT --reject-with icmp-port-unreachable

/etc/init.d/iptables save active

Hartknäckige Scriptkiddies

August 19, 2008Ryan1 Commentbrute force, Hacking, linux, Script Kiddie, ssh

Seit gestern Abend versucht irgendein Scriptkiddie mein SSH zu Bruteforce’n. Das an sich ist eigentlich nichts erwähnenswertes da es zum täglichen Müll gehört (wie die Spammer die offene Mail Relays suchen) und eigentlich zum allgemein “Rauschen” im Internet gehört. Nach ein paar Fehlversuche landet bei mir die IP automatisch für eine gewisse Zeit auf eine Blackliste und wird per iptables gesperrt.

Was das ganze hier jedoch interssant macht ist die Hartknäckigkeit derjenigen. Die meisten Kiddies merken “ach mist, meine IP wird geblockt” und versuchen es vielleicht noch von eine 2. IP bevor sie aufgeben. Der hier jedoch hat wohl eine ganze menge an Zombie Rechner zur Verfügung weil er seit ein paar Stunden es schafft nach jeden IP Ban von einen neuen Host seinen Brute Force Attacke erneut zu starten. Jepp, ihr habt richtig gelesen, er führt sie nicht weiter, wo er aufgehört hat, sondern fängt jedesmal wieder von vorne an.

Ich gib ihn 8/10 Punkte für Ressourcen, 9/10 für Hartknäckigkeit und 2/10 Punkte für die Durchführung.