Why directly run ssh or sftp from a UNIX/Linux machine to a mission critical server should be banned
To normal people, ssh and sftp are very secure to run jobs on remote machine or transfer files with remote machine. For people who are responsible for data security in a mission critical data center, and also think ssh and sftp are very secure, then it's very dangerous.
ssh and sftp are very secure by default in the network communication layer, and only in that part.
Directly using ssh or sftp on an UNIX/Linux machine to connect with a mission critical server, such as banking application/database server, can create many security risks, and should be banned for best security.
Let's see what are risks associated with directly run ssh/sftp on UNIX/Linux machine:
When the connection is uing the remote server's account password:
1. The password can be stolen by malicious person on the machine that runs the ssh or sftp, by tools like truss/tusc/strace.
2. The password can be stolen by malicious person on the machine that runs the ssh or sftp, by using a Trojan Horse program to replace the ssh or sftp program.
3. The password can be easily stolen by malicious person on client machine, if the machine has the Oracle dtrace or equivalent program.
When the connection is uing public/private key pair with no pass phrase protection for the private key:
1. Malicious person on the client machine with root privilege is able to copy the private key and use it on other machines to connect with the critical server.
When the connection is uing public/private key pair with pass phrase protection for the private key:
1. The pass phrase can be stolen by malicious person on the machine that runs the ssh or sftp, by tools like truss/tusc/strace. And it can be easily stolen by dtrace on Solaris.
2. The pass phrase can be stolen by malicious person on the machine that runs the ssh or sftp, by using a Trojan Horse program to replace the ssh or sftp program.
Under all these situations, the malicious person is able to get an unrestricted access to the account on the mission critical server, the result definitely won't be any good.
How use ssh to connect to critical server has so many risks, what about directly logon from machine's console? It also has risks: the password can still be stolen by malicious person if that person could run his/her own script as root: password can be stolen by system call tracer and dtrace.
Currently, the only secure way to use ssh or sftp on a UNIX/Linux machine to connect with mission critical server is using our AutoSSH and/or AutoSFTP: only our AutoSSH and AutoSFTP can detect truss/tusc/strace and dtrace attack, and detect Trojan Horse attack. Using AutoSSH and/or AutoSFTP with public/private key pair with pass phrase protection for the private key is the most secure way of connecting with mission critical servers.