Question #1
My question is, how do I restrict the command to just this SFTP transfer in the public key that is generated?
Existem 2 métodos para fazer isso.
1. - Restringindo por sshd
Este método envolve a configuração do recurso SFTP no seu daemon SSH, sshd . Isso é controlado pelo arquivo de configuração /etc/ssh/sshd_config . OBSERVAÇÃO: Isso restringirá o usuário, backup a ser permitido somente para SFTP no servidor.
# /etc/ssh/sshd_config
Subsystem sftp internal-sftp
## You want to put only certain users (i.e users who belongs to sftpusers
## group) in the chroot jail environment. Add the following lines at the end
## of /etc/ssh/sshd_config
Match User backup
ForceCommand internal-sftp
2. - Restringindo através de authorized_keys
Este método não envolve alterações no arquivo sshd_config . Você pode limitar um usuário + uma chave SSH a um único comando através do recurso command= que você já mencionou na sua pergunta. O truque está em qual comando você inclui. Você pode colocar o servidor SFTP nesta linha command= , que tem o mesmo efeito que configurar o servidor SFTP no arquivo sshd_config .
# User backup's $HOME/.ssh/authorized_keys file
command="/usr/libexec/openssh/sftp-server" ssh-dss AAAAC8ghi9ldw== backup@host
OBSERVAÇÃO: se o usuário tiver acesso de gravação a ~/.ssh/authorized_keys , ele poderá lê-lo e / ou modificá-lo. Por exemplo, eles poderiam baixá-lo, editá-lo e enviá-lo novamente, removendo o commmand=... , concedendo-lhe acesso irrestrito ao comando, incluindo o shell. Se o usuário tiver acesso de gravação a ~/.ssh , ele também poderá simplesmente desvincular e recriar o arquivo ou chmod para gravar o acesso. Existem muitas soluções possíveis, como colocar os arquivos ~/.ssh/authorized_keys em um local não gravável pelo usuário, como:
Match Group sftponly
AuthorizedKeysFile /etc/ssh/authorized_keys/%u
Question #2
And since I am on a dynamic IP address, how do I overcome the "missing known host" problem each time my IP changes?
Isso é mais complicado, mas factível, usando o recurso from= dentro do arquivo authorized_keys . Aqui estamos limitando o acesso somente do host, somehost.dyndns.org .
from="somehost.dyndns.org",command="/usr/libexec/openssh/sftp-server",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss AAAAC8ghi9ldw== backup@host
As configurações adicionais após o command= são igualmente importantes, pois limitam ainda mais o uso da chave SSH.
detalhamento de recursos
-
from='hostname1,hostname2,''- Restringe o acesso dos padrões especificados de IP ou hostname -
command='command'- Executa o comando especificado após a autenticação -
no-pty- Não aloca um pty (não permite login interativo) -
no-port-forwarding- não permite o encaminhamento de porta -
no-X11-forwarding- o usuário não poderá remover as GUIs do X11 de exibição -
no-agent-forwarding- o usuário não poderá encaminhar este host para outros hosts internos
Para se livrar da mensagem sobre os "hosts conhecidos ausentes", você pode adicionar esta opção SSH ao cliente quando ele se conecta da seguinte forma:
$ ssh -o StrictHostKeyChecking=no ....
Veja a página de manual, ssh_config para detalhes completos sobre essa opção.
Restringindo o shell do usuário
Para ambas as soluções acima, é provável que você queira bloquear o usuário backup , limitando também o shell desse usuário no arquivo /etc/passwd . Normalmente, você desejará configurá-lo como scponly , mas também há outras opções para isso. Veja este P & D Q & A intitulado: " Você precisa de um shell para SCP? "para formas de fazer isso.
O uso de /sbin/nologin também pode ser usado se você optar por usar o recurso chroot de sshd_config , conforme descrito em # 1 acima. No entanto, se você optar por usar o método descrito em # 2 , provavelmente precisará usar scponly ou outra coisa para o shell do usuário em /etc/passwd .
BONUS - Estendendo o nº 2 acima
Se você precisar expor um conjunto de comandos para esse usuário, também poderá fazer isso. Crie um script assim, /home/backup/commands.sh :
#!/bin/sh
case $SSH_ORIGINAL_COMMAND in
"diskspace")
df -h
;;
"dirlist")
ls -1
;;
"apache_restart")
/etc/init.d/apache restart
;;
*)
echo "Unknown command"
esac
Você configura o arquivo authorized_keys assim:
command="/bin/sh /home/user/commands.sh" ssh-dss AAAAC8ghi9ldw== user@host
O usuário backup pode então executar esses comandos da seguinte forma:
# diskspace
$ ssh -q user@remote_host diskspace
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/dev-root 39G 2.2G 35G 6% /
# dirlist
$ ssh -q remote_host dirlist
commands.sh
dump.sql