61–70 of 128 posts
What bit me recently was trying to set up non interactive password protected ssh keys. (The use case is wrapping the ssh functionality inside another program.) Turns out, if you want to script the use of an ssh key that requires a decryption password, you can’t do it without ssh-agent (which isn’t really the best solution for a multi user program).
Earlier quoted context omitted.
It’s covered under footnote #1: > First, some vendors make it difficult to associate an SSH key with a user. Then, many vendors do not support certificate-based authentication, making it difficult to scale. Finally, interactions between public-key authentication and finer-grained authorization methods like TACACS+ and Radius are still uncharted territory Keys (with/without certs) are the best route, but not always po…
Honest question, unless it's mandated by your employer, or you don't personally care, why would you ever choose to use a service that doesn't offer that?
Earlier quoted context omitted.
You may be in a position where you must employ and interact with networked equipment that does not support pubkey authentication.
Public key authentication is actually a Must Implement for SSHv2. Since SSHv1 is long obsolete, any gear that doesn't have pubkey doesn't actually have a de jure SSH implementation. "All implementations MUST support this method"
What bit me recently was trying to set up non interactive password protected ssh keys. (The use case is wrapping the ssh functionality inside another program.) Turns out, if you want to script the use of an ssh key that requires a decryption password, you can’t do it without ssh-agent (which isn’t really the best solution for a multi user program).
Something like https://matrixzj.github.io/documentations/idm_decrypt_ssh_pr... (then ssh -i decrypted_key) should work and avoid ssh-agent
Earlier quoted context omitted.
Overly contrived examples are the hallmark of software zealots. I knew to stop reading after "its more correct variant".
Ignoring failures because they're moderately unlikely is the hallmark of a bad developer. It's an extremely common attitude unfortunately - you can see it all over the place, especially in the Unix/Linux world e.g. * People thinking sysvinit (janky Bash scripts) are fine. * 50% of Linux software doesn't work if you have spaces in your path. GNU Make explicitly doesn't support that. * Over use of text based APIs, e.g.…
> Ignoring failures because they're moderately unlikely is the hallmark of a bad developer.
Totally agree.
I believe privileged access management is the proper way to manage access to a password protected systems. It is basically a terminal server, proxy, bastion or anything similar. You log in there with federated identity (for example AD) and it logs you in into target system with some shared or temporary user. Usually it also records session and does other security/compliance related things. Examples are Delinea (forme…
Used Powerbroker and cyberark for a long time and while they're good at stated purpose the integration with more flexible and modern auth systems has had a lot of friction.
The particular regulatory area I work in is also just a non-starter for federated AAA from outside the regulated systems which colors my opinion though.
Combined with command restrictions in openssh and sudo etc you end up with several wholly disjoint attack surfaces, decent logging, and granular user restrictions.
Earlier quoted context omitted.
Public key authentication is actually a Must Implement for SSHv2. Since SSHv1 is long obsolete, any gear that doesn't have pubkey doesn't actually have a de jure SSH implementation. "All implementations MUST support this method"
That doesn't mean it's always easy to install and manage keys. For example, the author of the passh tool recommended by this post somehow managed to come away with the impression that OpenWRT's ssh server only supports password authentication.
Used 'expect' like 20 years ago...
I was waiting for the article to mention why the author chose not to employ that option. Though the author mentions in passing that one solution is brittle because it requires parsing output, I don't see why that's a problem. It's exactly what 'expects was designed to do.
What it does do well:
1. can validate a key signature issue
2. firewall port-knocking (extra http ports interleaved with instant ban ports)
3. ssh over https setup
4. IDS tripwire Morse-code knocking
5. reverse-proxy configuration for trusted zone ingress
This approach helps solve several issues:
i. distributed firewall probes or nuisance traffic
ii. brute force attempts or nuisance traffic
iii. obscures security posture identification (what got an IP blacklisted might have occurred several minutes ago)
Indeed, I also Good luck =)
Earlier quoted context omitted.
Why not use something like Kerberos (for example) and have the proper identity also on the system where you log in to via SSH?
Kerberos is a) relatively complex to set up properly if its not a Windows in AD b) an SSO, not federated ID. Which means reasking MFA is not possible.