Remediations involving sshd_config

Shawn Wells shawn at redhat.com
Sat Oct 5 03:15:14 UTC 2013


On 10/4/13 3:52 AM, Rui Pedro Bernardino wrote:
> Hi,
>
> I have exactly the same results but that’s not the point. This is what I get on a system without a ‘Banner’ but with a 'Match' group:
> 	[root at seis64 ~]# ssh localhost
> 	root at localhost's password:
> 	[root at seis64 ~]# sshd_enable_warning_banner.sh
> 	[root at seis64 ~]# /etc/init.d/sshd restart
> 	Stopping sshd:                                             [  OK  ]
> 	Starting sshd:                                             [  OK  ]
> 	[root at seis64 ~]# ssh localhost
> 	root at localhost's password:
>
> Still no banner.
>
> This is because the ‘Banner’ was appended to the end of sshd_config and got ‘absorved’ by the Match rules (that use anything following 'Match' until EOF or another 'Match'):
> 	[root at seis64 ~]# tail -5 /etc/ssh/sshd_config
> 	# Rules for sftponly group
> 	Match group sftponly
> 	X11Forwarding no
> 	AllowTcpForwarding no
> 	Banner /etc/issue
>
> This applies to all SSG's sshd_config fixes. Note not all configuration primitives are acceptable on the “Match” blocks, meaning starting sshd will fail.
>
> Bottom line, new primitives must be inserted*before*  Match blocks.

Ah, yes, I see what you're talking about now. How's this?

> # Attempt to adjust value, should string be present
> grep -q ^PermitEmptyPasswords /etc/ssh/sshd_config && \
>   sed -i "s/PermitEmptyPasswords.*/PermitEmptyPasswords no/g" 
> /etc/ssh/sshd_config
> if ! [ $? -eq 0 ]; then
>         # string not present, check for Match stanza
>         grep -q ^Match /etc/ssh/sshd_config && \
>                 sed '0,/.*Match.*/s/.*Match*./PermitEmptyPasswords 
> no\n&/' /etc/ssh/sshd_config
>         if ! [ $? -eq 0 ]; then
>                 # Match stanza not present, add to bottom of 
> /etc/ssh/sshd_config
>                 echo "PermitEmptyPasswords no" >> /etc/ssh/sshd_config
>         fi
> fi

.... there has to be some easier / less fugly way through sed or awk... 
anyone?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20131004/709a8687/attachment.html>


More information about the scap-security-guide mailing list