QF0's questions

Estou automatizando a geração de chaves com ssh-keygen(OpenSSH v8.9), em um servidor headless. Isso é direto se nenhuma senha for necessária, mas fica difícil se você precisar de uma senha. ssh-keygenprecisa de 3 coisas no stdin ao gerar uma nova chave: y, porque o arquivo de chaves já existe, e a senha necessária, repetida duas vezes.

Com alguma simplificação, estou fazendo isso da seguinte maneira:

$ printf -v input "y\npassword\npassword\n"
$ echo -n "$input"
y
password
password
$ echo -n "$input" | ssh-keygen -t ed25519 -a100 -f tmpkey

Quando fiz isso inicialmente, obtive esta saída:

Generating public/private ed25519 key pair.
tmpkey already exists.
Overwrite (y/n)? ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory

O par de chaves foi criado, mas a chave privada não foi criptografada. Então, eu instalei ssh-askpass, em um sistema de teste com X. Quando eu executo ssh-keygenagora, eu recebo um pop-up de autenticação OpenSSH, e stdin agora é ignorado. Obviamente, eu não posso ter um pop-up gráfico em um servidor headless, mesmo se eu quisesse.

Então o que está acontecendo? Posso persuadir ssh-keygena automatizar a entrada de senha? Se não, posso usar opensslpara adicionar uma senha ou até mesmo criar o arquivo? Eu quero obter uma chave de formato OpenSSH disso - já estou automatizando o PKCS#8 com o openssl.

EDITAR

Eu encontrei o SSH_ASKPASS_REQUIREenvvar para ssh(não ssh-keygen). Se eu configurá-lo para 'never', ele para o ssh-askpasspopup, mas ssh-keygenagora lê apenas a primeira linha de stdin e ignora a senha nas próximas duas linhas. Então, não me leva a lugar nenhum.

Eu tenho um procedimento que criará manualmente um volume de troca dm-crypt simples, com uma chave aleatória, que parece funcionar. Este é um sistema QEMU/Ubuntu 22.04. No entanto, não há troca após a reinicialização, então provavelmente entendi meu /etc/crypttabe/ou /etc/fstab, ou algo mais, incorreto. Qualquer contribuição será apreciada.

A configuração do manual de trabalho é:

    # swapoff -a
    # cryptsetup --type plain open /dev/mapper/vg0-swap encswap
    # mkswap /dev/mapper/encswap
    # /etc/init.d/cryptdisks start
    # swapon /dev/mapper/encswap
    
    # swapon -s
    Filename                Type        Size        Used    Priority
    /dev/dm-3               partition   2097148     0       -2
    # lsblk
    NAME          MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
    sda             8:0    0   50G  0 disk  
    ├─sda1          8:1    0    1M  0 part  
    ├─sda2          8:2    0    1G  0 part  /boot
    ├─sda3          8:3    0   13G  0 part  
    │ ├─vg0-swap  253:0    0    2G  0 lvm   
    │ │ └─encswap 253:3    0    2G  0 crypt [SWAP]
    │ ├─vg0-data  253:1    0 36.1G  0 lvm   /data
    │ └─vg0-root  253:2    0 10.9G  0 lvm   /
    └─sda4          8:4    0   36G  0 part  
      └─vg0-data  253:1    0 36.1G  0 lvm   /data
    sr0            11:0    1    4M  0 rom 
  # cryptsetup status /dev/mapper/encswap
  /dev/mapper/encswap is active and is in use.
  type:    PLAIN
  cipher:  aes-cbc-essiv:sha256
  keysize: 256 bits
  key location: dm-crypt
  device:  /dev/mapper/vg0-swap
  sector size:  512
  offset:  0 sectors
  size:    4194304 sectors
  mode:    read/write

Então, para tornar isso persistente, /etc/crypttabcontém:

swap  /dev/mapper/encswap  /dev/urandom  plain,cipher=aes-xts-plain64,size=256,hash=sha256,swap,noearly

E /etc/fstabcontém:

/dev/mapper/swap none swap sw 0 0

Quando o sistema é inicializado dm-cryptou systemdultrapassa o tempo limite padrão de 90 anos, parece estar aguardando uma chave que nunca chega. O syslog diz praticamente a mesma coisa: tempo limite de espera /dev/mapper/encswap. Quando a inicialização é concluída, swapon -snão mostra nada e lsblknão mostra um encswapdispositivo (ou qualquer dispositivo de troca). Alguma ideia?

