Unable to negotiate with 1.2.3.4 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

While trying to connect to an older esxi server I got the error message Unable to negotiate with 1.2.3.4 port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

I was wondering.

The solution $EDITOR ~/.ssh/config

Host 1.2.3.4
    User root
    HostKeyAlgorithms=+ssh-dss

iptables 101

How to do things with iptables. Safety first: How to reset everything.

sudo iptables -F
sudo iptables -X
sudo iptables -t nat -F
sudo iptables -t nat -X
sudo iptables -t mangle -F
sudo iptables -t mangle -X
Also, safety first: Don’t just copy something and run it on your server. You better understand what you are doing.
How to block a service?
Instead of using “DROP” you should use “REJECT –reject-with tcp-reset”. If you want to be able to access that service from the inside, you have to add an allow rule first.
sudo iptables -A INPUT -p tcp -s localhost --dport 3306 -j ACCEPT #mysql allow local
sudo iptables -A INPUT -p tcp --dport 3306 -j REJECT --reject-with tcp-reset #mysql

The “REJECT –reject-with tcp-reset” looks to the outside like there is no service running. A “DROP” will show that there is a firewall / iptables working.

Blocking an IP range

sudo iptables -A bannedDownloader -s 14.120.0.0/16 -j DROP

Disallow NTP queries

sudo iptables -A INPUT -p udp -s localhost --dport 123 -j ACCEPT #ntp allow local
sudo iptables -I INPUT -p udp --dport 123 -j REJECT #ntp

Block timestamp

sudo iptables -I INPUT 1 -p ICMP --icmp-type timestamp-request -j DROP
sudo iptables -I INPUT 1 -p ICMP --icmp-type timestamp-reply -j DROP
sudo iptables -A INPUT -p icmp --icmp-type 13 -j DROP

SSH Tricks

This is more for me than others. Sometimes I forget things like this.

SSH Dynamic Socks Proxy for the browser.

ssh -D 8888 [email protected]
Browser: Socks Proxy localhost 888

SSH Tunnel to another host

ssh -L 9090:localhost:9090 user@proxyhost -i SSHKEY ssh -L 9090:localhost:9090 -N user@TARGETSYSTEM

Also SSH Tunnel Bypassing Transparent proxy using apache

SSH Tunnel Bypassing Transparent proxy using apache

A feature of the apache webserver is that it allows to to create a SSH connection through a transparent proxy / firewall. This is a stealth technic so no one will see it even in a large company network. Only IPoAC is able to interference this.

If you have internet access to port 80 (http) or 443 (https) you can establish a SSH connection to one of that ports. Proxys want the users to surf the web. most of the proxyes will only let their users through the paths they know safe (or whatever filtering their administrators may have set). In the best scenario, the proxy will not allow one particular HTTP method called CONNECT. This method is the one used for SSL / TLS protocol. It establishes a tunneled connection between the client and a remote server, through the proxy server. Since it is used by SSL / TLS, some proxys will let the CONNECT method free to certain sites, and most probably only on port 443.

Apache plus mod_proxy module will let us set up an HTTP server listening on port 80, and at the very same time an HTTP proxy. The proxying part is done by mod_proxy. This module turns Apache into a fully functional HTTP forward-proxy and reverse-proxy. the exciting feature of mod_proxy is its ability to handle the CONNECT method. It will even handle it if the transparent proxy, at the boundaries of our enterprise network, does not allow the CONNECT method. This, because we will talk GET and POST with Apache, the CONNECT thing happens inside Apache, and outside of the control of the enterprise proxy. The end result: we can use the CONNECT method.

Client side

  • SSH Client
  • Proxyclient

server side

  • apache webserver 2.x

This is an example virtual host configuration which I used for testing this implementation.

<VirtualHost *:80>
ServerName proxy.mydomain.com
ProxyRequests On
AllowCONNECT 22

<Proxy *>
Order deny,allow
Deny from all
</Proxy>

<ProxyMatch (host1|host2)\.mydomain\.com>
Order deny,allow
Deny from all
#Now we allow only our IP to access. Note that this IP must be the  public IP address of the enterprise proxy:
Allow from 222.22.22.100
</ProxyMatch>

# This directive enables DNS lookups so that host names can be logged. The  value Double refers to doing double reverse DNS lookup.
#That is, after a  reverse lookup is performed, a forward lookup is then performed on that  result. At least one of the IP addresses in the forward lookup must  match the original address. It is paranoid but is a good security  measure

