Set B, in isolamento non consente le comunicazioni ssh. Permette semplicemente che una connessione consentita da altre regole sia continuata o (soggetta a determinate combinazioni come per H.323 e FTP) per stabilire nuove connessioni tra gli indirizzi IP che hanno una voce esistente nella tabella conntrack.
Il problema con Set A è che non è statico - un utente malintenzionato potrebbe creare una connessione client a qualsiasi porta sul server fintanto che il client usa la porta 22. Per risolvere questo problema è necessario un firewall stateful - cioè uno che prende in considerazione la direzione della connessione. Quindi è più comune vedere qualcosa del tipo:
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
...
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
iptables -A OUTPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
Mettere ESTABLISHED, RELATED significa innanzitutto che l'intero set di regole deve essere analizzato solo una volta per connessione - i pacchetti successivi sono abbinati alle prime 2 regole. Questo può avere un grande impatto sulla latenza con un set di regole complesso.
Il rovescio della medaglia dell'utilizzo del firealling di stato è che consuma risorse sul server - quando la tabella conntrack si riempie, il firewall inizierà dropping connections . OTOH, il modulo stateful consente una gestione della domanda più complessa, in genere limitando la velocità delle connessioni.
with certificate-authentication-only
Davvero? Mentre ci sono versioni di ssh usando i certificati per la gestione delle chiavi è un caso molto insolito. Intendi coppie di chiavi?
None of both sets is superior in general
...
Which of both sets is more restrictive
Se nessuno dei due è superiore, come si può essere migliori?
Per un firewall host, dovresti usare il firewall stateful - per prevenire il bypass descritto in precedenza.