J'ai cinq systèmes Linux CentOS 6 au travail et j'ai rencontré un problème assez étrange qui ne semble se produire qu'avec mon ID utilisateur sur tous les systèmes Linux que j'ai ... Ceci est un exemple du problème des entrées que j'ai excepté de la lastcommande .. .

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)

Vous pouvez voir deux de mes entrées de connexion pts ci-dessus qui ne sont pas associées à une adresse IP source. Mes machines CentOS ont jusqu'à six autres utilisateurs qui partagent les systèmes. Environ 10% de mes connexions voient ce problème, mais aucun autre nom d'utilisateur ne présente ce comportement . Il n'y a pas d'entrée /var/log/securepour les entrées sans adresse IP source.

Des questions

Compte tenu du type de scripts que je garde sur ces systèmes (qui contrôlent une grande partie de notre infrastructure réseau), je suis un peu effrayé par cela et j'aimerais comprendre ce qui pourrait amener mes connexions à manquer occasionnellement des adresses source.

• Pourquoi last -is'affiche 0.0.0.0pour les entrées de ligne pts (voir également cette réponse )
• Y a-t-il quelque chose (autre qu'une activité malveillante) qui pourrait raisonnablement expliquer le comportement?
• Outre l'horodatage de l'historique bash, puis-je faire d'autres choses pour suivre le problème?

Informatif

Depuis que cela a commencé, j'ai activé l' bashhorodatage de l'historique (c'est- HISTTIMEFORMAT="%y-%m-%d %T "à- dire dans .bash_profile) et j'ai également ajouté quelques autres hacks d'historique bash ; cependant, cela ne donne pas d'indices sur ce qui s'est passé lors des événements précédents.

Tous les systèmes exécutent 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 ~]$

ÉDITER

Si j'utilise last -i mpenning, je vois des entrées comme celle-ci ...

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)

Remarque pour ceux qui tentent de répondre: je ne me suis pas connecté avec la screencommande ou l'interface graphique . Toutes mes connexions proviennent de SSH; pour recevoir le prix, vous devez citer des références faisant autorité pour expliquer les last -i 0.0.0.0entrées provenant uniquement via SSH.

EDIT 2 (pour les questions d'ewwhite)

/etc/resolv.conf(notez que j'ai utilisé des .localaddrs dans la lastsortie ci-dessus pour masquer les informations de mon entreprise)

[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 (notez que ce fichier d'hôtes personnalisé n'existe que sur l'une des machines qui a ces problèmes)

[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]$

sftpSortie 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)

RÉSOLUTION FINALE

Voir ma réponse ci-dessous

script différences de comportement entre RedHat et Debian

Bibliothèques liées

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 sur le code source en amont , scriptdes deux versions ouvrent un nouveau pty. Voici le test.

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$ 

Ubuntu 12.04 scripta ouvert un nouveau pts (2). Il n'a tout simplement pas été mis à jour /var/log/wtmp.

CentOS 6

Je saute le test car nous savons déjà qu'il scriptfaut ouvrir pty et s'enregistrer avec wtmp.

libutemper

• Projet: http://freecode.com/projects/libutempter
• Description: libutempter fournit une interface de bibliothèque pour les émulateurs de terminaux tels que screen et xterm pour enregistrer des sessions utilisateur dans des fichiers utmp et wtmp.

La principale différence semble donc être la bibliothèque supplémentaire ( libutempter.so.0) avec laquelle CentOS est scriptlié.

Testez avec Ubuntu 12.04

Compiler scriptavec 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)

Essai

Avant de courir 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

Dans 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

Après la scriptfin

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

La cause première du nom d'hôte emtpy

Et oui, script.ccréez l' wtmpentrée avec un nom d'hôte vide. Regardez le bloc de code suivant dans la util-linux-2.20.1/term-utils/script.cligne: 245-247

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

Baser sur libutempter-1.1.5/utempter.h

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

Il en script.cest de même en passant un nom d'hôte vide dans utempter_add_record.

RedHat Backport

La chose intéressante est que l'amont util-linux-ng-2.17.2ne prend pas en charge libutempter. Il semble que Redhat ait décidé de rajouter ce soutien.

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

La commande ci-dessus renvoie un résultat vide.

Conclusion

La différence de comportement entre les deux distributions n'est donc pas un bug, mais un choix. RedHat a décidé de prendre en charge cette fonctionnalité, tandis que Debian l'a ignorée.

Cela me semble absolument déroutant. Soit il doit utiliser un nom DNS ou une adresse IP. J'ai également vérifié le last.cfichier, mais je ne trouve toujours pas pourquoi il ne montre rien. Compte tenu probablement d'un certain temps, je peux comprendre la partie sur 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 }

Les deux variables globales utilisées dans le contexte sont les suivantes.

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

Donc, en théorie, il devrait utiliser le DNS ou IP.

Je vais voir si je peux creuser plus loin. Mais ce que ewwhite a demandé sont des questions valables.

J'ai donc couru en dernier dans un débogueur qui, espérons-le, vous donnera au moins quelques réponses à votre question. Mon sentiment est que la cause profonde est plus profonde.

Pourquoi last -i affiche 0.0.0.0 pour les entrées de ligne pts

La meilleure façon d'expliquer cela est ce qui se passe lorsque vous ne réussissez pas -i.

La raison en est dans cette section de code 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);
}

