Razões para perder informações de IP na saída 'last' nos logins de pts?

Question

Eu tenho cinco sistemas Linux CentOS 6 no trabalho, e encontrei um problema bastante estranho que só parece acontecer com meu ID de usuário em todos os sistemas Linux que eu tenho ... Este é um exemplo do problema de entradas que eu excetuado do comando last ...

mpenning pts/19                        Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17                        Fri Nov 16 10:21 - 10:42  (00:21)
bill     pts/15       sol-bill.local   Fri Nov 16 10:19 - 10:36  (00:16)
mpenning pts/1        192.0.2.91       Fri Nov 16 10:17 - 10:49 (12+00:31)
kkim14   pts/14       192.0.2.225      Thu Nov 15 18:02 - 15:17 (4+21:15)
gduarte  pts/10       192.0.2.135      Thu Nov 15 12:33 - 08:10 (11+19:36)
gduarte  pts/9        192.0.2.135      Thu Nov 15 12:31 - 08:10 (11+19:38)
kkim14   pts/0        :0.0             Thu Nov 15 12:27 - 15:17 (5+02:49)
gduarte  pts/6        192.0.2.135      Thu Nov 15 11:44 - 08:10 (11+20:25)
kkim14   pts/13       192.0.2.225      Thu Nov 15 09:56 - 15:17 (5+05:20)
kkim14   pts/12       192.0.2.225      Thu Nov 15 08:28 - 15:17 (5+06:49)
kkim14   pts/11       192.0.2.225      Thu Nov 15 08:26 - 15:17 (5+06:50)
dspencer pts/8        192.0.2.130      Wed Nov 14 18:24   still logged in
mpenning pts/18       alpha-console-1. Mon Nov 12 14:41 - 14:46  (00:04)

Você pode ver duas das minhas entradas de login pts acima que não têm um endereço IP de origem associado a elas. Minhas máquinas CentOS possuem até seis outros usuários que compartilham os sistemas. Aproximadamente 10% dos meus logins vêem esse problema, mas nenhum outro nome de usuário exibe esse comportamento . Não há entrada em /var/log/secure para as entradas sem um endereço IP de origem.

Perguntas

Devido ao tipo de scripts que mantenho nesses sistemas (que controlam grande parte da nossa infraestrutura de rede), estou um pouco assustado com isso e gostaria de entender o que faria com que meus logins ocasionalmente perdessem endereços de origem.

• Por que last -i mostra 0.0.0.0 para pts entradas de linha (veja também esta resposta )
• Existe alguma coisa (além de atividade maliciosa) que justificasse razoavelmente o comportamento?
• Diferente do registro de data e hora do histórico bash, há outras coisas que posso fazer para rastrear o problema?

Informativo

Desde que isso começou, ativei o carimbo de tempo do histórico de bash (ou seja, HISTTIMEFORMAT="%y-%m-%d %T " em .bash_profile ) e também adicionei um poucos outros hacks de histórico bash ; no entanto, isso não dá pistas sobre o que aconteceu durante as ocorrências anteriores.

Todos os sistemas rodam o CentOS 6.3 ...

[mpenning@typo ~]$ uname -a
Linux typo.local 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep 25 21:43:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[mpenning@typo ~]$

EDITAR

Se eu usar last -i mpenning , vejo entradas como esta ...

mpenning pts/19       0.0.0.0          Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17       0.0.0.0          Fri Nov 16 10:21 - 10:42  (00:21)

Observação para quem está tentando responder: Eu não fiz login com o comando screen ou a GUI . Todos os meus logins são do SSH; para receber o prêmio de recompensa, você deve citar as referências autoritativas para explicar as entradas last -i 0.0.0.0 originadas somente via SSH.

EDIT 2 (para as perguntas do ewwhite)

/etc/resolv.conf (observe que usei .local addrs em last output acima para ocultar as informações da minha empresa)

[mpenning@sasmars network]$ cat /etc/resolv.conf
nameserver 192.0.2.40
nameserver 192.0.2.60
domain mycompany.com
search mycompany.com
[mpenning@sasmars network]$

/etc/hosts info (observe que esse arquivo de hosts personalizados só existe em uma das máquinas com esses problemas)

[mpenning@sasmars network]$ cat /etc/hosts
127.0.0.1       localhost.localdomain localhost
192.0.2.44      sasmars.mycompany.com sasmars
::1             localhost6.localdomain6 localhost6

## Temporary kludge until I add reverse hostname mappings...
## Firewalls
192.0.2.254     a2-inet-fw1
192.0.2.253     a2-inet-fw2
192.0.2.254     a2-wan-fw1
192.0.2.253     a2-wan-fw2
192.0.2.201     a2-fab-fw1
192.0.2.202     a2-fab-fw2
192.0.2.203     t1-eds-fw1
192.0.2.42      sasvpn
192.0.2.246     sasasa1
192.0.2.10      sasoutfw1
## Wireless
192.0.2.6       saswcs1
192.0.2.2       l2wlc3
192.0.2.4       l2wlc4
192.0.2.12      f2wlc5
192.0.2.16      f2wlc6
192.0.2.14      f2wlc1
192.0.2.8       f2wlc2
[mpenning@sasmars network]$

sftp Saída de /var/log/secure *

Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: called (pam_tacplus v1.3.7)
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: user [mpenning] obtained
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: called
Dec 26 10:36:37 sasmars sshd[26016]: tacacs_get_password: obtained password
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: password obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: tty [ssh] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: rhost [192.0.2.91] obtained
Dec 26 10:36:37 sasmars sshd[26016]: pam_sm_authenticate: trying srv 0
Dec 26 10:36:38 sasmars sshd[26016]: Accepted password for mpenning from 192.0.2.91 port 55118 ssh2
Dec 26 10:36:38 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26016]: pam_unix(sshd:session): session opened for user mpenning by (uid=0)
Dec 26 10:36:38 sasmars sshd[26018]: pam_sm_setcred: called (pam_tacplus v1.3.7)
Dec 26 10:36:38 sasmars sshd[26018]: subsystem request for sftp
Dec 26 10:37:20 sasmars sshd[26016]: pam_unix(sshd:session): session closed for user mpenning
Dec 26 10:37:20 sasmars sshd[26016]: pam_sm_setcred: called (pam_tacplus v1.3.7)

RESOLUÇÃO FINAL

Veja minha resposta abaixo

    

Answer 1

script diferenças de comportamento entre RedHat e Debian

Bibliotecas vinculadas

CentOS 6.3 - script (util-linux-ng 2.17.2)

#ldd /usr/bin/script

linux-vdso.so.1 =>  (0x00007fff077ff000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f309f5d1000)
libutempter.so.0 => /usr/lib64/libutempter.so.0 (0x00007f309f3cf000)
libc.so.6 => /lib64/libc.so.6 (0x00007f309f03b000)
/lib64/ld-linux-x86-64.so.2 (0x00007f309f7e1000)

Ubuntu 12.04 - script (util-linux 2.20.1)

#ldd /usr/bin/script

linux-vdso.so.1 =>  (0x00007fff375ff000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007fc0d7ab0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc0d76f1000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc0d7cdc000)

PTY

Base no código-fonte upstream , script de ambas as versões abrem novas páginas . A seguir está o teste.

Ubuntu 12.04

john@U64D211:~/tmp$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp$ script
Script started, file is typescript
john@U64D211:~/tmp$ ls /dev/pts
0  1  2  5  8  ptmx
john@U64D211:~/tmp$ last -i
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 09:52  (00:44)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp$ exit
exit
Script done, file is typescript
john@U64D211:~/tmp$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp$ 

O Ubuntu 12.04 script abriu um novo teste (2). Apenas não atualizou /var/log/wtmp .

CentOS 6

Estou pulando o teste, pois já sabemos que script abre o arquivo e se registra no wtmp.

libutemper

• Projeto: link
• Descrição: o libutempter fornece uma interface de biblioteca para emuladores de terminal, como screen e xterm, para gravar sessões do usuário em arquivos utmp e wtmp.

Portanto, a principal diferença parece ser a biblioteca extra ( libutempter.so.0 ) do CentOS script ligada.

Teste com o Ubuntu 12.04

Compilando script com libutempter

john@U64D211:~/tmp/util-linux-2.20.1$ sudo apt-get install libutempter-dev
john@U64D211:~/tmp/util-linux-2.20.1$ ./configure --with-utempter
john@U64D211:~/tmp/util-linux-2.20.1$ make
john@U64D211:~/tmp/util-linux-2.20.1$ cd term-utils/
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ldd ./script
linux-vdso.so.1 =>  (0x00007fff54dff000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f289e635000)
libutempter.so.0 => /usr/lib/libutempter.so.0 (0x00007f289e432000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f289e072000)
/lib64/ld-linux-x86-64.so.2 (0x00007f289e861000)

Teste

Antes de executar script

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:28)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013

Dentro de script

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ./script
Script started, file is typescript
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  2  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/2        0.0.0.0          Sat Jan  5 10:37   still logged in   
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:29)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ exit
exit
Script done, file is typescript

Depois de script end

john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ ls /dev/pts
0  1  5  8  ptmx
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last -i
john     pts/2        0.0.0.0          Sat Jan  5 10:37 - 10:37  (00:00)    
john     pts/0        0.0.0.0          Sat Jan  5 09:09   still logged in   
reboot   system boot  0.0.0.0          Sat Jan  5 09:08 - 10:37  (01:29)    
john     pts/0        0.0.0.0          Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  0.0.0.0          Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013
john@U64D211:~/tmp/util-linux-2.20.1/term-utils$ last
john     pts/2                         Sat Jan  5 10:37 - 10:37  (00:00)    
john     pts/0        :0               Sat Jan  5 09:09   still logged in   
reboot   system boot  3.2.0-35-generic Sat Jan  5 09:08 - 10:38  (01:30)    
john     pts/0        :0               Thu Jan  3 00:50 - 01:42  (00:52)    
reboot   system boot  3.2.0-35-generic Thu Jan  3 00:48 - 01:43  (00:54)    

wtmp begins Tue Jan  1 20:48:28 2013

A causa raiz do nome do host emtpy

E sim, script.c cria a entrada wtmp com nome de host vazio. Observe o seguinte bloco de códigos em util-linux-2.20.1/term-utils/script.c Linha: 245-247

#ifdef HAVE_LIBUTEMPTER
    utempter_add_record(master, NULL);
#endif

Base em libutempter-1.1.5/utempter.h

extern int utempter_add_record (int master_fd, const char *hostname);

Portanto, script.c está passando o nome do host vazio para utempter_add_record .

Backport RedHat

O interessante é que o% upstream util-linux-ng-2.17.2 não suporta libutempter . Parece Redhat decidiu adicionar esse apoio de volta.

john@U64D211:~/tmp/util-linux-ng-2.17.2$ ./configure --help|grep utemp

O comando acima retorna o resultado vazio.

Conclusão

Portanto, a diferença de comportamento entre as duas distros não é um erro, mas uma escolha. O RedHat decidiu suportar esse recurso, enquanto o Debian o ignorava.

    

Answer 2

Isso parece absolutamente intrigante para mim. Ou ele deve usar algum nome DNS ou endereço IP. Eu verifiquei o arquivo last.c também, mas ainda não consigo encontrar por que ele não está mostrando nada. Provavelmente, dado algum tempo, eu posso descobrir a parte sobre 0.0.0.0.

int dns_lookup(char *result, int size, int useip, int32_t *a)
307 {
308     struct sockaddr_in  sin;
309     struct sockaddr_in6 sin6;
310     struct sockaddr     *sa;
311     int         salen, flags;
312     int         mapped = 0;
313 
314     flags = useip ? NI_NUMERICHOST : 0;
315 
316     /*
317      *  IPv4 or IPv6 ?
318      *  1. If last 3 4bytes are 0, must be IPv4
319      *  2. If IPv6 in IPv4, handle as IPv4
320      *  3. Anything else is IPv6
321      *
322      *  Ugly.
323      */
324     if (a[0] == 0 && a[1] == 0 && a[2] == htonl (0xffff))
325         mapped = 1;
326 
327     if (mapped || (a[1] == 0 && a[2] == 0 && a[3] == 0)) {
328         /* IPv4 */
329         sin.sin_family = AF_INET;
330         sin.sin_port = 0;
331         sin.sin_addr.s_addr = mapped ? a[3] : a[0];
332         sa = (struct sockaddr *)&sin;
333         salen = sizeof(sin);
334     } else {
335         /* IPv6 */
336         memset(&sin6, 0, sizeof(sin6));
337         sin6.sin6_family = AF_INET6;
338         sin6.sin6_port = 0;
339         memcpy(sin6.sin6_addr.s6_addr, a, 16);
340         sa = (struct sockaddr *)&sin6;
341         salen = sizeof(sin6);
342     }
343 
344     return getnameinfo(sa, salen, result, size, NULL, 0, flags);
345 }

