The question comes up because even in the support database it is advised to set AllowRootLogin to NO. So…why it is set to yes as default (which is then insecure if I well understood). And why is ssh not deactivated by default, so user have to opt in, if they do not use it, it is already set to save defaults. The same is for X11 forwarding that I would have expected be on default to no. Is there a logic that escapes me? I would like also to restrict the usage of “su” as mentioned in the support database mentioned. But the link is going to a non existing page. How can I restrict the use of “su” of ssh? I want on this machine the ssh functions securely disabled (as bulletproof possible). Thank you. I am writing that on my 11.1 evergreen. But I do not think that this policy has changed as the support database refers as well to 11.4. So in any case and any version, the question for me stays.
In 12.1 and 11.4 the ssh service was disabled by default during install. AllowRootLogin and X11Forwarding are not inherently insecure, just less secure settings. It’s not all black and white. There may be a case for disabling them in the OOTB config since experienced users know what to do to enable them.
I would agree. Once one checks, one discovers maybe not black and white but unpleasantly unexpected colors. I will check whether there is a openFATE thing about it. Not that all users have issues. But users who do not use it and do not want to use it should be on the safest possible side, IMO. As you stated: whatever OP that wants to use it knows how to activate it and the others can come here to ask. Thanks for answering.
On 2011-12-05 21:16, stakanov wrote:
>
> The question comes up because even in the support ‘database’
> (http://en.opensuse.org/SDB:Configure_openSSH#Limit_by_Hosts) it is
> advised to set AllowRootLogin to NO. So…why it is set to yes as
> default (which is then insecure if I well understood).
You could ask in the security mail list.
> And why is ssh
> not deactivated by default, so user have to opt in, if they do not use
> it, it is already set to save defaults.
This you can search in the mail lists archive, it was decided 1…3 years ago.
> Thank you. I would like also to restrikt the usage of “su”
> as mentioned in the support dabase mentioned. But the link is going to a
> non existing page.
Ask the “wikipedists”.
> How can I restrict the use of “su” of ssh?
I don’t understand that sentence.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
At the end of the day it’s up to you to determine your best practice for the machines you manage and apply that policy as no distro will conform exactly.
Sorry that was actually very cryptic. So:
Quote from the article (link as of above) SDB as follows:
PermitRootLogin can be set to yes or no. The default is yes. It is wise to change it to no, since every *NIX system has the user root and this user is almighty, so it is the ideal user to use to break into a system. You can still gain Root privileges by typing su or sudo after logging in as a normal user. You might even want to Restrict the usage of su.
Where the link going to “restric the usage” is not followed by a page yet. So I asked myself how you would do this.
Sorry for having been “cryptic”. Thank you for your reply.
Yes I understand. If you read the quote of the SDB of openSUSE one is to induced to belief that this is “best practice”. So for me it is paradox that we advice in a document “it is wise to change to no” but that we leave the default … to yes? This is the point of “surprise”.
You apply your Unix knowledge and ask yourself again. One way would be to remove the world rx permissions of /bin/su and change the group to that of a trusted group of users.
There is no best practice for every situation. If you believe a document that says there is one absolute best practice, I have a bridge to sell you.
Ken_yap, I didn’t know, you are ROMANTIC 
Seriously. I am fully in building up my “Unix knowledge” (thank you for your anticipated confidence) but the "permission settings are still to some extend a terrible black whole. If you have a tip for a good down to earth fast explanation on the web or in a book, I will be thankful for all hints. I have looked here and there but I do not think it is explained “from the scratch” - which in my case means “do not take anything for granted”. It is circular, so remember that I am the hamster in the wheel - I am running, I can assure you. But still no way to take a step sidewards. Still in the spinning phase. Thank you.
I dissent, my argument is about coherence in the overall documentation and implementation. To say it with the critics of Linux Torvaldsabout the Gnome desktop (purportedly "to switch something ON to be able to switch it OFF? - I did not find the original quote), this was just an aspect about overall coherent settings and documentation.
Which bridge is it? I do not trust these things any more. A certain “Toto” sold me the “Fontana di Trevi” time ago. It was a rip off!! 
If you believe that all the documentation is coherent, given that they are written by different volunteers at different times in different situations, I still have a bridge to sell you.
Thank you, very kind. I saw this book time ago, thought I downloaded it, but for some reason it is not in my collection.
On 12/05/2011 09:16 PM, stakanov wrote:
> Why is the default ssh setting set to allow root login?
>
> And why is ssh not deactivated by default
>
> The same is for X11 forwarding
>
>Is there a logic that escapes me?
i do not have a sure reason for those except to recall the history of
SUSE/SuSE/S.u.S.E which from the beginning was interested in making
great server software for businesses (who were willing to BUY services
etc)…
so, instead of thinking about the central core of these forums and the
mass of desktop user, think instead of trained Linux Administrators
loading SuSE 6.x into the hottest server of the day…and doing it 5 to
15 times in one day…into servers in a rack mount which may only
occasionally have a monitor attached, or may never have a monitor
attached…
in those old days (before us desktop using newcomers) all of those
defaults made sense: load it, give it a good strong root pass, connect
to it via ssh from the administrators console (in another room, where is
quiet (and you can smoke), log in as root, set it up and move on…done!
(who wants to have to enable all of that stuff that most folks are
gonna need enabled!?!)
so, times change and the old ways do not make sense to us here–becuase
we don’t really need all that stuff…but, in fact the folks who still
sell services to support our big sister (SUSE Linux Enterprise Server,
etc) know the paying customers still like all that stuff to default on,
i guess!!
otoh, Carlos spoke of a decision to default off on SSH a few years
back…but, i’d bet it has not been changed in SLES 10 or 11, and
someone somewhere working on SLES 12 has a note to him/herself to BE
SURE and when working the openSUSE code to make it ready for the
enterprise to REMEMBER to default ON both root log in and SSH…that is
a no brainer for enterprise systems…
ymmv
–
DD
openSUSE®, the “German Engineered Automobiles” of operating systems!
Ken_yap real estate lol! It’s O.K. I do not think all documentation is coherent. It was to understand why the documentation said to change default settings. As it has been recently set up and proofread, I would have expected that the authors still agree on this point, they could have changed it. Don’t worry, I will not buy that bridge, I still have to find a place for that huge fountain!
Makes sense to me.
I find that the putting AllowRootLogin inside a Match block for a subnet of trusted servers is useful as it allows you to rsync stuff from one server to another.
Now I wish I could have PubkeyAuthentication for external IPs and UsePAM for internal IPs using Match, but that’s not possible AFAIK.
BTW, if some less technical user come by, I did stumble upon this article on SSH. Just if anybody should be interested in light reading. Found it very linear.
Stupid question (which will engender an intelligent answer as I hope). Why would you prefer to make use of PAM for internal? Because of easier user management or because of the …I don’t know, overhead of calculating the key access? PubkeyAuthentication wouldn’t it combine practicability of use and also safety?