> this vulnerability might permit code execution with the privileges of the authenticated user
Yet another vote for secure authentication, which typically means requiring use of a private key and disabling root login.
Yet another vote for secure authentication, which typically means requiring use of a private key and disabling root login.
A bug like this could be pretty devastating for github and bitbucket type setups where everyone in the world is using a shared, restricted "git" UNIX user authenticating with a private key, for git ssh push and pull.
e.g. Git uses ssh as transport protocol, but github (and similar platforms) don't support direct user login.
I guess that gives the same problem. The exploitation allows to execute arbitrary code, as you would do by launching commands from, say, bash.
I don't know git-shell, but I guess (from the manpage) it restricts the allowed commands. The exploitation of the bug would allow a malicious user to execute a command instead of git-shell. A good example of command could be /bin/bash.
I was explaining the benefits of layers of security. This issue is an issue only to the degree that your server does not trust authenticated users, because it can only be exploited by authenticated users.
The main thing I wanted to see when I saw the OP was 'do I need to update SSH on my personal server yesterday'... and I'm not worried about it at this point.
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
PermitRootLogin no
But the gist of it is PermitRootLogin no in your sshd_config and Protocol 2 (to disable protocol 1), PubkeyAuthentication yes Password authentication no
For this specific vulnerability those will not do, as this exploit is for post-authentication, whether password or pubkey doesnt matter.
Hence, you can add Ciphers blowfish-cbc which will only allow that cipher to be used.
Also add MACs hmac-sha2-512 to only allow that MAC and none, weaker, others.