[Cryptography] SSH vulnerability when using passwords

[Tom Mitchell]

On Tue, Jan 6, 2015 at 3:42 PM, John Gilmore <gnu at toad.com> wrote:

> A friend pointed me to this page:
>
>   https://stribika.github.io/2015/01/04/secure-secure-shell.html
>

> ......
>
> Where is this attack written up in detail?  And how is it best
> defended against?
>
>
I did see a link to one paper on this in a previous reply...

Defending often involves the system admin of the far system
accepting the public half and installing it in ~/.ssh for you.
They often disallow ssh with a password for incoming connections.

It is also valuable to promptly  "scp -r ~/pubsshbits/  user at farhost:~/.ssh"
This gives a single ssh-login with password cycle to capture and analyse.
Test the ssh connection then set a fresh password.

The paranoid might also retire the initial public key installed by
the system admin for you assuming it was vacuumed up in transit and
tossed into a system to be abused and perhaps cracked.  The site
admin (root) will commonly have access to your ~/.ssh dir so
take a measure and manage the secret half of keys with care.

Most attacks take some non zero amount of time to process and analyse
to promptly changing keys and passwords can quickly invalidate the result
of that
analysis before they get to use it.  See the man page for ssh and friends...

Check "ssh -i yourmagicfile"

  -i identity_file
             Selects a file from which the identity (private key) for
public key authentication is read.  The default is ~/.ssh/identity
             for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa,
~/.ssh/id_ed25519 and ~/.ssh/id_rsa for protocol version 2.
             Identity files may also be specified on a per-host basis in
the configuration file.  It is possible to have multiple -i
             options (and multiple identities specified in configuration
files).  ssh will also try to load certificate information from
             the filename obtained by appending -cert.pub to identity
filenames.





-- 
  T o m    M i t c h e l l
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150106/07108657/attachment.html>