Hacker News Reader

Comment by mfenniak | Hacker News Reader

A decent approach to doing this in the Windows world would be to use PsExec.exe (http://technet.microsoft.com/en-ca/sysinternals/bb897553.asp...).

View on HN

Ah, PsExec. Yes, I reviewed that. However, the issue with PsExec has to do with credentials. If you don't bother with the user/password, it impersonates your account, which has certain restrictions[1]. That was not feasible due to most interesting things living on network drives. If you do bother with the username/password, you have to store those somewhere (remember, automated system). So now instead of running psexec directly, you have to have a tool that grabs the password file, hopefully decrypts it, then runs psexec.

Also, iirc, using the psexec interface from Linux in a Linux->Windows connection does not work (a wrinkle in the original story is that it was a Linux->Windows connection).

[1] http://windowsitpro.com/systems-management/psexec

What, in practice, is the difference between creating an account and SSH key that gives passwordless sudo (or other authorization) and creating an account and password that gives appropriate authorization?

You have to possess the SSH key, but any keylogger could record the password? Passwords can be guessed?

If you have the ability to install a keylogger that can hijack a user session, what prevents you from capturing the SSH key of the user?

I can generate a unique pair of ssh keys for each client that has to remote into a system; I have to have a consistent password for the same user across all systems (assuming integrated login).

Supposing that a keyfile is copied, the multiplicity of ssh files limits the damage.

Reply on news.ycombinator.com