¿Cómo usar SFTP en un sistema que requiere sudo para acceso raíz y autenticación basada en clave ssh?

Quiero poder usar SFTP para editar archivos que requieren permisos de root.

Estoy usando la autenticación basada en la clave SSH: clave rsa en la tarjeta inteligente.

Si el sistema requiere que sudo ejecute comandos de nivel raíz, ¿cómo puedo solucionar esto?

¿Puedo crear una forma de omitir sudo solo para SFTP?

¿Hay alguna manera de mantener la autenticación de sudo y clave?

Estoy usando Windows para conectarme a Ubuntu. Necesito esto para trabajar con Mac conectándose a Ubuntu también.

Entiendo cómo hacer SSH Tunneling para administrar los servicios del sistema. Actualmente, uso el inicio de sesión de usuario root directamente, pero el inicio de sesión con contraseña está deshabilitado. No entendía cómo usar sudo y SFTP al mismo tiempo. Parece ser una buena práctica exigir el inicio de sesión como usuario no root y luego requerir el uso de sudo, ya que los registros registrarán a quién se le otorgaron privilegios escalados para cada comando.

¿Debería preocuparme por esto cuando uso la autenticación basada en Clave o es una diferencia trivial en seguridad / registro? Parece que la autenticación basada en clave registra el número de serie del usuario en los registros, y puede tener varias claves para que el usuario raíz identifique a cada usuario. Este parece ser el mismo efecto que usar sudo para mí. ¿Me equivoco?

SFTP es un comando de acceso a las operaciones de archivos, con las restricciones de la cuenta que utiliza. Debe usar ssh para realizar más operaciones administrativas, haciendo imposible el uso de sudo y SFTP al mismo tiempo. Si necesita acceso a todo el disco sin restricciones utilizando SFTP, hágalo utilizando la cuenta raíz. De todos modos, puede iniciar sesión con root en sftp y ssh al mismo tiempo, por supuesto, usando dos sesiones diferentes.

Las claves de seguridad mejoran la seguridad y facilitan el registro, ya que no requieren entrada de teclado. Solo ayuda a iniciar sesión, puede tener varias contraseñas para cada usuario de la cuenta y tener el mismo efecto.

EDITAR: Olvidé: puede crear otra cuenta con el mismo efecto que la raíz si asigna la identificación de usuario a 0, pero no tiene ningún sentido, siendo peligroso de la misma manera. Podría ofuscarme si alguien intenta iniciar sesión como root, pero aparte de eso, no tiene mucho sentido.

Llamar al subsistema con sudo funcionó para mí.

A un host Ubuntu, por ejemplo:

sftp -s "sudo /usr/lib/openssh/sftp-server" targethost.fqdn

Más allá de lo que @MartinVonWittich sugirió en los comentarios anteriores , puede configurar un par de claves SSH dedicadas solo para esta actividad y agregarlas al /root/.ssh/authorized_keysarchivo del usuario raíz, limitando su alcance a un solo comando.

# User backup's $HOME/.ssh/authorized_keys file
command="/usr/libexec/openssh/sftp-server" ssh-dss AAAAC8ghi9ldw== backup@host

Esto permitiría otro sistema con la clave correspondiente a este par para SFTP en este sistema como root. Aún tendría un registro de esta conexión en sus archivos syslogy / o secure.logarchivos (suponiendo que su distribución proporcione este nivel de registro).

NOTA: Quien acceda al servidor en este método tendría acceso a cartes blanche, así que úselo sabiamente. Mejor aún continúe leyendo y combine esta capacidad con chroot y acceso de solo lectura, para construir restricciones más estrictas y acceso dirigido a ubicaciones específicas como root.

chroot y readonly

La otra técnica que podría explotar aquí sería limitar la conexión SFTP para que se agrupara en ubicaciones específicas como raíz, según la clave SSH utilizada. Consulte mi respuesta a esta pregunta y respuesta de U&L titulada: " Restrinja la copia de seguridad sin contraseña con SFTP " para obtener más detalles.