HostnameLookups Double

ErrorLog /var/log/apache2/proxy.error.log
CustomLog /var/log/apache2/proxy.access.log common
</VirtualHost>

And now, the final step: configure our browser to use 127.0.0.1 on port 8080 as proxy. Finally we can login to our SSH server and try pointing our browser to any website we know blocked by the enterprise transparent proxy!

I know I left the part setting up apache and proxy, but this isn’t a tutorial for noobs ;-)

This is the BEST part of using Apache. You can set it up as normal web server, serving some webpage. This way whoever point to mydomain.com will see a normal and harmless website, and won’t be able to distiguish it from a non-proxying server.

Wieder einmal aufgeweckt vom embedded Linux

Heute Nacht bin ich mal wieder von meinem embedded Linux aufgewacht, wie schon einmal. Nach der letzten Attacke hatte fail2ban installiert, was erstaunlich einfach ging.

sudo apt-get install fail2ban
sudo nano /etc/fail2ban/jail.conf
sudo /etc/init.d/fail2ban restart

Fertig! Das war es schon.

Und dennnoch blinkte die LED unaufhörtlich in der Nacht. Über 100 IP adressen, die gehackt haben bis endlich ruhe war. Alle anderen computer waren ausgeschaltet, so dass die anderen Ports vom Portforwarding beim scan zumindest closed oder filtert anzeigen müssen. So viel Ernergie wegen einem offnen SSH port bei einer IP die sich alle 24 Stunden ändert? Mich wundert, dass der kleine NSLU2 nicht aufgegeben hat bei einem solchen DDOS, immerhin dauert es schon mal 3,5 Stunden um alleine nmap zu compilieren ;-) Naja 266 MHz und 32 MB RAM sind auch nicht gerade viel, aber als Eingang in mein Netzwerk hat es für mich immer gereicht. Fragt sich nur, was ich als nächstes gegen einen solchen Angriff machen kann. Fail2ban scheint da nicht mehr zu reichen. Ideen?

Aufgeweckt vom ebedded linux

Eigentlich sollte man meinen, dass ein embedded linux leise bis ohne Geräusche arbeitet. So eigentlich auch der Fall bei mir.  Ich hatte mir ein NSLU2 gekauft und dann die Firmware mit Debian geflasht, um ein vernünftiges Linux darauf zu haben, nicht die originale Firmware mit all den Einschränkungen. Die Installation hatte anders als im internet angegeben nicht 4 Stunden, sondern ganze 6 Stunden gedauert, trotz einer guten Internetverbindung und obwohl ich den Prozessor auf 266 MHz schon erhöht hatte, mittels  Entfernen eines Widerstandes der die CPU nut ausbremst. Keine Ahnug warum Cisco Systems das gemacht hat. Da ich anstelle einer externen Festplatte einen 8 GB Flash USB Stick gewählt habe und der NSLI2 keinen Lüfter besitzt, ist gar nichts zu hören. Absolute Stille selbst bei Vollast.

Wie dem auch sei, heute bin ich mitten in der Nacht davon aufgewacht. Irgent etwas blickte sehr hell in meinem Zimmer. Zu nächst dachte ich es sei eine der Netzwerkkarten von den Computer, die eine Verbindung zum switch haben und wegen WOL immer aktiv sind, auch wenn die PCs ausgeschaltet sind. Das war es aber nicht. Die blaue Diode vom dem USB Stick am NSLU2 blickte unaufhörlich. Normalerweise blinkt die nur ganz selten, denn außer einem SSH server läuft nichts aus dem NSLU2. Ich habe dann das Gerät so gedreht, dass jene Diode nicht in in Richtung meines Bettes leuchtet und habe mich wieder hingelegt.

Heute morgen hat sich dann mein Verdacht bestätigt, warum da so viel Aktivität war. Da hat jemand 8 Stunden lang versucht sich auf dem SSH server einzuhacken. Naja die brute force methode klappt halt nicht, wenn root sich gar nicht einloggen kann und der einizige Benutzer, der sich einloggen kann keinen gewöhnlichen Usernamen hat. Aufgeweckt hat es mich trotzdem und das obwohl kein Mux von sich gibt.

Posts Tagged ssh

Archives by Month: