Eu tenho cinco sistemas Linux CentOS 6 em funcionamento e encontrei um problema bastante estranho que parece acontecer apenas com meu ID de usuário em todos os sistemas Linux que tenho ... Este é um exemplo do problema das entradas que eu excluí do lastcomando .. .

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 possuem um endereço IP de origem associado a elas. Minhas máquinas CentOS têm até seis outros usuários que compartilham os sistemas. Aproximadamente 10% dos meus logons veem esse problema, mas nenhum outro nome de usuário exibe esse comportamento . Não há entrada /var/log/securepara as entradas sem um endereço IP de origem.

Questões

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

• Por que last -imostrar 0.0.0.0para entradas de linha pts (também veja esta resposta )
• Existe algo (que não seja atividade maliciosa) que explique razoavelmente o comportamento?
• Além do registro de data e hora do histórico do bash, existem outras coisas que posso fazer para rastrear o problema?

Informativo

Desde que isso começou a acontecer, ativei o bashregistro de data e hora do histórico (por exemplo, HISTTIMEFORMAT="%y-%m-%d %T "in .bash_profile) e também adicionei alguns outros hacks do histórico do bash ; no entanto, isso não fornece pistas sobre o que aconteceu nas ocorrências anteriores.

Todos os sistemas executam 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)

Nota para aqueles que tentam responder: Eu não me conectei com o screencomando ou a GUI . Todos os meus logins são do SSH; para receber o prêmio de recompensa, você deve citar referências autorizadas para explicar as last -i 0.0.0.0entradas originadas apenas via SSH.

EDIT 2 (para perguntas de ewwhite)

/etc/resolv.conf(observe que usei .localendereços na lastsaída 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 existe apenas 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]$

sftpSaí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

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

Com base no código-fonte upstream , scriptde ambas as versões, abra um novo pty. 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 scriptabriu um novo pts (2). Apenas não foi atualizado /var/log/wtmp.

CentOS 6

Estou pulando o teste, pois já sabemos que scripto pty aberto é registrado e o wtmp.

libutemper

• Projeto: http://freecode.com/projects/libutempter
• 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) CentOS scriptvinculada.

Teste com o Ubuntu 12.04

Compilando scriptcom 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 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 do scriptfim

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.ccrie a wtmpentrada com o nome do host vazio. Veja o seguinte bloco de código na util-linux-2.20.1/term-utils/script.cLinha: 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);

Então, script.cna verdade, está passando o nome do host vazio para utempter_add_record.

RedHat Backport

O interessante é que a montante, util-linux-ng-2.17.2na verdade, não suporta libutempter. Parece Redhat decidiu adicionar esse suporte 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 dar suporte a esse recurso, enquanto o Debian o ignorou.

Isso parece absolutamente intrigante para mim. Ou ele deve usar algum nome DNS ou endereço IP. Também verifiquei o last.carquivo, mas ainda não consigo descobrir por que ele não está mostrando nada. Provavelmente, com algum tempo, 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 essas.

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.

Vou ver se consigo cavar mais alguma coisa. Mas o que ewwhite perguntou são perguntas válidas.

Então, eu corri pela última vez em um depurador que, esperançosamente, fornecerá pelo menos algumas respostas para sua pergunta. Meu sentimento é que a causa raiz é mais profunda.

Por que last -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 em -i.

O motivo disso está 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);
}

Ambos usednse useip(usando as opções padrão) não são sinalizados. Isso faz com que a lógica copie a estrutura p->ut_hostque, de acordo com, man utmpcontém o nome de login remoto, conforme registrado por qualquer coisa gravada no arquivo utmp.

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

No seu caso, o valor aqui é zero. É por isso que, quando você executa, lastnada aparece para você.

No caso de, last -ientão dns_lookup é chamado. Isso passará a entrada (p-> ut_addr_v6) a ser resolvida via DNS. No seu caso, esse valor também contém zeros.

A maioria dns_lookupé de janela e heusteric. Basicamente, o que importa é a função getnameinfo. Esta é uma chamada de biblioteca que, neste caso, tentará o melhor para resolver o valor binário armazenado no ut_addr_v6. Quando essa entrada contém zeros (como no seu caso), você está realmente resolvendo isso, 0.0.0.0como é o que acontece com sua last -isaída.

Existe algo (que não seja atividade maliciosa) que explique razoavelmente o comportamento?

Bem, provavelmente é um bug ou supervisão. Sua improvável que seja malicioso, já que parece estúpido para deixar qualquer vestígio como atacante ao invés de omitir um endereço de origem.

Até agora, o foco das respostas foi procurar o lugar errado. lastapenas lê utmpou wtmp. No entanto, lastestá fazendo o melhor possível com os dados que possui.

