Der Linux Kernel ist ein Optimist

Manchmal führt zuviel Optimismus zu Problemen. Dies gilt leider auch für den Linux Kernel in seiner Defaulteinstellung ab Version 2.1.27 bis 2.5.30. Damit der Kernel jede Speicheranfrage per malloc() immer(!) positiv beantworten kann, schickt er seine oom-killer los, um der einen „beliebigen“ Prozess abzuschießen. Als Resultat stürzt u.U. dann der gesamte Rechner ab. Beispielsweise mit folgender Meldung:

sw-engine invoked oom-killer: gfp_mask=0x201d2, order=0, oomkilladj=0

Call Trace:
[] out_of_memory+0x8e/0x2f3
[] __alloc_pages+0x27f/0x308
[] __do_page_cache_readahead+0x96/0x17b

Um das Problem zu lösen, sollte das Verhalten des Kernel angepasst werden, damit nicht mehr Speicher vergeben wird, als vorhanden ist. Dazu sollten in der Datei /etc/sysctl.conf (ab Kernel 2.5.30) folgende Zeilen eingetragen werden:

vm.overcommit_memory = 2
vm.overcommit_ratio = 80

Bei älteren Kerneln (2.1.27 – 2.5.30) sollte die Defaulteinstellung von 1 auf 0 gesetzt werden.

Kontrolle des aktuellen Status: echo '/proc/sys/vm/overcommit_memory' 
    ==> 0 : besser, 1 : overcommit aktiv, der OOM-Killer schlägt zu.
echo '0' > /proc/sys/vm/overcommit_memory

Original-Hinweis findet sich unter How to fix the OOM killer crashes under Linux

Eine genauere Erkärung und Funktionsweise findet man unter The Linux Kernel: Memory – 9.6 Overcommit and OOM

Happy Linuxing … 🙂

Wie kann ich mir den SSH-Key meines Servers anzeigen lassen?

Manchmal will man sich auf einen Server per SSH einloggen und bekommt dann eine Man-In-The-Middle Warnung und fragt sich, ob es wirklich ein Man-In-The-Middle ist, oder man nur wieder vergessen hat, ob sich der SSH-Schlüssel des Servers geändert hatte?

In diesem Fall sollte man die angezeigte Schlüssel-ID des ssh-client mit dem echten auf dem Server vergleichen. Die Schlüsel-ID des Servers bekommt man in der Warnung des ssh-clients direkt angezeigt. Aber wie geht das auf dem Server?

Knowledge Center Home
Cloud Hosting
Cloud Servers
Rackspace Cloud Essentials 3 – Checking a server’s SSH host fingerprint with the web console

Let us know what you think of our Knowledge Center!
Rackspace Community

Learn about Rackspace products, ask questions, and share your knowledge in our Rackspace Community.
Rackspace Cloud Essentials 3 – Checking a server’s SSH host fingerprint with the web console

Article ID: 1109
Last updated on May 20, 2013
Authored by: Jered Heeschen


Explaining the host key
Why the host key might change
A dire warning
How to check
The web console
In the Control Panel
In the console
The best way
The not-best way
Write it down
Completing the connection – maybe
First-time connection
Host key has changed
Linux and Mac OS X
Windows and PuTTY

Explaining the host key

One of the fundamentals of SSH is that it uses a „fingerprint“ generated using a server’s unique „host key“ to identify the server to a client. You may have seen a warning sometime related to the host fingerprint, either that it can’t be verified or that it has changed.

The host key is randomly generated when the SSH server is set up and is used to identify the server you’re connecting to. Warnings about it are more than just a devilish developer’s effort to inconvenience us (though it’s difficult to rule that motivation out entirely).

No, the host key is actually central to the security provided by SSH when you make a connection to your server. If someone malicious tries to set up a program to intercept your connection and steal your login credentials – a „man in the middle“ attack – then the only warning you’ll get is your SSH client complaining that the host key has changed.
Why the host key might change

The more innocent explanations for a changed host key include recompiling or upgrading SSH, rebuilding the server, or just using a different address to get to the same host. When your system stores the host key it records it by address, so even if „localhost“ and „“ point to the same server an SSH client will treat them as entirely different entries.

Thus, sometimes that message is expected. But even an expected warning doesn’t mean that there couldn’t be a man-in-the-middle attack in progress. It sounds a little paranoid, but that’s good security for you – anything can happen, at any time, and the more you do to rule out any variables the better.

So let’s look at when and how to check the host fingerprint without using an SSH connection. We’ll do it by going in through the server’s web console.
A dire warning

First we’ll look at the error message that probably brought you to this article, a warning that the host’s identification has changed:

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
Please contact your system administrator.
Add correct host key in /home/demo/.ssh/known_hosts to get rid of this message.
Offending key in /home/demo/.ssh/known_hosts:15
RSA host key for has changed and you have requested strict checking.
Host key verification failed.

The warning can be summed up as: The fingerprint that identifies the SSH server is different from what it was the last time you connected to it. Expected or not, you’ll want to check on that.
How to check

If you have your server’s SSH fingerprint written down somewhere you can compare it to what SSH shows you to make sure you’re connecting to the right machine. Most of us don’t write that down, but it’s a pretty good idea to do so if you connect from multiple machines or from unfamiliar computers (like from a consulting client’s desktop or server).

If you don’t have the host fingerprint handy you can use the control panel’s web console to find it.
The web console

The web console lets you connect to your server as if you were, well, sitting at the console. If anything weird is going on with SSH it won’t interfere with you connecting directly to the console through the Cloud Control Panel.
In the Control Panel

You can connect to the web console for your server through the Cloud Control Panel. If you need assistance opening the web console, see this article.

If you don’t have a username and password to use (if you’ve disabled passwords for all accounts, for example) you can use the Cloud Control Panel to reset your server’s root password. Then you can use the new credentials to get in.
In the console

Now that you’re on the server it’s time to get that host key fingerprint.
The best way

The official way to get that fingerprint is to run the „ssh-keygen“ command against the server’s public key, as in:

ssh-keygen -l -f /etc/ssh/

The „-l“ option tells ssh-keygen you want to list the fingerprint, and the „-f /etc/“ part tells ssh-keygen where it can find the host’s public key file. That location is typical for Linux servers, but you may need to poke around a bit to find the file if it’s not in that default location.

The output should be reminiscent of the fingerprint your SSH client showed you earlier:

2048 xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx /etc/ssh/ (RSA)

The first number indicates the strength of the key (in this case, 2048 bits). The fingerprint follows, along with the location of the key it analyzed and the type of key it’s using (usually RSA).