Configurei um VPS (Ubuntu 22.04, em Contabo na Alemanha) ontem. Infelizmente, recebi a entrada de DNS reverso incorreta (eu inseri example.orgem vez de example.uk). Eu percebi isso rapidamente e o corrigi, e ambos mxtoolbox.come digno meu sistema local mostraram a resolução correta para example.uk.

Este novo sistema tem que se comunicar com um servidor de e-mail, que também é o Ubuntu 22.04 (em Ionos no Reino Unido). No entanto, postfixno servidor de correio rejeita os e-mails recebidos, porque o endereço IP de entrada ainda está resolvendo para example.org. Isso vem acontecendo há cerca de 16 horas. Houve um período ontem à noite em que as correspondências estavam sendo entregues, mas não estão sendo entregues agora.

No servidor de correio, dig +noall +answer -x ip-addrmostra uma contagem regressiva de 2 horas no TTL. No entanto, ele apenas circula novamente, mas ainda mostra example.org. Se eu liberar o cache local com sudo resolvectl flush-cachesele não faz diferença, mas inicia a contagem regressiva novamente. Eu tentei isso em outro VPS no mesmo datacenter (Ionos, Reino Unido) e mostra os mesmos resultados.

Portanto, suponho que Ionos tenha um cache rDNS que ignora o TTL upstream (já mxtoolboxque meu próprio local digestá mostrando o example.ukresultado correto há mais de 16 horas). Isso faz sentido? Posso configurar o resolvedor local no servidor de correio para (temporariamente) ignorar qualquer cache upstream e obter uma resposta autoritativa? Como você obtém uma resposta autoritária no DNS reverso?

Durante os backups, preciso deixar o Apache 'inativo' para poder parar o MySQL e, em seguida, fazer backup dos bancos de dados MySQL e SQLite. O único acesso aos bancos de dados é através do Apache.

Atualmente, estou pensando em fazer isso com um script que modifique a configuração do Apache para redirecionar todos os acessos para uma página de 'site down', e então:

apache2ctl graceful
systemctl stop mysqld

No entanto, isso não parece ser uma ideia particularmente boa. gracefulnão para todos os trabalhadores infantis e, presumivelmente, apache2ctlretorna imediatamente. Este é um servidor de volume muito baixo e o backup é executado no meio da noite, em um fuso horário, e tenho certeza de que nenhuma solicitação durará mais de um minuto.

Existe uma maneira 'boa' de lidar com isso, em vez de apenas colocar um sleep 60após o graceful? Estou pensando que pode ser uma ideia melhor fazer um graceful-stope não se preocupar com uma página do site inativa, definida GracefulShutdownTimeoutpara 60 e dormir por 60 também.

Observe que entendo o que é "Amazon S3"; Estou perguntando apenas sobre o software que lida com a interface HTTP.

Se eu verificar os cabeçalhos HTTP para github.com , por exemplo, um dos cabeçalhos de resposta será:

server: AmazonS3

A Amazon realmente tem um servidor da web que chama de 'AmazonS3' ou eles estão apenas modificando os cabeçalhos do Apache/nginx/etc?

O script 1 abaixo é bash e está em https://example.com/cgi-bin/test. Ele produz a saída 'Em construção' quando buscado. Ele ecoa Statuse Content-typecabeçalhos e alguns HTML. Se eu tentar ecoar um documento HTML inteiro, o Apache apenas reclamará de um cabeçalho inválido.

O script 2 abaixo é php e está em https://example.com/cgi-bin/test2.php. Ao contrário do script bash, este retorna um documento HTML.

Como é que o script 2 pode enviar um documento HTML inteiro, mas o script 1 não?

Roteiro 1

#!/bin/bash
cat <<'EOF'
Status: 200 OK
Content-type: text/html

<p>Under construction.</p>
EOF

Roteiro 2

<?php
print <<<EOF  
<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8">
    ...etc
  </head>

  <body>
  ...etc
  </body>
</html>
EOF;
?>

EDITAR

phpvem em 2 sabores: as versões CLI e CGI. Se você acabou de executar o Script 2 a partir da linha de comando, php test2.phpa única saída produzida por phpé exatamente o que você vê: o documento HTML. php-cgié a versão CGI (instalar no Ubuntu/Deb como apt install php-cgi). O Apache (efetivamente) executa a versão CGI (na vida real, ele faz isso de maneira ligeiramente diferente, mas com os mesmos resultados):

 $ php-cgi test2.php
