Habilite el acceso de shell SSH pero deshabilite el acceso SFTP

Solución 1:

Como han mencionado otros, deshabilitar sftp no es suficiente:un usuario con ssh sin restricciones El acceso puede ver cualquier archivo que su cuenta tenga permisos para ver, puede modificar cualquier cosa que tenga permiso para modificar y puede descargar fácilmente cualquier cosa que pueda leer en su propia máquina. La única forma de evitar que hagan esto es restringir su acceso. Tampoco es ideal confiar en .profile para restringir a los usuarios, ya que no es para eso (Editar:como menciona Aleksi en su respuesta, de hecho, es trivial omitir .profile; lo que pasa con .profile es que es por conveniencia, no por seguridad, por lo que no pretende restringir al usuario. Use cosas diseñadas para la seguridad, como las siguientes, para proporcionar seguridad).

Hay dos formas básicas de hacer esto:puede restringirlos a través de permisos de archivo u obligarlos a ejecutar solo su aplicación de consola. La segunda forma es mejor:asigne usuarios que deberían estar restringidos a la aplicación de la consola a un grupo (por ejemplo, customers ); luego, en sshd_config , agregue las siguientes líneas:

Match Group customers
ForceCommand /path/to/app

Lo que esto hace es que todas las conexiones de los usuarios de ese grupo abran la aplicación de la consola; no pueden iniciar nada más, incluido el sftp herramienta de servidor Esto también les impide hacer cualquier otra cosa más con el sistema, y ​​a diferencia de .profile , lo hace utilizando el propio servidor SSH (.profile los restringe en el shell, ForceCommand también evita hacer otras cosas que no impliquen iniciar un shell). También a diferencia de .profile , esto está diseñado como cosa de seguridad; está hecho específicamente para resistir a un usuario malicioso que lo evade.

La alternativa (probablemente inferior) implicaría crear un nuevo usuario para ejecutar la aplicación de la consola. Luego restringiría los directorios de datos a ese usuario, configuraría la aplicación de consola propiedad de ese usuario y configuraría u+s en el programa Este es el setuid un poco; significa que alguien que ejecuta el programa de la consola lo hace con los permisos del propietario del programa. De esa manera, el usuario no tiene acceso a los directorios, solo lo obtiene a través del programa. Sin embargo, probablemente deberías usar ForceCommand , ya que restringe todas acceso a "simplemente ejecute este programa".

Solución 2:

Editar:

En caso de que no sea obvio, la siguiente respuesta no pretende ser una segura método para evitar que cualquier persona con acceso de shell al servidor utilice SFTP. Es solo una respuesta que explica cómo deshabilitarlo de la visibilidad externa. Para una discusión sobre la seguridad a nivel de usuario, consulte las respuestas de @cpast y @Aleksi Torhamo. Si la seguridad es su enfoque, esta respuesta no es la adecuada. Si su enfoque es la simple visibilidad del servicio, entonces esta es su respuesta.

Ahora continuamos con la respuesta original:

Comente la compatibilidad con sftp en sshd_config (y, por supuesto, reinicie sshd ):

#Subsystem sftp /usr/lib/openssh/sftp-server

Solución 3:

No intente hacer esto con .profile ¡porque no proporciona ningún tipo de seguridad y no restringe exactamente nada!

No importa lo que pongas en .profile , ya que puede omitirlo simplemente dando un comando para ejecutar en la línea de comando ssh, así:ssh [email protected] command . Todavía puede obtener acceso de shell normal haciendo ssh -t [email protected] bash .

Deshabilitar el subsistema sftp, como se menciona en otra respuesta, no ayuda en absoluto. Los subsistemas son esencialmente solo alias de los comandos, y aún puede usar sftp normalmente haciendo sftp -s /path/to/sftp-executable [email protected] .

Como han dicho cpast y algunos comentaristas, debe utilizar los mecanismos adecuados para restringir el acceso. Es decir,

• Utilice ForceCommand en sshd_config
• Utilice inicio de sesión sin contraseña y command="..." en .ssh/authorized_keys
• Cambie el shell del usuario a algo que restrinja lo que el usuario puede hacer

Notas:

• command="..." solo se aplica a una clave, por lo que no restringe el inicio de sesión ssh para el usuario que usa una contraseña u otra clave
• Es posible que también desee restringir el reenvío de puertos, etc. (el reenvío de puertos, el reenvío x11, el reenvío de agentes y la asignación de pty son de los que he oído hablar)
  • AllowTcpForwarding etc. en sshd_config
  • no-port-forwarding etc en .ssh/authorized_keys
• Si tiene otros demonios (como FTP) ejecutándose, debe verificar que no dejen entrar al usuario (algunos demonios toman esta decisión en función del shell del usuario, por lo que si cambia eso, es posible que desee volver a hacerlo). mira esto)
• Puedes cambiar el shell del usuario a un script que haga lo que quieras; se ejecuta sin argumentos o como script -c 'command-the-user-wanted-to-run'
• Ambos ForceCommand y command="..." ejecute el comando a través del shell del usuario, para que no funcionen si el shell del usuario está configurado en, por ejemplo. /bin/false o /sbin/nologin

Descargo de responsabilidad:no soy un experto en el tema de ninguna manera, así que puedo decir que el .profile la cosa no es segura, no puedo prometer que no haya algún "te pillé" con los otros métodos que no conozco. Por lo que yo sé, son seguros, pero no sería la primera persona en equivocarse en Internet.