How to permit selective SSH access?

Reply-Via-Newsgroup Thanks wrote:
> Jean-David Beyer wrote:
>
>> I do it with iptables.
>>
>> I have iptables set up to deny access from anyone to anything.
>>
>> Then I selectively allow those IP addresses I care about to connect to
>> those ports I want.
>>
>> So for ssh, I have entries like:
>>
>> # For sshd daemon.
>> for sip in $[list of good guys for ssh]; do
>> $IPT -A IN_FIREWALL -p tcp -m state --state NEW \
>> -s $sip --dport ssh -j ACCEPT
>> done
>>
>>
>
> Yep - I like this too - I'll play on my devbox first before trying it on
> one of our remote boxes...
>
> Much appreciated... though since our servers sit behind a secondary
> (hardware based) firewall, I don't have iptables enabled and had hoped
> instead to depend on ssh configuration on an out of the box ret hat 9
> installation...
>
> I'll play with both, but I have to admit, I do like the iptables example
> you have above...
>
> Can I just confirm, $IPT is the full path name to iptables, true?
>
Yes. But you better know some more:

################################################## ########################
# #
# INITIALIZATION #
# #
################################################## ########################

IPT=/sbin/iptables
if [ ! -x $IPT ]; then
echo "firewall: can't execute \$IPTABLES"
exit 1
fi

################################################## ########################
# #
# Clear the existing firewall rules #
# #
################################################## ########################
# #
$IPT -P INPUT DROP # Set default policy to DROP
$IPT -P OUTPUT DROP # Set default policy to DROP
$IPT -P FORWARD DROP # Set default policy to DROP
$IPT -F # Flush all chains
$IPT -X # Delete all userchains
# #
for table in filter nat mangle; do
$IPT -t $table -F # Delete the table's rules
$IPT -t $table -X # Delete the table's chains
$IPT -t $table -Z # Zero the table's counters
done
# #
################################################## #########################



################################################## ########################
# #
# Main Firewall Rules #
#
################################################## ########################
#
# The explicit drops here (-j DROP, -j BAD_INPUT, and -j BAD_OUTPUT) #
# should be unnecessary, but are included here just in case an error #
# in the other chains lets something fall through. #
# #
$IPT -A FORWARD -j SHUN
$IPT -A FORWARD -i $EXTDEV0 -j IN_NETWORK
$IPT -A FORWARD -i $INTDEV0 -j OUT_NETWORK
$IPT -A FORWARD -i $INTDEV1 -j OUT_NETWORK
$IPT -A FORWARD -j LOG --log-prefix "IPT FORWARD: " $LOGOPT
$IPT -A FORWARD -j DROP
# #
$IPT -A INPUT -j SHUN
$IPT -A INPUT -i lo -j ACCEPT
$IPT -A INPUT -j IN_IP_CHECK
$IPT -A INPUT -j IN_FIREWALL
$IPT -A INPUT -j BAD_INPUT
# #
$IPT -A OUTPUT -j SHUN
$IPT -A OUTPUT -o lo -j ACCEPT
$IPT -A OUTPUT -j OUT_IP_CHECK
$IPT -A OUTPUT -j OUT_FIREWALL
$IPT -A OUTPUT -j BAD_OUTPUT
# #
################################################## ########################

################################################## ########################
# #
# INPUT TABLE CHAINS. #
# #
################################################## ########################
# #
$IPT -N IN_FIREWALL
$IPT -A IN_FIREWALL -p icmp -j IN_F_ICMP
$IPT -A IN_FIREWALL -p tcp -j TCP_FLAGS
$IPT -A IN_FIREWALL -p tcp --syn -j SYN_FLOOD
$IPT -A IN_FIREWALL -p tcp -m state --state ESTABLISHED,RELATED \
-j ACCEPT
$IPT -A IN_FIREWALL -p udp -m state --state ESTABLISHED,RELATED \
-j ACCEPT


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 07:55:00 up 3 days, 16:54, 6 users, load average: 4.12, 4.08, 4.08

In linux.redhat.misc Tim Haynes <usenet-20040604@stirfried.vegetable.org.uk> wrote:
> if it's a bad packet designed to exploit a buffer-overrun or something, do

You are confused - packets do not exploit applications. Now if there
were a bug in your TC PROTOCOL (which a packet or packet sequence could
exploit), then the whole world would know about it, since the whole
world uses TCP.

But applications aren't vulnerable to "packets". Leave your tcpwrappers
be - it's fine.

> I trust the bits of the user-space process that deal with tcp-wrappers not
> to be susceptible?

Eh? Inetd simply starts a daemon to cope with the port incoming when
it hears somebody coming knocking - or not if the source IP is banned.
Tcpwrappers may make the decision instead of inetd if inetd starts the
daemon under tcpwrappers control.


Peter

On Thu, 03 Jun 2004 10:00:48 -0700, Reply-Via-Newsgroup Thanks wrote:

>
> Folks,
>
> I have tried reading the 'man' page on ssh and attempted to configure
>
> /etc/ssh/hosts.equiv
> .shosts
>
> to only permit access to the server from a select number of IP addresses
> however it doesn't work (meaning access is permitted from all IP
> addresses regardless of origin).
>
> I just placed the IP addresses in the above files - Can someone provide
> me with some examples or suggest where I am going wrong?
>
> Please reply via the newsgroup so all can learn,
>
> Thanks in advance,
> Randell D.

Use RSA authentication. Place the public keys from the machines that you
want to allow access from into an authorized_keys files. You can either
use a common authorized_keys file in /etc/ssh or you can do it on an per
account basis by putting them in ~/.ssh/authorized_keys.

in /etc/ssh/sshd_config

AuthorizedKeysFile /etc/ssh/authorized_keys

Then disable password authentication

PasswordAuthentication no

The authorized machines will be able to connect, other machines won't.