De vez em quando recebo o pedido estranho para fornecer suporte remoto, resolução de problemas e / ou ajuste de desempenho em sistemas Linux.
As grandes empresas geralmente já possuem procedimentos bem estabelecidos para fornecer acesso remoto a fornecedores / fornecedores e eu só preciso cumpri-los. (Para melhor ou para pior).
Por outro lado, as pequenas empresas e os indivíduos invariavelmente se voltam para mim para instruí-los com o que precisam fazer para me preparar. Normalmente, seus servidores estão diretamente conectados à Internet e as medidas de segurança existentes consistem nos padrões para qualquer que seja sua distribuição Linux.
Quase sempre preciso de acesso ao nível de raiz e quem quer que esteja configurando o acesso para mim não é um administrador de sistema especializado. Não quero a senha de root deles e também tenho certeza de que minhas ações não serão mal-intencionadas, mas que instruções razoavelmente simples eu devo dar para:
(E sim, estou ciente e sempre aviso a esses clientes que, uma vez que eu tenha acesso de administrador ocultando quaisquer ações maliciosas, isso é trivial, mas vamos supor que não tenho nada a esconder e participar ativamente na criação de uma trilha de auditoria).
What can be improved on the steps below?
set up an account and securely exchange credentials
Eu forneço um hash de senha e peço que minha conta esteja configurada com essa senha criptografada. Por isso, não precisaremos transmitir uma senha de texto não criptografado, serei o único que sabe a senha e não comece com uma senha fraca previsível.
sudo useradd -p '$1$********' hbruijn
Eu forneço um SSH de chave pública (par de chaves específico por cliente) e peço que eles configurem minha conta com essa chave:
sudo su - hbruijn
mkdir -p ~/.ssh
chmod 0700 ~/.ssh
echo 'from="10.80.0.0/14,192.168.1.2" ssh-rsa AAAAB3NzaC1y***...***== hbruijn@serverfault' >> ~/.ssh/authorized_keys
chmod 0600 ~/.ssh/authorized_keys
set up root (sudo) access
Peço ao cliente que configure o sudo para mim com sudo sudoedit ou usando o editor favorito deles e acrescente /etc/sudoers :
hbruijn ALL=(ALL) ALL
restrict access to my account
Normalmente, o cliente ainda permite logins baseados em senha e peço que eles adicionem as duas linhas seguintes a /etc/ssh/sshd_config para pelo menos restringir minha conta apenas a chaves SSH:
Match user hbruijn
PasswordAuthentication no
Dependendo do cliente, rotearemos todo o meu acesso SSH através de um único host bastion para sempre fornecer um único endereço IP estático (por exemplo, 192.168.1.2) e / ou fornecer o intervalo de endereços IP que meu ISP usa (por exemplo instância 10.80.0.0/14). O cliente pode precisar adicioná-los a uma lista de desbloqueio de firewall se o acesso SSH estiver restrito (na maioria das vezes o ssh não é filtrado).
Você já viu esses endereços IP como a restrição from= no arquivo ~.ssh/authorized_keys que limita os hosts dos quais minha chave pode ser usada para acessar seus sistemas.
provide audit trail
Até agora, nenhum cliente me pediu isso, e não fiz nada além do seguinte para cobrir minha bunda:
Eu tento usar sempre sudo com comandos individuais e tento evitar o uso de sudo -i ou sudo su - . Eu tento não usar sudo vim /path/to/file mas use sudoedit .
Por padrão, todas as ações privilegiadas serão registradas no syslog (e /var/log/secure ):
Sep 26 11:00:03 hostname sudo: hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=jboss ; COMMAND=sudoedit /usr/share/jbossas/domain/configuration/domain.xml
Sep 26 11:00:34 hostname sudo: hbruijn : TTY=pts/0 ; PWD=/home/hbruijn ; USER=root ; COMMAND=/usr/bin/tail -n 5 /var/log/messages
Eu desisto principalmente de personalizar meus ambientes de trabalho, a única coisa que realmente faço é definir o seguinte no meu ~/.bash_profile , aumentando o histórico do bash e incluindo os timestamps:
export HISTSIZE=99999999999
export HISTFILESIZE=99999999999
export HISTIGNORE="w:ls:ls -lart:dmesg:history:fg"
export HISTTIMEFORMAT='%F %H:%M:%S '
shopt -s histappend
Você pode gravar suas sessões com o utilitário script (1) .
$ script session.log
Script started, file is session.log
$ ls
file1 session.log
exit
Script done, file is session.log
então tudo está em session.log.
Já que você já está efetuando login com uma chave pública SSH, isso aumentaria um pouco as coisas se você não fornecesse um hash de senha; em vez disso, diga-lhes para usar adduser --disabled-password (equivalentemente, useradd -p '!' , eu acho), que é efetivamente equivalente a PasswordAuthentication no para essa conta, além de não haver chance de alguém bisbilhotar seu e-mail poder forçar a senha e o log em como você.
Por que fornecer uma senha, quando você vai usar chaves públicas / privadas.
As chaves públicas devem ser compartilhadas, por isso é isso que você deve usar para trocar credenciais com segurança, não para senhas com hash.
sudo useradd --disabled-password hbruijn
Ao enviar sua chave pública, verifique a impressão digital em um segundo canal, como uma chamada telefônica, para que você saiba que ninguém a alterou ao entrar.
Como você não terá uma senha agora para usar o sudo, você também precisa alterar sua linha no arquivo sudoers para
hbruijn ALL=(ALL) NOPASSWD:ALL
Se você não está confortável em não ter nenhuma senha para o sudo e realmente quer uma senha, ainda não há necessidade de enviar sua senha com hash, permitir que a conta seja criada sem senha, definir sua chave pública e sua conta está configurada, você pode fazer login no ssh e executar
passwd para definir sua própria senha.