The inspiration for this post comes from Kees Cook’s tweet about having
VisualHostKey yes
on his ~/.ssh/config file.
I’ve played with this option in the past, but having some scripts running over ssh, I was afraid about parsing the “wrong” things on the output.
I’ve enabled this option again this evening, so the head of my ~/.ssh/config looks like:
Host *
VisualHostKey yes
Compression yes
I started to ssh login in to a few machines, just to see the output.
A sample output, looks like this:
+---[RSA 2048]----+
|.E . . o |
|= . . . . o o |
| + o . ..o. . |
| o . o . .*. |
| . +S...*. o |
| . ...+o.+oo|
| . +o +.B|
| . + oo+ +=|
| . o.=o. .|
+----[SHA256]-----+
RSA 2048 is the size of the servers public key and you can check the size of the servers key -as of course yours too- with this command:
# ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub
on your local machine:
> ssh-keygen -l -f ~/.ssh/id_rsa.pub
I have changed a few times my ssh key pair (you must remember to append your new public key to your server authorized_keys, before removing your old key) but I never changed the servers key pairs.
After searching online for a few minutes to educate my self on the matter, seems that when your (in this case) centos machine is starting ssh daemon for the first time, it creates new ssh key pairs.
The procedure is really easy, but before doing anything, we need to edit
/etc/init.d/sshd to add a 4096 bit keysize for SSHv2 RSA:
echo -n $"Generating SSH2 RSA host key: "
rm -f $RSA_KEY
if test ! -f $RSA_KEY && $KEYGEN -q -b 4096 -t rsa -f $RSA_KEY -C '' -N '' >&/dev/null; then
The final steps are these:
> ssh linuxbox
> sudo -s
# cd /etc/
# tar cf ssh.tar ssh
# cd ssh
# rm -f ssh_host_*
# service sshd restart
If you test your ssh connection, you will get an ugly message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
BUT you have to see this error msg.
If you dont, then you have a very serious problem !
Edit your ~/.ssh/known_hosts to get rid of this message and delete the previous record about the old server ssh public key.
Try again, now it should show you something like:
Are you sure you want to continue connecting (yes/no)? yes
Type yes and memorize your new VisualHostKey !
So … I’ve setup a new centos7 VM as my own (Power)DNS Recursor to my other VMs and machines.
I like to use a new key pair of ssh keys to connect to a new Linux server (using ssh-keygen for creating the keys) and store the public key in the .ssh/authorized_keys of the user I will use to this new server. This user can run sudo afterworks.
ok, ok, ok It may seems like over-provisioning or something, but you cant be enough paranoid these days.
Although, my basic sshd conf/setup is pretty simple:
Port XXXX
PermitRootLogin no
MaxSessions 3
PasswordAuthentication no
UsePAM no
AllowAgentForwarding yes
X11Forwarding no
restarting sshd with systemd:
# systemctl restart sshd
Jun 09 10:58:05 vogsphere systemd[1]: Stopping OpenSSH server daemon...
Jun 09 10:58:05 vogsphere sshd[563]: Received signal 15; terminating.
Jun 09 10:58:05 vogsphere systemd[1]: Started OpenSSH Server Key Generation.
Jun 09 10:58:05 vogsphere systemd[1]: Starting OpenSSH server daemon...
Jun 09 10:58:05 vogsphere systemd[1]: Started OpenSSH server daemon.
Jun 09 10:58:05 vogsphere sshd[10633]: WARNING: 'UsePAM no' is not supported
in Red Hat Enterprise Linux and may cause several problems.
Jun 09 10:58:05 vogsphere sshd[10633]: Server listening on XXX.XXX.XXX.XXX port XXXX.
And there is a WARNING !!!
“UsePAM no” is not supported
So what’s the point on having this configuration entry if you cant support it ?
WTF, in only 40min, ssh brute force attack !
Jul 14 17:54:56 server1 sshd[1135]: Server listening on 0.0.0.0 port 22.
…
Jul 14 18:36:16 server1 sshd[2325]: Invalid user center from 70.38.23.166
thank Venema for TCP Wrapper
I believe that this is a security risk for new installations.
Ok, root cant ssh access the server.
But common!
We create a simple user to login and then su to root.
I dont want ssh daemon to be started by default, before i finished with my linux server configuration and add some security measures to prevent issues like that.
And the most significant part is that i had configured my router sshd port to a non known tcp port !!!!