Content-type: text/html; charset=UTF-8

<!DOCTYPE html>
...rest of doc

Os scripts CGI devem retornar pelo menos Content-typepara o Apache (mas podem retornar mais cabeçalhos, incluindo Status). Portanto, a resposta é que ambos os scripts funcionam porque o Script 1 retorna explicitamente Content-type, enquanto a versão CGI oculta phpfaz o mesmo.

O script bash pode retornar todo o documento HTML, desde que também retorne o arquivo Content-type.

Cenário: Estou testando um servidor SMTP em minha rede local e agora preciso verificar se ele pode enviar e-mails para a rede. O problema é, claro, que estou saindo pelo meu ISP, e meu endereço IP fixo atribuído ao ISP não está no DNS (eu poderia colocá-lo no DNS, é claro, mas não consegui definir a pesquisa inversa, então não ajudaria).

Para contornar isso, tenho o Postfix configurado em um servidor remoto e estou tentando retransmitir minhas mensagens de saída por meio desse servidor para um destinatário local nesse servidor. Parece que deve ser simples, mas obviamente estou perdendo alguma coisa. Esta é uma nova configuração do Postfix 3.6.4 e main.cfcontém:

mynetworks = 127.0.0.0/8, 93.184.216.34/32
smtpd_helo_restrictions = permit_mynetworks, ...
smtpd_client_restrictions = permit_mynetworks, ...

93.184.216.34é meu endereço atribuído pelo ISP e minha rede local é dummy-domain.com. Quando tento enviar um email para o servidor, recebo uma falha e o arquivo de log do servidor diz:

Oct 16 13:24:42 titan postfix/smtpd[19103]: connect from my-isp[93.184.216.34]
Oct 16 13:24:42 titan postfix/smtpd[19103]: NOQUEUE: reject: RCPT from my-isp[93.184.216.34]: 450 4.1.8 <[email protected]>: Sender address rejected: Domain not found; from=<[email protected]> to=<a-local-recipient-address> proto=ESMTP helo=<dummy-domain.com>
Oct 16 13:24:42 titan postfix/smtpd[19103]: lost connection after RCPT from my-isp[93.184.216.34]

postconfconfirma mynetworks, mas também diz isso:

compatibility_level = 0
smtpd_relay_restrictions = ${{$compatibility_level} <level {1} ? {} : {permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination}}

O que eu entendo, talvez incorretamente, dizer que o padrão smtpd_relay_restrictionsnão inclui , ao contráriopermit_mynetworks da documentação. Então eu explicitamente defino isso em main.cf:

smtpd_relay_restrictions = permit_mynetworks

Reiniciado, E postconfagora relata exatamente a linha acima. No entanto, ainda não funciona, e o arquivo de log do servidor ainda mostra a mesma mensagem. Alguma ideia? E como faço postconfpara me mostrar as configurações reais atuais, sem ter que me preocupar com o nível de compatibilidade? Obrigado.

EDITAR

de acordo com a resposta do anx, verifica-se que smtpd_client_restrictions = permit_mynetworks("Permitir a solicitação quando o endereço IP do cliente corresponder a qualquer rede ou endereço de rede listado em $ mynetworks") não é suficiente. Você também precisa

smtpd_sender_restrictions = permit_mynetworks

com permit_mynetworksantes reject_unknown_sender_domain. Isso tudo funciona sem nenhuma alteração /etc/hostsou necessidade de adicionar nada ao DNS.

Configurei sendmailpara ouvir na porta 1234 em vez de 25 com uma alteração para sendmail.mc:

DAEMON_OPTIONS(`Port=1234, Name=MTA')

Isso geralmente funciona, com uma exceção. O pano de fundo é que eu tenho um relé escutando na porta 25 (o relé deve ter um registro MX, então deve estar na porta 25). O relé envia e-mails via sendmail, então sendmail escuta em localhost:1234. Em outras palavras, o sendmail é responsável apenas por enviar e-mails, e não por recebê-los. netstat/etc confirma que o relé está escutando em 25 e o sendmail está escutando em 1234.

Isso funciona nestes dois casos de teste:

1. Posso enviar emails por telnet'ing para sendmail ( telnet localhost 1234)
2. Posso enviar e-mails s-nailcom uma alteração de configuração apropriada ( set mta=smtp://localhost:1234)

No entanto, essa configuração não funciona se eu executar o sendmail diretamente:

sendmail -d8.20 -vt < test-email.txt

Nesse caso, o sendmail tenta enviar o e-mail conectando-se à porta 25 localmente, de modo que ele realmente se comunica com a retransmissão local, em vez de um servidor SMTP remoto. A saída de depuração mostra:

[email protected]... Connecting to [127.0.0.1] via relay...
220 mydomain.org ESMTP mydomain relay

Isso me deixou perplexo - alguma idéia do que está acontecendo aqui?

EDITAR

Fazendo algum progresso. Estou no Sendmail 8.15.2, Ubuntu 20.04. Esse problema realmente não importaria, exceto que o sendmail libera suas filas MSP com um cron job que é executado a cada 20 minutos, então recebo muitas entradas de falha do syslog e grandes filas de e-mail não entregues, porque o sendmail não pode se encontrar.

O problema parece ser o seguinte. Quando você envia um e-mail (ou gerencia as filas) usando o sendmail, é (normalmente) um processo de 2 etapas. Você executa o sendmail, que lê submit.cf(e não sendmail.cf ), e atua como um MSA, enviando o email para algo. Esse algo normalmente é o daemon sendmail local, que lê sendmail.cfquando é ativado.

sendmail.cfdiz ao sendmail que ele precisa ouvir localhost:1234os e-mails recebidos. Isso significa que submit.cfdeve conter uma configuração que diga ao programa sendmail para rotear e-mails de saída para localhost:1234.

A submit.mcconfiguração relevante é provavelmente FEATURE msp, cujo padrão é

FEATURE(`msp', `[127.0.0.1]', `25')

Portanto, a resposta é provavelmente tão simples quanto alterar 25 para 1234. No entanto, não é tão fácil. Apenas alterá-lo, regenerar os arquivos e reiniciar o sendmail não faz diferença. Na verdade, regenerar submit.cfcom um m4ou makeoutro faz exatamente zero diferença ou fornece um cfarquivo com o recurso comentado. Há alguma mágica em algum lugar que permite alterar o recurso, mas não tenho ideia do quê. A resposta pode estar em /usr/share/sendmail/cf/feature/msp.m4, mas não consigo vê-la.

Situação hipotética: tenho dois computadores (Linux) na mesma rede com o mesmo nome de host, mas FQDNs diferentes ( foo.example.come foo.example.org).

Eles têm endereços MAC diferentes e obtêm seus endereços IP de um servidor DHCP.

Que problemas isso pode causar, se houver? Em particular, não há DNS nesta rede, e os endereços IP são pesquisados /etc/hosts​​e o equivalente do Windows. Pode /etc/hostsconter várias entradas com o mesmo alias ou devo omitir o alias?

Eu quero redirecionar todo o tráfego de entrada na interface ens4f0para o endereço IP 192.168.50.10, mas o Wireshark está mostrando que o endereço IP de destino nos pacotes recebidos está inalterado. Este é o comportamento esperado? Eu pensei que PREROUTING entrou antes de qualquer outra coisa?

Meu iptablescomando é:

# iptables -t nat -A PREROUTING -i ens4f0 -j DNAT --to 192.168.50.10
# iptables -t nat -vL
Chain PREROUTING (policy ACCEPT 24618 packets, 1923K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DNAT       all  --  ens4f0 any     anywhere             anywhere             to:192.168.50.8
    0     0 DNAT       all  --  ens4f0 any     anywhere             anywhere             to:192.168.50.10
    0     0 DNAT       all  --  ens4f0 any     anywhere             anywhere             to:192.168.50.10

Eu sei que os pacotes de entrada são de 192.168.50.8, então também tentei:

# iptables -t nat -A PREROUTING -i ens4f0 -j DNAT -s 192.168.50.8/32 --to 192.168.50.10
# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         
DNAT       all  --  anywhere             anywhere             to:192.168.50.8
DNAT       all  --  anywhere             anywhere             to:192.168.50.10
DNAT       all  --  anywhere             anywhere             to:192.168.50.10
DNAT       all  --  192.168.50.8         anywhere             to:192.168.50.10