Les deux usednset useip(en utilisant les options par défaut) ne sont pas marqués. Cela provoque la logique à copier hors de la structure p->ut_hostqui, selon, man utmpcontient le nom de connexion à distance tel qu'enregistré par tout ce qui a été écrit dans le utmp.

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

Dans votre cas, la valeur ici est des zéros. C'est pourquoi, lorsque vous exécutez, lastrien ne s'affiche pour vous.

Dans ce cas, last -idns_lookup est invoqué. Cela passera l'entrée (p-> ut_addr_v6) à résoudre via DNS. Dans votre cas, cette valeur contient également des zéros.

L'essentiel dns_lookupest l'habillage de fenêtre et heustérique. Ce qui compte, c'est la fonction getnameinfo. Il s'agit d'un appel de bibliothèque qui dans ce cas fera de son mieux pour résoudre la valeur binaire stockée dans le ut_addr_v6. Lorsque cette entrée contient des zéros (comme dans votre cas), vous résolvez 0.0.0.0en fait ce qui se passe avec votre last -isortie.

Y a-t-il quelque chose (autre qu'une activité malveillante) qui pourrait raisonnablement expliquer le comportement?

Eh bien, c'est probablement un bug ou une erreur. Il est peu probable qu'il soit malveillant, car il semble stupide de laisser une trace en tant qu'attaquant plutôt que d'omettre une adresse source.

Jusqu'à présent, les réponses se sont concentrées sur le mauvais endroit. lastlit simplement utmpou wtmp. Cependant lastfait de son mieux avec les données dont il dispose.

Votre cause profonde se situe quelque part dans la manière d' utmpécrire !

Bien que quelques applications écrivent directement, utmpje suppose que la source de vos problèmes réside dans la manière de sshdgérer la gestion des sessions.

Outre l'horodatage de l'historique bash, puis-je faire d'autres choses pour suivre le problème?

utmpn'est généralement pas accessible en écriture et n'est pas censé l'être. utmpest écrit par des applications conçues pour vous connecter et configurer votre session. Dans votre cas, c'est le cas sshd.

Pourquoi sshd ne gère pas correctement votre utilisateur est très étrange car il devrait être copié correctement dans le nom d'hôte d'où vous venez. C'est là que les efforts de débogage devraient probablement être concentrés. Commencez par ajouter la sortie de débogage de sshd à vos journaux et voyez si quelque chose d'anormal se présente.

Si vous souhaitez contourner le problème (ou, peut-être même éventuellement en savoir plus sur le problème), vous pouvez l'utiliser pam_lastlogpour le gérer utmpen l'ajoutant à l' entrée de session dans /etc/pam.d/sshd.

En fait, cela ne fera pas de mal de vérifier s'il est déjà là - car pam_lastlogcontient une nohostoption qui expliquerait certainement votre comportement que vous rencontrez.

Enfin, vous ne pouviez pas utiliser du tout. aulastfait le même travail via le sous-système d'audit.

Cela pourrait valoir la peine d'essayer de voir si cela a réussi à au moins écrire la bonne adresse. Si ce n'est pas le cas, votre problème doit être avec sshd car sshd transmet les noms DNS autour de différents sous-systèmes comme utmp ou audit.

(1) Base sur la lastsortie OP

Après vous être connecté via ssh, on peut ssh vers localhost et obtenir 0.0.0.0 last -ipour la dernière.

Base sur les quatre premières lignes du journal 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/19la connexion était dans pts/17la période de connexion.

pts/17la connexion était dans pts/1 la période de connexion.

Pour cette occurrence spécifique, il est logique de deviner que OP ssh de 192.0.2.91 ( pty/1), puis dans cette session ssh, connectez-vous localement ( ssh localhost) au serveur à nouveau ( pts/17) et à nouveau ( pts/19).

Veuillez vérifier si ce chevauchement se produit avec une autre occurrence.

Ce qui suit peut aider à identifier la cause

• Utilisez-vous ssh-key? Si oui, sur le serveur, avez-vous configuré ssh-key pour vous connecter localement?
• Vérifiez ou affichez / var / log / secure du même laps de temps. Cela peut fournir un indice.
• Vérifiez les scripts que vous utilisez
• Vérifiez les alias de shell que vous utilisez
• Vérifiez l'historique de vos commandes

(2) Secnario supplémentaire

Scénario 1 - Sudo et terminal

1. UtilisateurA login X Window
2. Ouvrez une fenêtre de terminal, faites xhost + localhost
3. su - UserBou sudo su - UserBalors ouvrez un nouveau terminal (xterm, gnome-terminal, etc.)
4. UserB apparaîtra comme 0.0.0.0 dans last -i

su - UserBne s'enregistrera pas en tant que UserBlogin en dernier, mais l'ouverture d'un terminal le fera.

Scénario 2 - connexion

1. ssh dans le serveur
2. type sudo login
3. connectez-vous en tant que vous
4. vérifier lastetlast -i

lastn'afficher aucun nom d'hôte ou IP pour le login session. last -iIP 0.0.0.0 pour le 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

La réponse de Mife montre déjà un bloc de code de last.c. La raison pour laquelle le lastnom d'hôte / IP vide est dû ut_hostau fait que ces enregistrements sont en fait vides. Pour une structure wtmp complète, faites man wtmpsur n'importe quel système Linux.

Les 2 scénarios ici montrent que même les packages standard, dans certaines situations, les créent en tant que tels.

(3) Bash History Hack

Cela ne fonctionnera que si la session est utilisée bashcomme shell interactif.

.bashrcet .bash_profilene sont utilisés que par bash.

Ils ne seront pas fournis automatiquement si la session utilise un autre shell (sh, csh, etc.) ou exécute directement un programme, et il n'y aura pas non plus d'historique bash.

(4) Comptabilité des processus

Étant donné que OP ne mentionne rien au sujet du securefichier, je suppose que c'est une impasse et qu'il fournit actuellement un indice.

Si l'hypothèse suivante est correcte

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

auth.log (debian) / secure (CentOS) n'aidera pas. Comme seule l'action liée à l'authentification y est enregistrée.

wtmp / utmp, avec la limitation de leur structure de données, est également une impasse. Il n'y a aucune information sur ce qui les a créés.

Cela nous laisse avec une option, la comptabilité des processus . C'est un gros pistolet et doit être utilisé avec prudence.

1. Peut-être contre la politique de l'entreprise
2. D'autres utilisateurs sur un système partagé peuvent être mécontents / mal à l'aise avec l'activation
3. Le fichier journal peut utiliser beaucoup d'espace disque. Gardez un œil sur le taux de croissance de la taille des fichiers.

La version du package psacct devrait être 6.3.2-56 ou supérieure, selon cet article .

Si celui-ci doit être utilisé et /var/logdispose d'un espace limité, remplacez le fichier journal acct par un répertoire (accès root uniquement) sous /home, qui a généralement beaucoup plus d'espace.

C'est vraiment le gros canon. Avec un taux d'occurrence de 10% OP, il devrait y avoir un résultat dans la semaine. Si pendant cette période, une entrée vide apparaît lastmais rien dans le journal des comptes, cela devient une situation mystérieuse et nécessiterait une action drastique .

Voici un exemple de sortie 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

Vous pouvez également utiliser «dump-acct» pour afficher plus d'informations.

PS1: J'ai essayé d'ouvrir quelques terminaux et session ssh. Il n'est pas clair (ou difficile à cerner) ce qui ouvre un nouveau pts. Cependant, il montre tout ce qui s'est déroulé dans ce pts / session.

PS2: un article de blog sur l'utilisation de acct par un Mike.

Lorsque vous vous connectez à une machine, il peut s'agir de quelques entrées dans la dernière commande.

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)    

