Hi,

That's not
security through obscurity. It's a way to limit the exposure to a brute force attack with an a privileged account.

Also this allows the user uses a different account so remote attacks that user is unknown and can not be used to brute force delimiting more exposure.
Most instances cloud providers do this basically, like EC2 where the normal user for a predefined fedora cloud instance is 'fedora'  (
public key-based authentication).
Whenever possible need to limit remote access, and one of the most important points are the privileges of these remote access.

It must be guaranteed a minimum of security for all users (Desktop/Cloud/Whatever). Should be the responsibility of the administrator to enable this remote access.


--

Francisco Alonso. 
http://twitter.com/revskills 
PGP: 0xE2E64DCA
--

On Mon, Jan 12, 2015 at 10:40 AM, Milan Keršláger <milan.kerslager@pslib.cz> wrote:
No, this is not good idea as I wrote few minutes ago because it does not
improve security, it just provide feeling of better security, see:
https://en.wikipedia.org/wiki/Security_through_obscurity

I wonder why no-one responded like me, because this was discussed many
times ago. Well maybe many times since 1995 (when SSH was born) and
maybe I'm a little bit old so I read it many times again and again.

It seems like SSH does not make padding sufficiently, but this changes
nothing on what I wrote.

Disabling root loging does not solve the problem and it profides only
false feeling of security.

M.K.

Dne 12.1.2015 v 09:56 P J P napsal(a):
>   Hello,
>
>> On Sunday, 11 January 2015 2:27 PM, Peter Robinson wrote:
>>>> Earlier in the discussions I was told that this is not really an issue: in
>>>> production, about every server with remote access also has a KVM.
>>> Often not the case in small business or third party hosted environments.
>>> Without remote ssh, box is unmanageable.
>>>
>>> Even if you want to do key-based authentication rather than password, you
>>> still need to use password initially to get the key onto the remote box.
>> If you use cloud-init you can specify an initial public key that it
>> inserts against, or even auto enrol it in a central auth system like
>> IPA and hence not ever need a password.
>   So, the major issue(or blocker should we say?) is the virtualized deployments. If there is no solution in sight, maybe last resort is to enable remote root login, possibly in the '%post' install section of the kick-start file.
>
> Does it seem like an appropriate solution?
> ---
> Regards
>    -Prasad
> http://feedmug.com

--
                            Milan Keršláger
                            http://www.pslib.cz/ke/
                            http://www.nti.tul.cz/wiki/Milan.Kerslager



--

Francisco Alonso. 
http://twitter.com/revskills 
PGP: 0xE2E64DCA
--