Sua causa raiz está em algum lugar da maneira como utmpestá sendo escrita !

Enquanto alguns aplicativos escrevem diretamente, utmpacho que a origem dos seus problemas está no modo sshdcomo lida com o gerenciamento de sessões.

Além do registro de data e hora do histórico do bash, existem outras coisas que posso fazer para rastrear o problema?

utmpnormalmente não é gravável e não deve ser. utmpé escrito por aplicativos projetados para fazer login e configurar sua sessão. No seu caso, é isso sshd.

Por que o sshd não está manipulando seu usuário corretamente é muito estranho, pois deveria estar copiando corretamente o nome do host de onde você veio. É aqui que os esforços de depuração provavelmente 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ê deseja solucionar o problema (ou, talvez até descobrir mais sobre o problema), pode usá-lo pam_lastlogpara gerenciar utmpadicionando-o à entrada da sessão em /etc/pam.d/sshd.

Por uma questão de fato, não será difícil verificar se ele já está lá - porque pam_lastlogcontém uma nohostopção que definitivamente explicaria seu comportamento que você está enfrentando.

Finalmente, você não pode usar o último. aulastfaz o mesmo trabalho através do subsistema de auditoria.

Pode valer a pena tentar ver se isso conseguiu escrever pelo menos o endereço correto. Caso contrário, seu problema deve estar com o sshd, pois o sshd passa os nomes DNS por diferentes subsistemas, como utmp ou audit.

(1) Base na lastsaída OP

Após o login via ssh, é possível ssh no localhost e obter 0.0.0.0 last -ipara o posterior.

Baseie-se nas quatro primeiras 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/19o login estava dentro pts/17do período de login.

pts/17o login estava dentro pts/1 do período de login.

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

Verifique se essa sobreposição acontece com outra ocorrência.

A seguir, pode ajudar a identificar a causa

• Você usa ssh-key? Em caso afirmativo, no servidor, você configurou o ssh-key para efetuar login localmente?
• Verifique ou publique / var / log / secure no mesmo período. Pode fornecer algumas dicas.
• Verifique os scripts que você usa
• Verifique os aliases de shell que você usa
• Verifique seu histórico de comandos

(2) Secnario adicional

Cenário 1 - sudo e terminal

1. Janela X de login do usuário
2. Abra as janelas de um terminal, faça xhost + localhost
3. su - UserBou sudo su - UserBabra um novo terminal (xterm, gnome-terminal, etc)
4. UserB aparecerá como 0.0.0.0 em last -i

su - UserBnão se registrará como um UserBlogin por último, mas abrir um terminal fará.

Cenário 2 - login

1. ssh no servidor
2. tipo sudo login
3. faça login como você
4. verifique lastelast -i

lastnão mostre nenhum nome de host ou IP para o login session. last -iIP 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 para lastexibir o nome do host / IP vazio é porque, ut_hostna verdade, esses registros estão vazios. Para uma estrutura wtmp completa, faça man wtmpem qualquer sistema Linux.

Os 2 cenários aqui mostram que mesmo pacotes padrão, sob determinada situação, os criam como tal.

(3) Corte do histórico do Bash

Só funcionará se a sessão for usada bashcomo shell interativo.

.bashrce .bash_profilesão usados ​​apenas por bash.

Eles não serão fornecidos automaticamente se a sessão usar outro shell (sh, csh, etc) ou executar o programa diretamente, e também não haverá histórico do bash.

(4) Contabilidade de processos

Como o OP não menciona nada sobre o securearquivo, assumirei que esse é um beco sem saída e, na verdade, ele fornece agora uma dica.

Se a seguinte suposição 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.

O 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 de processo . Esta é uma arma grande e deve ser usada com cautela.

1. Talvez contra a política da empresa
2. Outros usuários em um sistema compartilhado podem ficar descontentes / desconfortáveis ​​com ele 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 publicação .

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

Esta é realmente a grande arma. Com a taxa de ocorrência de OP 10%, deve haver resultado dentro de uma semana. Se durante esse período, a entrada vazia aparecer, lastmas nada no registro de contas, se tornar uma situação misteriosa e exigir alguma ação drástica .

A seguir, é apresentada uma amostra de saída 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: Tentei abrir algumas sessões de terminal e ssh. Não está claro (ou não é fácil identificar) o que abre um novo pts. No entanto, mostra tudo o que foi executado nessa pts / sessão.

PS2: Um blogue post sobre como usar acct por um Mike.

Quando você faz login em uma máquina, essas podem ser poucas 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 * ocorre quando você faz login no terminal ou console pressionando CTRL + ALT + F1-6. É bem claro a partir do terminal que está usando.

