Expand all |
Post comment
Analyzing Malicious SSH Login Attempts
2006-11-06
Anonymous (1 replies)
Anonymous (1 replies)
|
Analyzing Malicious SSH Login Attempts
Expand all |
Post comment
Analyzing Malicious SSH Login Attempts
2006-11-06 Anonymous (1 replies) |
|
|
Privacy Statement |
I think a real powerful setup would be combining relocating the sshd daemon to a higher port, in addition to using port knocking. If a list of passwords or phrases could be kept in the config file or securely in a another file, then even throwaway passwords could be used, say at public terminals or school terminals where the possibility of a keystroke logger existed. You use a password via port knocking, then that password is automatically discarded and locked out by the port knocking daemon or the config file, and it awaits the next password on the list. There would be no danger of having your password sniffed by a keystroke logger or over a wireless connection since it only works once to grant access once, then it would theoretically move to the next password.
What I'm doing to avoid running the sshd daemon is logging in and then keeping a shell open and logged on, monitoring the syslog and apache logs long term. This allows me to stop the sshd daemon, and then the only time necessitating a visit to the remote box to restart sshd so I can log on again is if I get accidently logged out from each of the several terminal windows I keep open to monitor the remote box. I've heard keeping a shell open and logged on as root is insecure, but I don't understand why and the risk appears to me at least less than keeping sshd running. I've tried logging on as a regular user then su'ing to root, but when I need to run an X app with root privileges, the permissions don't carry and I get a denied message when trying to start an X app after su'ing the regular login. I'm using a public/private key for a regular user, but am falling back on password authentication for root when I need to log in with the -X flag as root.
[ reply ]
Link to this comment: http://www.securityfocus.com/comments/infocus/1876/679#679