81–90 of 99 posts
Earlier quoted context omitted.
These are good asks. After xz I worry a little about how many eggs are in the ssh basket.
xz? regreSSHion should make you lose sleep! https://arstechnica.com/security/2024/07/regresshion-vulnera...
Earlier quoted context omitted.
If you use container tabs in Firefox, you can also configure proxies on a per-container basis! In case that’s useful to other people besides me.
In case anyone besides me had never heard of this feature: https://support.mozilla.org/en-US/kb/how-use-firefox-contain...
Exposing SSH to the world really bothers me. Personally I firewall to my own IP when connecting to EC2 instances, it's a pain but I don't feel comfortable knowing there may be zero days out there, plus I don't want my CPU cycles wasted by script kiddies. It seems like there should be a better solution - something like port-knocking but done properly.
Earlier quoted context omitted.
I must admit my rsync experience is limited. I do not know the behaviors and flags very deeply. It's on my list though, as it's surely another one of those foundational linux tools. I know it is even faster than cp on the same host for some situations.
rsync is the tar of network transfers. It is extremely useful, but has too many options, so one ends up memorizing a few use cases and carefully sticking to them. I still have PTSD from the time I played with the options and made the mistake of swapping source and destination, where the destination was a blank disk.
Time a 'tar | nc' sometime to a remove server, it'll blow away the rsync time.
Earlier quoted context omitted.
rsync is the tar of network transfers. It is extremely useful, but has too many options, so one ends up memorizing a few use cases and carefully sticking to them. I still have PTSD from the time I played with the options and made the mistake of swapping source and destination, where the destination was a blank disk.
haha, you say rsync is the tar of network transfers, but have you ever considered using tar for network transfers? Time a 'tar | nc' sometime to a remove server, it'll blow away the rsync time.
SSH is great but rapidly becomes less so once companies decide to put their servers behind some times cascaded SSH gateways, so you need to know which magic invocation of jump hosts to put in to have your connection go through anyway.
You can simplify this for hosts you talk to regularly by configuring them in your .ssh/config file(s), as shown in https://wiki.gentoo.org/wiki/SSH_jump_host A bit of faf for one-off or infrequent connections, but a great time saver for regular interactive use.
I think Amazon does a good job here. Default SSH is with certificates, passwords not used. I like that. Hard to brute force a certificates. In the old flat 10.X.X.X network amazon days - your new hosts were absolutely hammered when being brought up. There must have been folks on the amazon network itself just portscanning like crazy.
> Hard to brute force a certificates. I see this mentioned a lot. But is it any harder to brute force a 2048 certificate than a 2048 bit password? (Note: A 2048 bit password with base64 character set is 342 characters long) Don't get me wrong, there are many advantages to certificates (server doesn't learn the secret, easier to enforce strong secrets, ability to issue centrally, ...) but there is nothing magically di…
The "SSH has a wide attack surface as seen by RCE ..." is a bit dishonest IMO. How s any VPN more secure?
If you want configure SSH to be pubkey only and hand over Yubikey to your users.
I wonder: in all the recent data leaks leaking billions of users data where attackers were inside company's networks (and not just on online facing servers), was it through SSH holes that these attack too place? Or are we talking about a corporate culture of Windows+VPN?
Earlier quoted context omitted.
> Hard to brute force a certificates. I see this mentioned a lot. But is it any harder to brute force a 2048 certificate than a 2048 bit password? (Note: A 2048 bit password with base64 character set is 342 characters long) Don't get me wrong, there are many advantages to certificates (server doesn't learn the secret, easier to enforce strong secrets, ability to issue centrally, ...) but there is nothing magically di…
At least in government there often were weird limits on password length (ie, 8, 40, 72 ) or in tooling around passwords. Certificates seem to force allow things like 2048 bits. Didn't Red Hat have a default at 8 for a while??
Drives me nuts that somewhere along the devops journey people decided that SSHing into a private server used for internal tools is an antiquated and outrageous thing to expect. People for some reason are actually excited about the prospect -- "we're gonna make it so you never have to SSH!". Little do they know that I like SSH. A lot more than I like clicking on the AWS console. And then somehow we're expected to debu…