A segunda entrada normalmente aparece quando você faz login em uma máquina e abre uma janela de terminal na GUI. Também haverá uma entrada, mesmo se você abrir uma nova guia na mesma janela do terminal.

O terceiro tipo de entrada ocorre quando você abre uma sessão de tela após o logon no SSH. Isso também criará uma entrada lá e sem nenhum endereço IP.

A quarta entrada é bastante normal, que todo mundo entende.

Se você fizer last -ias seguintes entradas, verá algo parecido com isto:

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 o seu caso se encaixa em qualquer um dos dois casos, um com a janela Terminal na GUI e o outro com a sessão de tela.

Espero que isso tenha ajudado.

Eu não acho que vamos chegar longe com isso sem depurar last.c, mas isso não deve ser tão difícil quanto compilar rapidamente ...

Uma possibilidade, porém, é despejar o arquivo / var / log / wtmp usando o comando utmpdump e dar uma olhada nos registros brutos, pois isso pode trazer alguma luz para você. Caso contrário, envie 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

Eu verifiquei em 12 servidores de aplicativos baseados em CentOS e RHEL 6.3 para vários usuários. Nenhum exibiu esse comportamento. Não havia entradas ausentes na lastsaída, retornando 4-5 semanas.

Eu acho que seria importante ver a /etc/hostsentrada do seu arquivo para garantir que esteja em conformidade com este formato .

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

As outras respostas indicando que 0.0.0.0representam conexões locais estão corretas. Os exemplos típicos são eventos de reinicialização e login do 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)    

Como isso parece ocorrer apenas com usuários nomeados, há alguma alteração de algo estranho que está sendo originado ou executado em seus scripts de logon? Você mudou ~/.bashrcou foi o ~/.bash_profilepadrão? Existem outros scripts de login especiais no ambiente?

--Editar--

Ainda não consigo reproduzir isso de nenhuma maneira. Eu olho para dois componentes críticos, no entanto. O lastcomando é estável e não foi alterado há muito tempo. Olhando para o changelog de ferramentas sysvinit , não há bugs relevantes. O mesmo para initscripts (wtmp).

Se você pode forçar isso, tente com uma conta de usuário diferente das mesmas máquinas de origem. Mas não vejo nenhuma indicação de que esse seja um problema do sistema operacional.

RESOLUÇÃO FINAL

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

A razão pela qual isso aparece apenas em ~ 10% dos meus logins é porque, quando faço grandes alterações em nossos roteadores ou switches, uso-o script foo.logpara ter um log de terminal completo da alteração. Por razões que ainda não entendi, o CentOS cria uma ptsentrada quando você usa o scriptcomando ... Demonstrarei a saída de last -iantes e depois da execução 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]$

Esse comportamento parece exclusivo do CentOS 6 ... temos algumas máquinas CentOS 4.7 em laboratório que não colocam uma entrada em branco em wtmp... As máquinas Debian / Gentoo também não apresentam esse comportamento. Nossos administradores de linux estão coçando a cabeça porque o CentOS adicionaria intencionalmente outra ptsentrada quando você executa script... Suspeito que seja um bug do RHEL.

Edição : Arquivei este problema como RHEL Bug id 892134

NOTA

Algumas pessoas assumiram erroneamente que eu coloquei scriptno meu ~/.bashrcou ~/.bash_profile. Este é um argumento defeituoso ... se isso fosse verdade, eu wtmpdeveria ter uma 0.0.0.0entrada 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 ...

As conexões do pseudo terminal escravo (pts) são conexões SSH ou telnet, o que significa conexões indiretas ao sistema. Todas essas conexões podem se conectar a um shell que permitirá que você emita comandos para o computador. Portanto, quando você abre um terminal em seu sistema a partir da GUI, ele abre um pts com o ip 0.0.0.0 de origem. A partir das informações fornecidas por você, parece que isso está acontecendo devido ao script em execução neste servidor ou agendado, que está usando o serviço ssh ou telnet ou pontos locais para lançar a saída no terminal.

Qual cliente ssh você usa? Alguns clientes ssh podem multiplexar vários terminais em uma conexão, e percebo que todas as suas sessões sem IP se enquadram em sessões mais longas que possuem um IP registrado.

Não consigo duplicar esse comportamento com o ssh aqui.

Talvez o seu endereço IP resolva uma sequência em branco em um de seus servidores DNS, provavelmente o secundário, se isso acontecer apenas 10% das vezes (ou possivelmente um arquivo de host, se estes forem distribuídos a partir 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.

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

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 talvez alguém tenha hackeado, tente configurar o log completo do shell, incluindo comandos via ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Eu o resolvi adicionando um script ao ~ / .bashrc, o script encontra o último endereço IP de origem da conexão telnet. Depois, 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