As duas variáveis globais usadas no contexto são estas.

int usedns = 0;     /* Use DNS to lookup the hostname. */
72 int useip = 0;       /* Print IP address in number format */

Portanto, em teoria, ele deve usar dns ou IP.

Eu vou ver se consigo cavar mais alguma coisa. Mas o que o ewwhite perguntou são questões válidas.

    

Answer 3

Então eu corri por último em um depurador que, esperamos, lhe dará pelo menos algumas respostas à sua pergunta. Meu sentimento é que a causa raiz é mais profunda.

Por que último -i mostra 0.0.0.0 para entradas de linha pts

A melhor maneira de explicar isso é o que acontece quando você não passa -i.

A razão para isso é nesta seção de código de last.c

if (usedns || useip)
  r = dns_lookup(domain, sizeof(domain), useip, p->ut_addr_v6);
if (r < 0) {
   len = UT_HOSTSIZE;
   if (len >= sizeof(domain)) len = sizeof(domain) - 1;
   domain[0] = 0;
   strncat(domain, p->ut_host, len);
}

Tanto usedns quanto useip (usando as opções padrão) não são sinalizados. Isso faz com que a lógica seja copiada da estrutura p->ut_host , que, de acordo com man utmp , contém o nome de login remoto, conforme registrado pelo que quer que tenha sido escrito em utmp .

char ut_host[UT_HOSTSIZE]; /* Hostname for remote login, or
                              kernel version for run-level
                              messages */

No seu caso, o valor aqui é zeros. É por isso que quando você executa last , nada aparece para você.

No caso de last -i , o dns_lookup é invocado. Isto irá passar a entrada (p- > ut_addr_v6) para ser resolvida via DNS. No seu caso, esse valor também contém zeros.

A maior parte de dns_lookup é de fachada e heusterica. Basicamente, o que importa é a função getnameinfo . Esta é uma chamada de biblioteca que, neste caso, fará o possível para resolver o valor binário armazenado no ut_addr_v6 . Quando esta entrada contém zeros (como no seu caso) você está realmente resolvendo isso para 0.0.0.0 como é o que acontece com a sua saída last -i .

Existe alguma coisa (além de atividade maliciosa) que possa explicar o comportamento?

Bem, provavelmente é um bug ou descuido. É improvável que seja malicioso, pois parece estúpido deixar qualquer rastreio como um invasor em vez de omitir um endereço de origem.

O foco das respostas até agora foi olhar para o lugar errado. last apenas lê utmp ou wtmp . No entanto, last está fazendo o melhor possível com os dados que possui.

Sua causa raiz está em algum lugar na maneira como utmp está sendo gravado em !

Embora alguns aplicativos escrevam diretamente em utmp , acho que a origem de seus problemas está no modo como sshd está lidando com o gerenciamento de sessões.

Diferente do timestamping do histórico bash, há outras coisas que posso fazer para rastrear o problema?

utmp não é normalmente gravável e não é para ser. utmp é escrito por aplicativos projetados para você entrar e configurar sua sessão. No seu caso, isso é sshd .

Por que o sshd não está manipulando o seu usuário corretamente é muito estranho, já que ele deve estar copiando adequadamente o nome do host que você veio. É aqui que os esforços de depuração devem ser focados. Comece adicionando a saída de depuração do sshd aos seus logs e veja se algo anômalo aparece.

Se você quiser contornar o problema (ou, talvez até mesmo descobrir mais sobre o problema), você pode usar pam_lastlog para gerenciar utmp adicionando-o à entrada sessão para / etc / pam.d / sshd.

Por uma questão de fato, não vai doer verificar se ele já está lá - porque pam_lastlog contém uma opção nohost que definitivamente explicaria seu comportamento que você está experimentando.

Finalmente, você não pode usar o último. aulast faz o mesmo trabalho por meio do subsistema de auditoria.

Pode valer a pena tentar ver se isso conseguiu, pelo menos, escrever o endereço correto. Se não tiver, então, o seu problema deve estar com o sshd, pois o sshd está passando os nomes do DNS em torno de diferentes subsistemas, como o utmp ou o audit.

    

Answer 4

(1) Base em OP last output

Após o login via ssh, pode-se ssh para localhost e obter 0.0.0.0 em last -i para o último.

Base nas primeiras quatro linhas do log do OP

mpenning pts/19                        Fri Nov 16 10:32 - 10:35  (00:03)
mpenning pts/17                        Fri Nov 16 10:21 - 10:42  (00:21)
bill     pts/15       sol-bill.local   Fri Nov 16 10:19 - 10:36  (00:16)
mpenning pts/1        192.0.2.91       Fri Nov 16 10:17 - 10:49 (12+00:31)

pts/19 log in estava dentro do período de log pts/17 .

pts/17 log in estava dentro do período de log pts/1 .

Para esta ocorrência específica, é lógico supor que o OP ssh de 192.0.2.91 ( pty/1 ), em seguida, dentro dessa sessão ssh, efetue login localmente ( ssh localhost ) no servidor ( pts/17 ), e novamente ( pts/19 ).

Por favor, verifique se esta sobreposição acontece com outra ocorrência.

A seguir pode ajudar a identificar a causa

• Você usa a chave ssh? Em caso afirmativo, no servidor, você configurou a chave ssh para efetuar login localmente?
• Verifique ou poste / var / log / secure do mesmo período de tempo. Pode fornecer alguma sugestão.
• Verifique os scripts que você usa
• Verifique os aliases de shell que você usa
• Verifique seu histórico de comandos

(2) Seção Adicional

Cenário 1 - sudo e terminal

1. Login do usuárioA janela X
2. Abra as janelas de um terminal, faça xhost + localhost
3. su - UserB ou sudo su - UserB , em seguida, abra um novo terminal (xterm, gnome-terminal, etc)
4. UserB será exibido como 0.0.0.0 em last -i

su - UserB não se registrará como UserB login no último, mas abrirá um terminal.

Cenário 2 - login

1. ssh no servidor
2. digite sudo login
3. faça o login como você mesmo
4. verifique last e last -i

last não mostra nenhum nome de host ou IP para o login session . last -i será IP 0.0.0.0 para o login session .

john@U64D211:~$ last -5
john     pts/0                         Sun Dec 23 20:50   still logged in   
john     pts/0                         Sun Dec 23 20:50 - 20:50  (00:00)    
john     pts/0        :0               Sun Dec 23 20:50 - 20:50  (00:00)    
reboot   system boot  3.2.0-35-generic Sun Dec 23 20:49 - 20:50  (00:01)    
john     pts/2        js.example.com   Sun Dec 23 17:14 - crash  (03:34)    

wtmp begins Sat Dec  1 06:30:46 2012
john@U64D211:~$ last -5i
john     pts/0        0.0.0.0          Sun Dec 23 20:50   still logged in   
john     pts/0        0.0.0.0          Sun Dec 23 20:50 - 20:50  (00:00)    
john     pts/0        0.0.0.0          Sun Dec 23 20:50 - 20:50  (00:00)    
reboot   system boot  0.0.0.0          Sun Dec 23 20:49 - 20:50  (00:01)    
john     pts/2        192.168.1.90     Sun Dec 23 17:14 - crash  (03:34)    

wtmp begins Sat Dec  1 06:30:46 2012

A resposta de

Mife já mostra o bloco de código de last.c . O motivo last exibir nome de host / IP vazio é porque ut_host para esses registros estão realmente vazios. Para a estrutura completa do wtmp, faça man wtmp em qualquer sistema linux.

Os dois cenários aqui mostram que mesmo os pacotes padrão, sob certas situações, os criam como tal.

(3) Corte do histórico de hash

Ele só funcionará se a sessão usar bash como shell interativo.

.bashrc e .bash_profile são usados apenas por bash .

Eles não serão originados automaticamente se a sessão usar qualquer outro shell (sh, csh, etc) ou executar o programa diretamente, e não haverá nenhum histórico bash.

(4) Contabilidade do processo

Como o OP não menciona nada sobre o arquivo secure , presumo que seja um beco sem saída e que, na verdade, forneça agora uma dica.

Se a suposição a seguir estiver correta

'last' 0.0.0.0 entries are actually created with in OP own session

auth.log (debian) / secure (CentOS) não ajudará. Como apenas a ação relacionada à autenticação é registrada nela.

wtmp / utmp, com a limitação em sua estrutura de dados, também é um beco sem saída. Não há informações sobre o que os criou.

Isso nos deixa com uma opção, contabilidade do processo . Esta é uma arma grande e tem que ser usada com cautela.

1. Talvez contra a política da empresa
2. Outros usuários em um sistema compartilhado talvez infeliz / desconfortável com isso ativado
3. O arquivo de log pode usar muito espaço em disco. Fique de olho na taxa de crescimento do tamanho do arquivo.

A versão do pacote psacct deve ser 6.3.2-56 ou superior, de acordo com esta postagem .

Se isso for ser usado, e /var/log tiver espaço limitado, altere o arquivo de log acct para um diretório (acesso somente raiz) em /home , que geralmente tem muito mais espaço.

Esta é realmente a grande arma. Com uma taxa de ocorrência de OP 10%, deve haver resultado dentro de uma semana. Se durante esse período, a entrada vazia aparecer em last , mas nada de acct log, ela se tornará uma mistério situação , e exigiria alguma ação drástica .

A seguir, uma saída de amostra de lastcomm

lesspipe               john     pts/8      0.02 secs Mon Dec 24 17:10
lesspipe          F    john     pts/8      0.00 secs Mon Dec 24 17:10
dirname                john     pts/8      0.00 secs Mon Dec 24 17:10
basename               john     pts/8      0.00 secs Mon Dec 24 17:10
kworker/1:2       F    root     __         0.00 secs Mon Dec 24 16:54
tty                    john     pts/6      0.01 secs Mon Dec 24 17:09
tty                    john     pts/4      0.01 secs Mon Dec 24 17:09
cron              F    root     __         0.05 secs Mon Dec 24 17:09
sh               S     root     __         0.01 secs Mon Dec 24 17:09
find                   root     __         0.01 secs Mon Dec 24 17:09
maxlifetime            root     __         0.00 secs Mon Dec 24 17:09
php5                   root     __         0.23 secs Mon Dec 24 17:09
which                  root     __         0.00 secs Mon Dec 24 17:09
lastcomm               root     pts/0      0.01 secs Mon Dec 24 17:08
tty                    john     pts/1      0.01 secs Mon Dec 24 17:08
dconf worker         X john     __         5.46 secs Mon Dec 24 16:58
lastcomm               root     pts/7      0.04 secs Mon Dec 24 17:05
mesg             S     root     pts/7      0.00 secs Mon Dec 24 17:05
bash              F    root     pts/7      0.00 secs Mon Dec 24 17:05
dircolors              root     pts/7      0.00 secs Mon Dec 24 17:05

Você também pode usar 'dump-acct' para mostrar mais informações.

PS1: Eu tentei abrir algumas sessões de terminal e ssh. Não está claro (ou não é fácil apontar) o que abre um novo pts. No entanto, ele mostra tudo o que foi executado dentro daquele pts / sessão.

PS2: Um blog postar sobre o uso do acct por um Mike.

    

Answer 5

Quando você faz login em uma Máquina, estas podem ser algumas entradas no último comando.

geekride   tty2                        Fri Dec 21 15:45 - 15:45  (00:00)    
geekride   pts/1                       Fri Dec 21 13:45   still logged in   
geekride   pts/1        :pts/0:S.0     Thu Dec  6 12:49 - 00:40  (11:50)    
geekride   pts/1        10.31.33.47    Thu Dec  6 12:49 - 00:40  (11:50)    

A primeira entrada com tty * vem quando você faz o login através do terminal ou console pressionando CTRL + ALT + F1-6. É bastante claro do terminal que está usando.

A segunda entrada normalmente entra em cena quando você entra em uma máquina e abre uma janela de terminal na GUI. Haverá também uma entrada mesmo se você abrir uma nova aba na mesma janela de terminal.

O terceiro tipo de entrada vem quando você abre uma sessão de tela depois de logar no SSH. Isso também criará uma entrada lá e sem nenhum endereço IP.

A quarta entrada é bem normal e todos entendem.

Se você last -i com as seguintes entradas, você verá algo assim:

geekride   tty2         0.0.0.0        Fri Dec 21 15:45 - 15:45  (00:00)    
geekride   pts/9        0.0.0.0        Fri Dec 21 13:45   still logged in   
geekride   pts/1        0.0.0.0        Thu Dec  6 12:49 - 00:40  (11:50)    

Tenho quase certeza de que seu caso vem em qualquer um dos dois casos, um com o terminal Window na GUI e o outro com a sessão de tela.

Espero que isso tenha ajudado.

    

Answer 6

Eu não acho que vamos chegar longe com isso sem depurar last.c, mas isso não deve ser difícil, já que compila ...

Uma possibilidade é despejar o arquivo / var / log / wtmp usando o utmpdump comando e dê uma olhada nos registros brutos isso pode lançar alguma luz para você. Se não, por favor poste alguma saída relevante de

utmpdump /var/log/wtmp 

para que possamos recriar cópias locais do seu wtmp para depurar com

utmpdump -r <dumpfile >wtmp

    

Answer 7

Eu verifiquei em 12 servidores de aplicativos multi-usuário CentOS e RHEL 6.3. Nenhum exibiu esse comportamento. Não houve entradas em falta na saída last , voltando 4-5 semanas.

Acho que seria importante ver sua entrada de arquivo /etc/hosts para garantir que está de acordo com este formato .

Além disso, o que você está fazendo para a resolução de DNS? Você pode postar seu /etc/resolv.conf ?

As outras respostas indicando que 0.0.0.0 representa as conexões locais estão corretas. Os exemplos típicos são eventos de login de reinicialização e console:

 reboot   system boot  0.0.0.0          Sat Dec  8 06:12 - 05:57 (12+23:45)  
 reboot   system boot  0.0.0.0          Sat Dec  8 05:25 - 06:09  (00:44)    
 reboot   system boot  0.0.0.0          Fri Nov 30 14:28 - 05:22 (7+14:54)   
 root     tty1         0.0.0.0          Fri Nov 30 13:52 - 13:55  (00:03)    
 reboot   system boot  0.0.0.0          Fri Nov 30 13:51 - 14:25  (00:34)    

Já que isso parece ocorrer apenas com usuários nomeados, existe alguma mudança? Há algo estranho sendo originado ou executado em seus scripts de login? Você alterou ~/.bashrc ou ~/.bash_profile do padrão? Existem outros scripts de login especiais no ambiente?

- Editar -

Ainda não consigo reproduzir isso de maneira alguma. Eu olho para dois componentes críticos, no entanto. O comando last é estável e não foi alterado em muito tempo. Olhando para o changelog para sysvinit-tools , não há erros relevantes. O mesmo para initscripts (wtmp).

Se for possível forçar isso, experimente-o com uma conta de usuário diferente das mesmas máquinas de origem. Mas não vejo qualquer indicação de que este seja um problema do SO.

    

Answer 8

RESOLUÇÃO FINAL

Eu já ganhei o bônus, então isso é apenas para futuros googlers com a mesma pergunta.

A razão pela qual isso só aparece em ~ 10% dos meus logins é porque quando eu faço grandes mudanças em nossos roteadores ou switches, eu uso script foo.log , então eu tenho um log de terminal completo da mudança. Por razões que ainda não entendi, o CentOS cria uma entrada pts quando você usa o comando script ... Eu demonstrarei a saída de last -i antes e depois de executar script ...

[mpenning@sasmars net]$ last -i | head
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
mpenning pts/14       192.0.2.91    Thu Dec 27 08:31 - 08:32  (00:00)
[mpenning@sasmars net]$ script ~/something_random.log
Script started, file is /home/mpenning/something_random.log
[mpenning@sasmars net]$ date
Thu Jan  3 16:14:19 CST 2013 # <--------------------------------------------------
[mpenning@sasmars net]$ exit
exit
Script done, file is /home/mpenning/something_random.log
[mpenning@sasmars net]$ last -i | head
mpenning pts/15       0.0.0.0          Thu Jan  3 16:14 - 16:14  (00:00) # <------
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
[mpenning@sasmars net]$ cat /etc/redhat-release
CentOS release 6.3 (Final)
[mpenning@sasmars net]$