La première entrée avec tty * apparaît lorsque vous vous connectez via le terminal ou la console en appuyant sur CTRL + ALT + F1-6. C'est assez clair depuis le terminal qu'il utilise.

La deuxième entrée apparaît normalement lorsque vous vous connectez à une machine et ouvrez une fenêtre de terminal dans l'interface graphique. Il y aura également une entrée même si vous ouvrez un nouvel onglet dans la même fenêtre de terminal.

Le troisième type d'entrée survient lorsque vous ouvrez une session d'écran après vous être connecté via SSH. Cela créera également une entrée là-bas et sans aucune adresse IP.

La quatrième entrée est assez normale, ce que tout le monde comprend.

Si vous le faites last -iavec les entrées suivantes, vous verrez quelque chose comme ceci:

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)    

Je suis à peu près sûr que votre cas se présente dans l'un des 2 cas, l'un avec la fenêtre du terminal dans l'interface graphique et l'autre avec la session d'écran.

J'espère que cela a aidé.

Je ne pense pas que nous allons aller loin avec cela sans déboguer last.c, mais cela ne devrait pas être trop difficile car il se compile facilement ...

Une possibilité est cependant de vider le fichier / var / log / wtmp à l'aide de la commande utmpdump et de jeter un œil aux enregistrements bruts, cela peut vous éclairer. Sinon, veuillez publier une sortie pertinente de

