Netios is a little tool aimed to help network administrators to administrate a large number of Cisco network devices.
Providing it with a list of equipments, it connects within SSH to remotly apply IOS commands.

It can automatically :

• retrieve and export in a CSV file the list of local users
• update the local user, the enable password
• change NTP settings
• execute a file of customed IOS commands
• retrieve configuration files

It can read the targets from the command line or from a text file.

Its primary goal is to improve the security by making it easier to renew regularly the local password of these equipments, but it can do more convenient things (and I will continue to work to add more of them).

Check there (tools page) for more details and a download link.

These commands should provide quite a good security level for a while (at least again non super-power governmental organizations) :

$ ssh-keygen -t rsa -b 4096
# openssl genrsa -aes256 -out secret.key 4096

I am the only person to use the server, so I don’t have any scallability issue. :)

Just to enforce the ssh configuration, I added these two line in sshd_config :

Protocol 2
HostKeyAlgorithms ssh-rsa

I have had no time so far to check all the keys on my server. I prefer to stay on the safe side, though I have some reason to believe that my keys might not be so vulnerable : I generated them a long time ago, maybe before the Debian maintainer sad mistake.

It is going to be pretty easy now, for those who are motivated, to get access to the ssh server running keys generated during the 2 last years…

I recommend this article which summarize pretty well the situation. You may also use this tool, which checks if your keys are vulnerable :

$  perl dowkd.pl file ~/.ssh/*.pub

It find it funny to think that I chose to use certificates for security (avoiding brute force attacks).
What’s less funny is the pure disaster for the reputation of Debian.

I already noticed in the past that some companies switched their servers from Debian to Red Hat because of such security problems. They claimed about some security holes being patch much too slowly and about the lack of official support to rely on in such a crisis.
This kind of news is not going to enforce trust from companies.

I myself will think twice in the future about what system to use when I design my networks.

Depending on the systems and equipment you use, you might encounter some timeout that make any login impossible.

I got such timeouts with an OpenBSD machine behind a Pix firewall. With Linux machines, it was very slow but worked.

This issue is related to the reverse DNS check that SSH makes by default during the login process. This is in order to improve the security. Howerver, this is not so secure as a DNS cache can also be spoofed.
Considering this, you can disable this check with not much worry with the right option in your /etc/sshd_config file :

UseDNS no

Of course, the best solution will be that you set up a full DNS infrastructure as soon as possible.