It would be a cool to have a `forward agent connection once` option to ssh. when I know I'd have to `git pull` once on the server but don't need the agent forwarding after that.
SSH: Best practices
91–100 of 123 posts
Re: SSH: Best practices
#92Also, move sshd to a random & rarely-used TCP port. Won't help much against a skilled & determined targeted attack, however the "security through obscurity" is not entirely worthless. Using something other than 22 is quite effective at avoiding spray-n-pray scans and exploits. For extra credit, set up port knocking.
Choosing to only bind SSH to a VPN interface is another option. If you can utilize a VPN that incorporates 2FA then that's even better. Projects such as zerotier are going a long way towards making this kind of thing easier to setup.
Then the VPN breaks, and you're out of luck.
Re: SSH: Best practices
#93Weird, where I work we're not allowed to use key auth. They claim it's for PCI since they can't enforce that the keys are passworded/encrypted.
There's nothing in PCI which prevents the use of SSH keys. In no scenario is password auth more secure than key auth.
Re: SSH: Best practices
#94Good advice, except the "remove all system passwords" part. Do not do this. It's a really bad idea. There are occasions where you do need to authenticate using a password, most importantly on the local console - what if your server lost network access?
And that sudo workaround is bad since it requires agent key forwarding, which you shouldn't use for the reasons the author himself noted a few paragraphs up.
Re: SSH: Best practices
#95Weird, where I work we're not allowed to use key auth. They claim it's for PCI since they can't enforce that the keys are passworded/encrypted.
There's nothing in PCI which prevents the use of SSH keys. In no scenario is password auth more secure than key auth.
There is a step where the auditor will observe you entering a correct and an incorrect password to enter the systems. If your org is depending on SSH key passphrases for this step and you get the wrong person in front of the auditor (the one without the passphrase on their key) then you just failed the audit. The more steps you fail, the deeper down the rabbit holes they go with each step. If they see you are not failing, it will be a check-box exercise. Each auditor is a little different of course; but generally speaking, this is true.
Re: SSH: Best practices
#96Earlier quoted context omitted.
Compliance has very little to do with actual security unfortunately...
I've worked with an organisation with the following rules. A user wants to write an SQL query. The user writes it in notepad or whatever, and saves it in a .sql file. The user then will right click on this file they just created, and hit "Scan with McAfee antivirus". If the .sql file they just created comes up clean, they can then open it in SQL Manager and execute it. If they want to then adjust the query, they have…
I facepalmed so hard my forehead hurts
Re: SSH: Best practices
#97Here's a brief guide for setting up SSH with YubiKey as a smartcard which complements this article nicely - https://github.com/drduh/YubiKey-Guide
Looks like I'd need to configure gpg to use it locally first. One of the main uses of smartcards is to use it on other machines (eg: not mine). What's the added benefit of adding one if I'm logging in from my local machine?
For what it's worth, most smartcard applets don't typically store GPG objects but RSA keys (and also usually X.509 certificate objects that go along with them, as well as less-used RSA public key objects).
I use PIV (NIST SP 800-73) compliant smartcards with a PKCS#11 module I wrote (CACKey), it just works with "ssh-add -s /path/to/libcackey.so", then SSH away.
Additionally, there is a fork of OpenSSH called PKIXSSH that adds X.509 certificate support (in addition to the relatively recent, compared to the fork, support for OpenSSH certificates) and then I can authenticate to remote systems using my certificate -- which is helpful when my card is replaced, or if my certificate is revoked the CRLs can be used.
Re: SSH: Best practices
#98Earlier quoted context omitted.
> All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will... ...install a rootkit or botnet client regardless of how you've configured ssh. What does it have anything to do with ssh at all? The attacker could just as easily set up an outgoing VPN-over-TLS in the same way.
The reason that this involves SSH and is in no way related to the malware example you provided is, this is not malware and will never be detected as such. Very few things can actually block this and most of those things are either too expensive, or disabled by most organizations. Also, this is only getting worse with time. More and companies are opening up their firewalls outbound because it makes developers feel war…
[deleted]
Re: SSH: Best practices
#99Earlier quoted context omitted.
> All I have to do is trick your folks into testing a ruby / python / perl / bash script for me that will... ...install a rootkit or botnet client regardless of how you've configured ssh. What does it have anything to do with ssh at all? The attacker could just as easily set up an outgoing VPN-over-TLS in the same way.
The reason that this involves SSH and is in no way related to the malware example you provided is, this is not malware and will never be detected as such. Very few things can actually block this and most of those things are either too expensive, or disabled by most organizations. Also, this is only getting worse with time. More and companies are opening up their firewalls outbound because it makes developers feel war…
"I am just dropping a key on your machine" - from my point of view, it does not matter whether you're dropping an executable, an SSH key, or Aunt Matilda: you already have the user executing arbitrary code (your distinction between "here, pipe this code into bash, it will execute" and "here, pipe this code into bash, it will save itself to disk and then execute" is pure handwaving).
(you are likewise assuming there are multiplexed connections, which is a great leap - these are off by default)
What you have demonstrated is the simplest possible botnet technique, using SSH as the transport and social engineering as the vector; for some reason, you consider it groundbreaking. Well, it would have been - in 2000.
Re: SSH: Best practices
#100Earlier quoted context omitted.
Public keys being exposed isn't something I think needs to be mitigated. That's the whole point, they're public.
Exposing shared public keys creates an information leak; it allows attackers to probe for valid and usable username/key combinations on your servers (and thereby discover valid usernames). This may be a trivial information leak or it may be one that you consider important; it depends on the situation. Not sharing public keys between different services and contexts (eg not using your Github keys for anything else) mit…
I think if you consider leaking usernames to be an important risk, there is probably some other problem. Your username can probably be easily guessed based on your email address or first and last name anyway.
My point is you are better off designing things assuming that usernames and public keys are public information. That doesn't mean you have to go publish them on your website, but you also don't need to worry about mitigating it if someone else does.