utmpdump /var/log/wtmp 

afin que nous puissions recréer des copies locales de votre wtmp pour déboguer avec

utmpdump -r <dumpfile >wtmp

J'ai vérifié sur 12 serveurs d'applications multi-utilisateurs CentOS et RHEL 6.3. Aucun n'a montré ce comportement. Il n'y avait aucune entrée manquante dans la lastproduction remontant à 4-5 semaines.

Je pense qu'il serait important de voir votre /etc/hostsentrée de fichier pour vous assurer qu'elle est conforme à ce format .

Aussi, que faites-vous pour la résolution DNS? Pouvez-vous poster votre /etc/resolv.conf?

Les autres réponses indiquant que 0.0.0.0représente les connexions locales sont correctes. Les exemples typiques sont les événements de redémarrage et de connexion à la 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)    

Étant donné que cela ne semble se produire qu'avec les utilisateurs nommés, y a-t-il un changement, il y a quelque chose de génial à trouver ou à exécuter dans leurs scripts de connexion? Avez-vous changé ~/.bashrcou ~/.bash_profilepar défaut? Existe-t-il d'autres scripts de connexion spéciaux dans l'environnement?

--Éditer--

Je ne suis toujours pas en mesure de reproduire cela en aucune façon. Je regarde cependant deux composants critiques. La lastcommande est stable et n'a pas été modifiée depuis longtemps. En regardant le journal des modifications pour sysvinit-tools , il n'y a pas de bogues pertinents. Idem pour les scripts d' initiation (wtmp).