También puede controlar a sftp-servertravés de sus interruptores -Ry -d.

 -d start_directory
         specifies an alternate starting directory for users.  The pathname 
         may contain the following tokens that are expanded at runtime: %%
         is replaced by a literal '%', %h is replaced by the home directory
         of the user being authenticated, and %u is replaced by the user‐
         name of that user.  The default is to use the user's home 
         directory.  This option is useful in conjunction with the 
         sshd_config(5) ChrootDirectory option.

 -R      Places this instance of sftp-server into a read-only mode.  
         Attempts to open files for writing, as well as other operations 
         that change the state of the filesystem, will be denied.

El enfoque simple que seguí fue simplemente sftp y colocar los archivos en un área de escenario ( mkdirnuevo directorio donde tiene permisos en el servidor) y luego ssh nuevamente para mover los archivos desde allí al destino con sudo cpo sudo mv.

Tuve un problema similar en el sentido de que quería usar vimdiff para editar archivos de configuración en un grupo de hosts en su mayoría similares, con cssh y sudo y es posible que pueda adaptar mi solución a su flujo de trabajo.

sudoedit (parte de sudo) le permite usar cualquier editor como usuario normal para editar un archivo para el que no tiene permiso de escritura y puede especificar el editor con una variable de entorno. sudoedit copia los archivos, invoca al editor con los nombres de las copias y espera a que el editor salga, luego copia la copia modificada de nuevo a donde estaba. así que creé un 'editor' que no edita, solo anota el archivo para su uso posterior y espera y un contenedor alrededor de vimdiff que usa ese marcador.

el primer archivo es ~ / .bin / redit

#!/usr/bin/perl -w
use strict;
use warnings;
use Sys::Hostname;
my $file = $ENV{HOME}.'/.var/redit/'.hostname();
sub cmkdir($){
    my $_=shift;
    mkdir $_ unless -d $_;
}
cmkdir $ENV{HOME}.'/.var/';
cmkdir $ENV{HOME}.'/.var/redit/';
foreach (@ARGV){
    my $fh;
    open $fh, '>', $file.'na' or warn;
    print {$fh} $_;
    close $fh;
    symlink $_, $file or die;
    print;
    <STDIN>;
    unlink $file or die;
    unlink $file.'na' or die;
}

el segundo es ~ / .bin / redit1

#!/usr/bin/perl -w
use strict;
use warnings;
use Sys::Hostname;
my $h=hostname();
@ARGV=qw(host1 host2 host3 host4) unless @ARGV;
print join " ", qw(gvimdiff), $ENV{HOME}.'/.var/redit/'.$h, map {'scp://'.$_.'/.var/redit/'.$_} grep {$_ ne $h} @ARGV;
exec qw(gvimdiff), $ENV{HOME}.'/.var/redit/'.$h, map {'scp://'.$_.'/.var/redit/'.$_} grep {$_ ne $h} @ARGV;

La forma en que los uso es usar cssh para abrir una conexión a los cuatro hosts y luego usar un comando como EDITOR=~/.bin/redit sudoedit /etc/conf/filey luego, en una ventana diferente, ejecutar ~/.bin/redit1mis cambios, guardar y salir, volver a cssh y presionar enter para confirmar los cambios y salga de sudoedit (a menos que esté editando más de un archivo, en cuyo caso redit avanza al siguiente archivo de la lista y ejecuta redit1 nuevamente para el siguiente archivo).

Como lo que está haciendo es menos complicado, no necesita redit1 debido a que solo trabaja con un host remoto, simplemente puede apuntar su editor sftp al host: .var / redit / host o equivalente.

Lo que hago es usar scp en lugar de (s) ftp, y cambiar el shell a sudo su -WinSCP, esto está en Advanced \ SCP \ Shell, pero esto solo funciona con el protocolo scp.

Para sftp: si tiene acceso a sudo ssh shell, puede agregar su nombre de usuario al grupo de usuarios raíz en / etc / group y luego otorgar permisos de rx de grupo a las carpetas a las que desea acceder.

Puede insertar en su archivo sshd_config en el lado del servidor:

Subsystem sftp sudo -n true && sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-server

De esta forma, quien tenga el sudo NOPASSWD correcto obtendrá un acceso sftp rooteado.

Agregar esta línea en / etc / ssh / sshd_config fue una solución para mí, y comentar la línea del subsistema existente Subsystem sftp sudo -n true && sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-server

luego sudo systemctl sshd restart