Este comportamento parece ser único para o CentOS 6 ... nós temos algumas máquinas CentOS 4.7 no laboratório que não colocam uma entrada em branco em wtmp ... Máquinas Debian / Gentoo também não exibem este comportamento . Nossos administradores do linux estão coçando a cabeça porque o CentOS intencionalmente adicionaria outra entrada pts quando você executasse script ... Eu suspeito que esse seja um bug do RHEL.

EDIT : Eu arquivei este problema como RHEL Bug id 892134

NOTA

Algumas pessoas erroneamente assumiram que coloquei script no meu ~/.bashrc ou ~/.bash_profile . Este é um argumento falho ... se isso fosse verdade, meu wtmp deveria ter uma entrada 0.0.0.0 após cada um dos meus logins ssh ...

[mpenning@sasmars net]$ last -i | head
kkim14   pts/13       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/12       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/10       192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/9        192.0.2.225   Wed Jan  2 09:43   still logged in
kkim14   pts/5        192.0.2.225   Wed Jan  2 09:43   still logged in
mpenning pts/18       0.0.0.0       Mon Dec 31 16:45 - 16:49  (00:03)  # <-----
mpenning pts/17       192.0.2.29    Mon Dec 31 16:45 - 16:49  (00:03)  # <-----
gduarte  pts/16       192.0.2.135   Thu Dec 27 10:54   still logged in
gduarte  pts/14       192.0.2.135   Thu Dec 27 10:44   still logged in
dspencer pts/14       192.0.2.4     Thu Dec 27 09:56 - 09:57  (00:01)
mpenning pts/15       0.0.0.0       Thu Dec 27 08:31 - 08:32  (00:00)  # <-----
mpenning pts/14       192.0.2.91    Thu Dec 27 08:31 - 08:32  (00:00)  # <-----

Claro, não foi esse o caso ...

    

Answer 9

Conexões Pseudo Terminal Slave (pts) são conexões SSH ou telnet que significam conexões indiretas ao sistema. Todas essas conexões podem se conectar a um shell que permitirá a emissão de comandos para o computador. Então quando você abre um terminal no seu sistema a partir do gui, ele abre um pts com o ip fonte 0.0.0.0. A partir das informações fornecidas por você, parece que isso acontece por causa do script em execução neste servidor ou agendado, que está usando o serviço ssh ou telnet ou pts locais para lançar a saída no terminal.

    

Answer 10

Qual cliente do ssh você usa? Alguns clientes ssh podem multiplexar múltiplos terminais através de uma conexão e noto que todas as suas sessões sem IP estão dentro de sessões mais longas que possuem um IP registrado.

Eu não posso duplicar esse comportamento com o ssh aqui.

    

Answer 11

Talvez o seu endereço IP resolva para uma string em branco em um de seus servidores DNS, provavelmente o secundário, se acontecer apenas 10% do tempo (ou possivelmente um arquivo hosts, se forem distribuídos de um repositório central). Isso explicaria a entrada ausente (ou espaço em branco) e seria consistente com a leitura da fonte por Soham.

    

Answer 12

"0.0.0.0" significa que é um usuário local (não um login remoto), provavelmente chamado por aplicativo, por exemplo, cronjob.

    

Answer 13

Isso acontece porque você usa o sistema local e 0.0.0.0 significa endereço IP de todas as interfaces. Se você acha que alguém pode tê-lo hackeado, tente configurar o registro completo do shell, incluindo comandos via ssh - link

    

Answer 14

Eu resolvi adicionando um script para ~ / .bashrc o script encontra o último endereço IP da origem da conexão telnet, Então você pode adicionar o IP a um arquivo de log ou fazer o que precisar ..

client_ip=$(echo $(netstat -nae | grep $(netstat -nae | grep 23 | awk  '{print $8}' | sort -n | tail -n1) | awk '{print $5}') | awk -F':' '{print $1}' )

echo "client_ip=$client_ip"

Sharon