On Wed, Mar 20, 2024 at 1:32 AM <to...@tuxteam.de> wrote: > > On Wed, Mar 20, 2024 at 04:22:29AM +0800, jeremy ardley wrote: > > > A 'safer' implementation will not even expose an ssh port. Instead there > > will be a certificate based VPN where you first need a certificate to > > connect and then you need a separate certificate to log in as root. A > > further enhancement of security is to use 2-factor authentication - which is > > supported in sshd via pam. > > How will a "VPN" with a "certificate" (whatever that means in this context) > be more secure than a SSH (assuming key pair authentication, not password)?
This may be more theoretical, but... IPSec uses Encrypt-then-Authenticate (EtA), which is provably secure under random models. In fact, I believe IPSec is IND-CCA2 secure (Ciphertext Indistinguishability), which is a strong notion of security. SSH uses Encrypt-and-Authenticate (E&A), which is provably insecure. The SSH protocol leaks information because of the order of operations of encryption and authentication. As far as the certificate, I suspect it alludes to public key. Both IPSec and SSH can use public key cryptography (as opposed to passwords), so they are about equally secure (compared to passwords). IPSec is actually a little stronger with provable security properties because it uses HKDF after key agreement to derive bulk encryption keys. And I believe IPSec performs a key conformation step, which helps with the security proofs. The IPSec standard is maintained by Hugo Krawczyk and associates. Hugo is a world class cryptographer. That's why the IPSec protocol does not have the theoretical defects of SSH (or TLS). Krawczyk is also the author of The Order of Encryption and Authentication for Protecting Communications, <http://www.iacr.org/archive/crypto2001/21390309.pdf>. It is a very good paper. > They are doing the same dance (key exchange, key pair validation, session > key establishment) -- the "certificate" part is just a step further (and, > BTW, SSH can do that, too), which just eases key management (at the expense > of security: you have but one more moving part). > > The "port" thing stays the same: the VPN server uses a TCP connection, too. > > Moving the port to a non-standard number, using fail2ban, firewall knocking > and those things don't increase security *directly* -- they just remove > noise from the logs, which eases the admin's task and thus increase security > indirectly. > > There's no magic. Jeff
