lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 27 Jan 2017 21:23:08 +0000
Subject: Re: [FD] Digital Ocean ssh key authentication security risk --
 password authentication is re-enabled


The last time I contacted them they did not care about this. It's 
basically a feature. They also used to (or still do) reset SSH host keys 
and other things.

A suggested workaround if I remember correctly was to set a sticky bit 
on the files you did not want their bootstrap script to modify. I have 
no idea if this works or if it makes sense as I worked around the 
problem another way.

Have you tried reaching support about it? I would expect you might get a 
different response depending on which tech you end up on.


On 2017-01-27 17:00, Daniel Elebash wrote:
> Regarding cloud computing.
> PasswordAuthentication is reset to yes in  /etc/ssh/sshd_config when
> using ssh key authentication given the following scenario:
> When creating a new droplet from a snapshot where ssh key
> authentication "PasswordAuthentication" in /etc/ssh/sshd_config was
> previosly set to no, "PasswordAuthentication" is reset to yes.
> I am not sure how common this scenario is but for me I often create a
> base snapshot that is pre-configured with firewall settings, sudo
> user, ssh key authentication, various apps, hardening etc. that I can
> then use when spinning up a new server so I don't have to start from
> scratch.  By doing this  I was unaware that PasswordAuthentication was
> automatically re-enabled and that these servers were no longer secure
> via ssh key authentication only, leaving them open to Brute Force
> attacks.
> Steps to reproduce:
> Tested using an Ubuntu 16.04 droplet image
> 1. Create a  new Ubuntu 16.04 droplet and secure it using ssh key 
> authentication
> 2. Edit /etc/ssh/sshd_config and set PasswordAuthentication no
> 3. Reload ssh
> 4. Verify that you can log in using key authentication only, trying
> via password should be rejected.
> 5. Create a snapshot of this droplet
> 6. Create a new droplet from this snapshot
> 7. Open /etc/ssh/sshd_config and PasswordAuthentication will be reset 
> to yes
> You will now be able to log in via ssh using passwords instead of key
> authentication only.
> _______________________________________________
> Sent through the Full Disclosure mailing list
> Web Archives & RSS:

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists