3
Using signed ssh-keys for users has several benefits:
The user's public key is not distributed to the servers as ~/.ssh/authorized_keys, that saves a lot of pain.
~/.ssh/authorized_keys can not be mis-used by adding other identities to it.
Access control using public keys can be immutable.
The signed key can have a time limit (lease)
The signed key can be ...
2
The only reliable thing your users can do is to verify the server fingerprint.
Password authentication can be intercepted without problems, because passwords are transferred in plaintext only protected by the encrypted ssh channel. This only protects you, when an attacker is reading the network traffic, but in your case you are sending the password to the ...
2
The setting PermitRootLogin no alone does not prevent su - after
logging in as a normal user.
Your statement assumes that any system is configured in such way that all users in this system are allowed to use sudo and that any user is allowed to executed any command via sudo. This may be the case in some systems if administrators don't care about security. ...
2
Could they theoretically use this to somehow ssh into my server or
mysql db?
No.
Certificates contain no private keys. The whole purpose of certificates is to be a public information that everyone can freely load from your server to validate the identity of your server.
The CA bundle is just a convenient way to keep the related certificates together instead ...
2
Did you give them any private keys?
If so, maybe, depending on how your service is set up. You need to immediately revoke the certificates for those keys, and replace the private keys (and certs) with new ones on all your servers.
If not... no. Public keys are, after all, public. Certificates only contain public keys (and some non-key data) and are also ...
2
Put ssh in a VPN tunnel.
Set up a VPN like wireguard, which does not respond to port scans.
Make the sshd on the server listen only on the private IP of the wireguard interface.
Then ssh into the server using wireguards internal ip on the client.
Do the same for other services which don't require public access.
Hackers almost always have a chance to get in. ...
2
If you connect to the ssh server from only a known set of ip addresses, then it's a wise idea to restrict access to only allow incoming connections from these addresses. By blocking incoming connections from all other address, this mitigates attacks that may exploit a potential zero-day vulnerability in ssh, or a configuration error.
You can do this in ...
1
Sure, you use the techniques used by attackers: you hire a botnet to try to bruteforce the password. This doesn't mean that the attempts won't be noticed. It means that the attempts will get lost amongst all the other botnets doing the same. And if detected, you just switch bots. The attacker won't know it's you.
If the attacker has access to the logs, and ...
1
When ProxyJump is used, the jump host can not read data from the forwarded ssh session, because this session should be end to end encrypted.
The problem is, when you are using a malicious server as a jump host, the jump host can redirect your second ssh session to another mitm server. If you are using password authentication, a full mitm can be established.
...
1
Since we cannot enforce the usage of a passphrase server-side, we have to mitigate the risk by education of the users.
Private ssh-key files are sensitive data that could lead to comprimised system if not managed properly. One way to ensure that a pass-phrase is used is a formal policy with a penalty for keys found unencrypted. But it is not hard or ...
Only top voted, non community-wiki answers of a minimum length are eligible
