WoJ's questions

Atualmente, uso chaves ssh para me conectar ao meu servidor (Ubuntu 18.04). Eu gostaria de permitir (em um escopo específico e limitado) a capacidade de fazer login com senhas.

Sempre que tento, minhas senhas falham. abaixo está uma sessão em que defino uma senha, depois tento usá-la:

~ # id
uid=0(root) gid=0(root) groups=0(root)

~ # passwd
Enter new UNIX password: <helloworld>
Retype new UNIX password: <helloworld>
passwd: password updated successfully

~ # ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no [email protected]
The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established.
ECDSA key fingerprint is SHA256:AlFtwpK4EhhaMXP5aT6fuQM9u9RYPq/o/sLJXfz++jM.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.
[email protected]'s password: <helloworld>
Permission denied, please try again.

Peço desculpas se isso for algo óbvio, não tenho ideia de por que o servidor aceita uma nova senha e, em seguida, aceita um login baseado em senha para finalmente rejeitar as credenciais.

EDIT: o sshd_configarquivo que não consegui adicionar

~ # cat /etc/ssh/sshd_config | grep -v ^#  | grep -v ^$                                                                                                                  root@srv
Port 22
PasswordAuthentication no
ChallengeResponseAuthentication no
GSSAPIAuthentication no
UsePAM yes
PrintMotd no
UseDNS no
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server
Match Address 192.168.10.0/24,192.168.20.0/24,127.0.0.0/8
    PasswordAuthentication yes

Estou tentando ver o que foi registrado no meu sistema entre "logo antes da meia-noite" (portanto, os últimos momentos de ontem), até logo depois.

~ # journalctl --since "2019-09-09 23:59" --until "2019-09-10 00:10"                                                                                                     
-- Logs begin at Mon 2019-08-05 09:48:15 CEST, end at Tue 2019-09-10 17:04:00 CEST. --

~ # 

A saída está vazia e sou informado de que há logs disponíveis desde um mês atrás até agora. Por que não são mostrados?

Um bare journalctlmostra muitos logs (começando em agosto, terminando agora)

~ # journalctl | tail -5
Sep 10 17:10:53 srv synapse[1111]: 2019-09-10 17:10:53,792 synapse.access.http.8008 (...)
Sep 10 17:11:00 srv caddy[1111]: (...)
Sep 10 17:11:02 srv mqtt[1111]: 1568128262: New (...)
Sep 10 17:11:02 srv mqtt[1111]: 1568128262: New(...)
Sep 10 17:11:02 srv mqtt[1111]: 1568128262: Client (...)

~ # journalctl | head -5                                                                                                                                                 root@srv
-- Logs begin at Mon 2019-08-05 09:48:15 CEST, end at Tue 2019-09-10 17:13:23 CEST. --
Aug 05 09:48:15 srv systemd[15247]: Stopped target Default.
Aug 05 09:48:15 srv systemd[15247]: Stopped target Basic System.
Aug 05 09:48:15 srv systemd[15247]: Stopped target Paths.
Aug 05 09:48:15 srv systemd[15247]: Stopped target Timers.

EDIT 1: Existem eventos nesse intervalo de tempo:

~ # less /var/log/syslog.1
(...)
Sep 10 00:07:41 srv systemd[1]: Started Session 109446 of user root.
(...)

EDIT 2: Curiosamente, para outro intervalo de tempo, recebo eventos, mas não desse intervalo de tempo:

~ # journalctl --since "2019-09-09 18:00" --until "2019-09-10 19:00"
-- Logs begin at Mon 2019-08-05 09:48:15 CEST, end at Tue 2019-09-10 19:21:44 CEST. --
Sep 10 15:51:26 srv systemd[468]: pam_unix(systemd-user:session): session opened for user root by (uid=0)
Sep 10 15:51:26 srv audit[468]: USER_START pid=468 uid=0 auid=0 ses=146446 msg='op=PAM:session_open acct="root" exe="/lib/systemd/systemd" hostname=? addr=? t
Sep 10 15:51:26 srv systemd[468]: Reached target Paths.