Si vous pouvez forcer cela à se produire, essayez-le avec un compte d'utilisateur différent des mêmes machines source. Mais je ne vois aucune indication qu'il s'agit d'un problème de système d'exploitation.

RÉSOLUTION FINALE

J'ai déjà attribué le bonus, c'est donc uniquement pour les futurs googleurs avec la même question.

La raison pour laquelle cela n'apparaît que dans environ 10% de mes connexions est que lorsque j'apporte des modifications majeures à nos routeurs ou commutateurs, j'utilise script foo.logdonc j'ai un journal de terminal complet de la modification. Pour des raisons que je ne comprends toujours pas, CentOS crée une ptsentrée lorsque vous utilisez la scriptcommande ... Je vais montrer la sortie last -iavant et après l'exécution 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]$

Ce comportement semble être unique à CentOS 6 ... nous avons quelques machines CentOS 4.7 dans le laboratoire qui ne mettent pas d'entrée vide dans wtmp... Les machines Debian / Gentoo ne présentent pas ce comportement non plus. Nos administrateurs linux se grattent la tête pourquoi CentOS ajouterait intentionnellement une autre ptsentrée lorsque vous exécutez script... Je soupçonne que c'est un bogue RHEL.

EDIT : J'ai classé ce problème sous le numéro d'identification de bogue RHEL 892134

REMARQUE

Certaines personnes ont supposé à tort que je mettais scriptmon ~/.bashrcou ~/.bash_profile. C'est un argument erroné ... si c'était vrai, mon wtmpdevrait avoir une 0.0.0.0entrée après chacune de mes connexions 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)  # <-----

Bien sûr, ce n'était pas le cas ...

Les connexions Pseudo Terminal Slave (pts) sont des connexions SSH ou telnet qui signifient des connexions indirectes au système. Toutes ces connexions peuvent se connecter à un shell qui vous permettra d'envoyer des commandes à l'ordinateur. Ainsi, lorsque vous ouvrez un terminal sur votre système à partir de l'interface graphique, cela ouvre un point avec l'ip source 0.0.0.0. D'après les informations fournies par vous, il semble que cela se produise en raison du script exécuté sur ce serveur ou planifié, qui utilise le service ssh ou telnet ou des points locaux pour lancer la sortie dans le terminal.

Quel client ssh utilisez-vous? Certains clients ssh peuvent multiplexer plusieurs terminaux sur une seule connexion et je remarque que toutes vos sessions sans IP se trouvent dans des sessions plus longues qui ont une IP enregistrée.

Je ne peux pas reproduire ce comportement avec ssh ici.

Peut-être que votre adresse IP se résout en une chaîne vide sur l'un de vos serveurs DNS, probablement le secondaire si cela ne se produit que 10% du temps (ou tout simplement un fichier d'hôtes si ceux-ci sont distribués à partir d'un référentiel central). Cela expliquerait l'entrée manquante (ou espace blanc) et serait cohérent avec la lecture de la source par Soham.

"0.0.0.0" signifie qu'il s'agit d'un utilisateur local (pas une connexion à distance), probablement invoqué par l'application, par exemple cronjob.

Cela se produit parce que vous utilisez le système local et que 0.0.0.0 signifie l'adresse IP de toutes les interfaces. Si vous pensez que quelqu'un a piraté, essayez de configurer la journalisation complète du shell, y compris les commandes via ssh - http://blog.pointsoftware.ch/index.php/howto-bash-audit-command-logger/

Je l'ai résolu en ajoutant un script à ~ / .bashrc, le script trouve la dernière adresse IP source de la connexion Telnet, puis vous pouvez ajouter l'IP à un fichier journal ou faire tout ce dont vous avez besoin ..

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