Tenho alguns containers ( systemd-nspawnbaseados) e gostaria de saber se devo configurar o horário (via systemd-timesyncd) ou é mantido pelo host?

Eu tenho um host que está ligado 192.168.0.0/24com um IP de 192.168.0.13. Seu gateway fornecido por DHCP é 192.168.0.254.

A configuração é feita via systemd-networkde o problema abaixo está presente pelo menos até a versão 240(a versão que uso hoje - veja minha resposta em relação a outras versões).

Eu preciso que este host alcance 10.0.0.0/8redes que estão disponíveis através de um 192.168.0.10gateway - isso pode ser feito adicionando uma rota estática:

# ip r add 10.0.0.0/8 via 192.168.0.10

Funciona bem (o tráfego passa).

Agora eu queria adicionar esta entrada à minha systemd-networkdconfiguração, adicionando um [Route]à minha definição atual

[Match]
Name=eth0

[Network]
DHCP=yes

# the entry below is added to ensure a static route

[Route]
Gateway=192.168.0.10
Destination=10.0.0.0/8

Não funciona:

• nenhuma rota estática é adicionada
• há uma mensagem de erro no log mencionando uma rede inacessível

Jan 17 11:29:32 rpi-dmz systemd[1]: Stopping Network Service...
Jan 17 11:29:32 rpi-dmz systemd[1]: Stopped Network Service.
Jan 17 11:29:32 rpi-dmz systemd[1]: Starting Network Service...
Jan 17 11:29:33 rpi-dmz systemd-networkd[14584]: wlan0: Gained IPv6LL
Jan 17 11:29:33 rpi-dmz systemd-networkd[14584]: eth0: Gained IPv6LL
Jan 17 11:29:33 rpi-dmz systemd-networkd[14584]: Enumeration completed
Jan 17 11:29:33 rpi-dmz systemd[1]: Started Network Service.
Jan 17 11:29:33 rpi-dmz systemd-networkd[14584]: eth0: Could not set route: Network is unreachable
Jan 17 11:29:33 rpi-dmz systemd-networkd[14584]: eth0: DHCPv4 address 192.168.0.13/24 via 192.168.0.254

Como adicionar corretamente essa rota via systemd-networkd?

Considere a seguinte topologia:

Estou enviando pacotes ICMP (ping) de host Bpara 10.0.1.1. Eles atingem o alvo e o alvo responde com um reply. A conectividade funciona bem.

Ao correr, emhost A

• tcpdump -i eth1 icmp: não vejo nenhum pacote
• tcpdump -i eth2 icmp: eu vejo os pacotes

Existe uma maneira de verificar se um pacote destinado a interface eth1chegou a essa interface?

Lembro-me vagamente de ler um dia que o kernel estava entregando a resposta no eth2nível (que é a primeira interface que o pacote atinge) para explicar por que o monitoramento eth1não produz nenhum resultado.

Por que eu precisaria verificar esse caso específico: tenho casos em que um pacote chega em uma interface de um host (o primeiro a caminho), mas parece não atingir a interface pretendida (o aplicativo real não é ativado ). Esse teste garantiria que o firewall/encaminhamento está OK e que o problema está em outro lugar (na configuração do aplicativo, um bug no aplicativo etc.)

Eu gostaria de configurar um Timer que irá parar um serviço, executar um script e reiniciar o serviço.

Uma das possibilidades é usar

Type=oneshot
ExecStartPre=/bin/systemctl stop myservice
ExecStart=/usr/local/bin/myscript.sh
ExecStartPost=/bin/systemctl start myservice

Outra é ter que myscript.shlidar com a coisa toda, incluindo systemctl.

Acho estranho, no entanto, usar systemctldentro de uma declaração de serviço, quando pode haver mecanismos internos do systemd para interagir com os serviços. Existe uma maneira mais limpa de realizar essas operações?

Existe uma maneira documentada de verificar, de dentro do código do programa em execução como o próprio serviço , que ele foi iniciado systemd(em vez de ser iniciado de dentro de uma sessão de login interativa, do cron, etc.)?

Minha solução atual é definir uma variável de ambiente na .serviceunidade ( Environment=...) e verificar sua existência no meu código. Mas pode haver algo diretamente disponível.