Uma semana na vida de um administrador de redes bastardo do inferno

**** Segunda ****

8:05am

Usuário chama dizendo que perdeu a password. Eu disse a ele para usar um utilitário de recuperação de senhas chamado FDISK. Ignorante, ele me agradeceu e desligou. Meu Deus!
E a gente ainda deixa essas pessoas votarem e dirigirem?

8:12am

A Contabilidade chamou para dizer que não conseguiam acessar a base de dados de relatórios de despesas. Eu dei a resposta Padrao dos Administradores de Sistema #112: “Engraçado… Comigo funcionou…”. Deixei eles pastarem um pouco enquanto eu desconectava minha cafeteira do No-Break e conectava o servidor deles de volta. Sugeri que eles tentassem novamente. Ah… Mais um usuario feliz…

8:14 am

O Usuario das 8:05 chamou dizendo que recebeu a mensagem:
Erro no acesso ao drive 0. Disse a ele que isso era problema de SO e: transferi a ligação para o microsuporte.

11:00 am

Relativamente calmas as últimas horas. Decidi reconectar o telefone do suporte para ligar pra minha namorada. Ela disse que os pais dela virão pra cidade nesse fim-de-semana. Pus ela “em-espera” e transferi a ligação para o almoxarifado.
Que é que ela está pensando? Os torneios de “Doom” e “Myst” são neste fim-de-semana!

12:00 pm

almoço.

15:30 pm

Retorno do almoço.

15:55 pm

Acordei da soneca. Sonhos ruins me dão tremores. Empurrei os servidores sem razão. Voltei pra soneca.

16:23 pm

Outro usuario liga. Quer saber como mudar fontes em um formulário. Perguntei que chip eles estão usando. Falei pra eles ligarem novamente quando descobrirem.

16:55 pm

Resolvi rodar a macro “Criar Salvar/Replicação de Conflitos” para que o turno da noite tivesse algo pra fazer…

**** Terça ****

8:30 am

Terminei a leitura do log do suporte da noite anterior. Pareceram ocupados. Tempos terriveis com Salvar/Replicação de Conflitos…

9:00 am

Gerente de suporte chega. Quer discutir minha atitude. Cliquei no Phone Notes Smart Icon. “Adoraria, mas estou ocupado. “, gritei enquanto pegava as linhas de suporte, que (misteriosamente) acenderam.

9:35 pm

O chefe da equipe de P&D precisa de ID para novos empregados. Disse ele que precisava do formulario J-19R=3D9C9\\DARR\K1. Ele nunca tinha ouvido falar de tal formulário. Disse a ele que estava no banco de dados de FORMULÁRIOS ESPECIAIS. Ele
nunca tinha ouvido falar de tal banco de dados. Transferi a ligação para o almoxarifado.

10:00 am

Ana ligou pedindo um novo ID. Eu disse que precisaria da matricula, nome de depto, nome do gerente e estado marital. Rodei @DbLookup nos bancos de dados de Controle de Doenças e não achei nada. Disse a ela que o novo ID estaria pronto de noite. Relembrando as lições de “Reengenharia para Parceria de Usuários”, ofereci-me para entregar pessoalmente em sua casa.

10:07 am

O cara do almoxarifado passou por aqui dizendo que estava recebendo ligações estranhas ultimamente. Ofereci a ele um treino em Notes. Começando agora. Deixei ele olhando a console enquanto sai para fumar.

13:00 pm

Voltei da pausa para o cigarro. O almoxarife disse que os telefones ficavam tocando demais, então ele transferia as ligações pra moça da cafeteria. Começo a gostar desse cara.

13:05 pm

Grande Comoção! Gerente de suporte cai num buraco aberto onde eu tinha tirado os tacos, na frente da porta do seu escritório. Falei pra ele da importância de não entrar correndo na sala do computador, mesmo que eu grite “Meu Deus — Fogo!!”

14:00 pm

A secretária jurídica liga e diz que perdeu a password. Pedi a ela que cheque sua bolsa, chão do carro e no banheiro. Disse que provavelmente caiu das costas da máquina. Sugeri que ela ponha durex em todas as entradas de ar que ela ache no PC. Grunhindo, ofereci-me para lhe dar nova ID enquanto ela colava os durex…

14:49 pm

O almoxarife voltou. Quer mais aulas. Tirei o resto do dia de folga.

**** Quarta ****

8:30 am

Detesto quando os usuários ligam pra dizer que o chipset não tem nada a ver com fontes em um formulário. Disse a eles “claro, vocês deviam estar checando o “bitset” e não “chipset”. Usuário bobo pede desculpa e desliga.

9:10am

Gerente de suporte, com o pé engessado, volta ao escritório. Agenda um encontro comigo para 10:00am. Usuário liga e quer falar com o gerente de suporte sobre terriveis socorros na mesa de suporte. Disse a eles que o gerente estava indo a
uma reunião. As vezes a vida nos dá material…

10:00 am

Chamei o Luiz do almoxarifado pra ficar no meu lugar enquanto vou no escritório do gerente. Ele disse que não pode me demitir, mas que pode sugerir vários movimentos
laterais na minha carreira. A maioria envolvida com implementos agricolas no terceiro mundo. Falando nisso, perguntei se ele já sabia de um novo bug que pega texto indexado dos bancos de dados e distribui aleatoriamente todas as referências. A reunião foi adiada…

10:30 am

Disse ao Luiz que ele está se saindo muito bem. Ofereci-me para mostra-lo o sistema corporativo de PBX algum dia…

11:00 am

almoço.

16:55 pm

retorno do almoço.

17:00 pm

Troca de turno. Vou pra casa.

**** Quinta ****

8:00 am

Um cara novo (Jonas) começou hoje. “Boa sorte”, disse a ele. Mostrei-lhe a sala do servidor, o armário de fios e a biblioteca técnica. Deixei-o com um PC-XT. Falei pra ele parar de choramingar. O Notes rodava igual, tanto em monocromo quanto em cores.

8:45 am

Finalmente o PC do novato deu boot. Disse a ele que iria criar novo usuário pra ele. Setei o tamanho minimo de password para 64. Sai pra fumar.

9:30 am

Apresentei o luiz ao Jonas. “Boa Sorte”, comentou o Luiz. Esse cara não é o máximo?

11:00 am

Ganhei do Luiz no dominó. Luiz sai. Tirei o resto das peças da manga (“tenha sempre backups”). Usuário liga, diz que servidor de contabilidade está fora do ar. Desconecto o cabo Ethernet da antena do radio (melhor recepção) e ligo de volta no hub. Disse a ele que tentasse novamente. Mais um usuário feliz!

11:55 am

Expliquei ao Jonas a política corporativa 98.022.01 “Sempre que novos empregados começam em dias que terminam em ‘A’ estão obrigados a prover sustento e repouso ao analista técnico senior do seu turno “Jonas duvida. Mostrei o banco de dados de “políticas corporativas”. “Lembre-se, a pizza é de peperoni, sem pimenta!”, gritei enquanto Jonas pisa no taco solto ao sair.

13:00 pm

Oooooh! Pizza me dá um sono…

16:30 pm

Acordo de uma soneca refrescante. Peguei o Jonas lendo anúncios de emprego.

17:00 pm

Troca de turno. Desligo e ligo o servidor varias vezes (Teste do botão ON-OFF…). Até amanhã…

**** Sexta Feira ****

8:00 am

Turno da noite continua tendo problemas para trocar a fonte de alimentação do servidor. Disse a eles que estava funcionando direito quando sai.

9:00 am

Jonas não está aqui ainda. Decidi que deveria começar a responder as chamadas eu mesmo.

9:02 am

Chamada de usuário. Diz que a base em Sergipe não consegue replicar. Eu e Luiz determinamos que é problema de fuso horário. Mandei eles ligarem para Telecomunicações.

9:30 am

Meu Deus! Outro usuário! Eles são como formigas, Dizem que estão em Manaus e não conseguem replicar com Sergipe. Falei que era fuso horário, mas com duas-horas de diferença. Sugeri que eles resetassem o time no servidor.

10:17 am

Usuário do Espírito Santo liga. Diz que não consegue mandar mail pra Manaus. Disse pra eles setarem o servidor para 3 horas adiantado.

11:00 am

E-mail da corporação diz para todos pararem de resetar o time dos servidores. Troquei o “date stamp” e reenviei para o Acre.

11:20 am

Terminei a macro @FazerCafe. Recoloquei o telefone no gancho.

11:23 am

O Acre liga, perguntando que dia é hoje.

11:25 am

Gerente de suporte passa pra dizer que o Jonas pediu pra sair. “Tão dificil achar boa ajuda…”, respondi. O gerente disse que ele tem um horário com o ortopedista essa tarde e pergunta se eu me importo em substitui-lo na reunião semanal dos administradores. “No problems”, eu respondo.

11:30 am

Chamo Luis e digo que a oportunidade bate à sua porta e ele é convidado para um encontro essa tarde. “Claro, você pode trazer seu jogo de dominó”, digo a ele.

12:00 am

almoço

13:00 pm

Começo backups completos no servidor Linux. Redireciono o device para NULL para o backup ser mais rápido.

13:03 pm

Backup semanal completo. Cara, como eu gosto da tecnologia moderna!

14:30 pm

Olho o banco de dados de contatos de suporte. Cancelo o compromisso de 2:45pm. Ele deve ficar em casa descansando.

14:39 pm

Outro usuario ligando. Diz que quer aprender a criar um documento de conexão. Digo a ele para rodar o utilitário de documentos CTRL-ALT-DEL Ele disse que o PC reiniciou. Digo a ele para chamar o microsuporte.

15:00 pm

Outro usuário (novato) liga. Diz que a macro periódica não funciona. Disse a ele para incluir a macro @DeleteDocument no final da fórmula e prometi a ele mandar-lhe o anexo do manual que indica isso.

16:00 pm

Acabei de trocar a cor de frente de todos os documentos para branco. Também setei o tamanho da letra para 2 nos bancos de dados de ajuda.

16:30 pm

Um usuário liga pra dizer que não consegue ver nada em nenhum documento. Digo a ele para ir no menu Edit, opção Select all, e apertar a tecla Delete depois refresh. Prometi mandar-lhe a página do manual que fala sobre isso.

16:45 pm

Outro usuário liga. Diz que não consegue ver os helps dos documentos. Digo a ele que irei consertar. Mudei a fonte para WingDings.

16:58 pm

Conectei a cafeteira no hub Ethernet pra ver o que acontece…Nada… (muito sério).

17:00 pm

O turno da noite apareceu. Digo a eles que o hub está agindo estranho. Desejo um bom fim-de-semana.

Seu site não é um outdoor no meio da rua. Além disso, existem milhões de sites interessantes no ar. Se você não trouxer as pessoas até ele, ninguém o conhecerá. Divulgue.

Não atualizar
Ninguém lê o jornal da véspera. Um site desatualizado demonstra falta de gerenciamento ou descaso com seus visitantes. As duas coisas são péssimas para a imagem da sua empresa. Atualize.

Não responder
A comunicação é feita por pessoas. Ouça o que elas têm a dizer e responda. Se quer os benefícios da interatividade, esteja preparado: responda de maneira consistente. E com velocidade.

Interatividade inútil
Estrelinhas que correm atrás do cursor do mouse, formulários enormes que perguntam qual o número do sapato do internauta (inútil, se você não vende artigos para os pés…), pisca-pisca e todas aquelas coisas irritantes que só fazem a página demorar a ser visualizada e não trazem qualquer benefício para a mensagem. Fuja disso.

“Sedução da tecnologia”
É bonitinho, engraçadinho, interessante, mas serve para que mesmo? Não caia na tentação de colocar um novo recurso, a não ser que ele traga benefícios para seu público e, dessa forma, para sua empresa.

Fonte: Tau Virtual [http://www.tauvirtual.com.br/scr/pt/trabalhos/]

http://paste.lymas.com.br/606

Por Renato Ucha

O gerente de desenvolvimento da sua empresa o chama para uma reunião e o questiona sobre uma nova implantação que deve ser feita no sistema. Por cima, ele diz a você qual a necessidade do cliente e o questiona: “Em quanto tempo você coloca isso em produção?”

Reticente, pois o gerente não foi capaz de definir claramente o escopo do projeto, você hesita em dar uma estimativa de prazo, mas ao ser pressionado você acaba pedindo 30 horas baseado na sua experiência em projetos similares.

Como resposta o gerente diz que acredita muito no seu potencial e por isso estipula um prazo desafiador de 8 horas para a implantação. Como subordinado você aceita o prazo e para mostrar competência e corresponder às expectativas do seu gerente você pula o planejamento e a documentação indo direto para a alteração necessária nos códigos do sistema.

Você acaba entregando o projeto em 20 horas e o seu gerente ainda ironiza dizendo que você estava valorizando ao prever 30 horas para o projeto.

A situação acima, apesar de fictícia, lembra um pouco o dia-a-dia de trabalho de alguns departamentos de TI.

Em geral, quando um projeto desses consegue ser entregue dentro do prazo estipulado pelo gerente (nas condições acima), ou o escopo não foi claramente entendido pelo líder da equipe e portanto o resultado do trabalho não atenderá às necessidades do cliente ou então houve um assassinato da qualidade, o que implica em falta de documentação e excesso de códigos complexos para realizar tarefas simples, o que vai em curto prazo gerar um excessivo número de “bugs” e em longo prazo impactará em uma dificuldade em dar manutenção gerando maiores custos e degradando a performance da aplicação até que um dia a empresa percebe que está na hora de reescrever a aplicação a partir do zero (isso quando não resolvem instalar uma solução de terceiros e acabam com a área de desenvolvimento interna que passa a ser vista como um custo e não como um investimento).

Uma abordagem para o caso acima seria dizer a seu gerente que pela experiência que você possui a implantação levará de 22 a 52 horas, mas que para dar uma estimativa mais correta você precisa primeiro conhecer claramente o escopo das mudanças necessárias e verificar a disponibilidade de recursos para executá-las.

Durante o seu planejamento procure envolver a equipe de desenvolvimento. Sua equipe é quem fará de fato a implementação e portanto deve ser ouvida, até mesmo para levantar questões como a falta de conhecimento para utilizar determinada tecnologia, o que acarretará em um gasto maior de tempo para concluir uma tarefa aparentemente simples.

Não deixe de documentar todas as atividades que você achar necessário fazer para concluir o projeto, não esquecendo de planejar tempo para a elaboração de documentação funcional, técnica, desenvolvimento e testes.

Para este trabalho, não é necessário utilizar ferramentas sofisticadas de gestão de projetos como o MS Project. Esta tarefa pode ser facilmente realizada com uma planilha convencional e será até mesmo mais fácil para quem não está habituado com o MS Project.

Após detalhar as atividades, envolva os seus desenvolvedores e peça que eles respondam as seguintes questões para cada atividade que você escreveu em sua planilha:

• a) Qual o prazo para concluir essa atividade?

• b) Digamos que tudo ocorra bem, e nenhum contratempo aconteça. Neste cenário, qual o tempo mínimo para concluir a atividade?

• c) E se tudo der errado? Qual será o tempo máximo para concluir a atividade?

Estudos comprovam que na maioria das vezes a estimativa da pergunta “a” será o tempo real, mas que desvios podem acontecer e para isso existe um cálculo matemático simples para prever com maior exatidão o prazo da atividade levando em consideração esta variação (das perguntas b e c).

Para isso, antes de colocar a estimativa de prazo na sua planilha, multiplique a resposta da pergunta “a” por 4, some com os tempos das perguntas “b” e “c” e então divida o resultado da soma por 6. É simples, veja o exemplo abaixo:

Estimativa: 10 horas

Se tudo der certo: 8 horas

Se tudo der errado: 15 horas

( 10 * 4 + 8 + 15 ) / 6 = ( 40 + 8 + 15 ) / 6 = ( 63 ) / 6 = 10,5 horas

Ainda que meia hora isolada não represente uma grande alteração, em um projeto de longa de duração, meia hora em cada atividade pode representar dias de trabalho.

Após estimar o prazo para todas as atividades, avalie os riscos envolvidos (como falta de conhecimento da equipe, possibilidade de perder funcionários chave, parada de servidor não programada, etc) e tente quantificar o quanto de tempo cada risco pode custar ao projeto.

Por exemplo, você sabe que o servidor de banco de dados de desenvolvimento costuma ficar parado pelo menos um dia por mês devido a falhas na restauração do backup de produção, então contabilize (para uma atividade estimada de 1 semana) 2 horas como tempo extra para este risco (como calcular? em um mês = 8 horas parado, então em 1 semana, 8h (parada mensal)/4(semanas) = 2 horas por semana).

Ao final, some as estimativas de tempo e adicione separadamente as estimativas de tempo para os riscos que você detectou.

Para apresentar a estimativa ao seu gerente, leve com você esta planilha que criou e entregue ao seu gerente uma cópia, incluindo a listagem das atividades, o tempo estimado para cada atividade (se possível, inclua também o nome do funcionário que deverá executar a atividade).

Ao final, após a soma total de tempo estimado, inclua a relação de riscos e o tempo extra correspondente, que poderá ser utilizado para compensar os riscos listados.

Veja aqui um modelo preenchido de planilha.

Com base em todo este material que você coletou e elaborou, você terá bastante argumento para convencer seu gerente a respeito da estimativa de prazo que você passou, evitando ter de sacrificar a documentação do sistema e o processo de planejamento, elementos essenciais quando se pensa em alta performance, reutilização de códigos, documentação de sistemas, etc.

Ah, e não ache que passar estimativas de prazo altas e entregar em tempo excessivamente melhor vai fazer com que seu gerente acredite que você seja um bom líder. Ao contrário, se isto ocorrer com freqüência vão pensar que você é um péssimo líder pois não sabe estimar com precisão o tempo necessário para concluir suas atividades e aí cada vez mais a história hipotética do começo desse artigo vai acontecer no seu dia-a-dia.

Fonte: Webinsider

A maioria dos roteadores aceita o procedimento abaixo. Em alguns casos podem haver particularidades.

Veja mais detalhes em: http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_tech_note09186a00801746e6.shtml

1. Conecte se ao roteador pela porta de console(configuração da serial: 9600-8-N-1)

2. Se você tiver acesso ao roteador use o comando show version no prompt e anote a configuração do registro. (Register 0×2102, por exemplo).

3. Desligue e ligue o roteador.

4. Pressione Break no teclado do terminal antes de 60 segundos depois de ligar o equipamento para entrar no modo ROMMON.

5. Digite confreg 0×2142 no prompt da rommom (rommom >1) de maneira a bootar da flash e “bypassar” (fazer com que não seja executado) o arquivo de configuração onde as senhas estão armazenadas.

6. Digite reset no prompt (rommom >2)O roteador irá reinicializar, mas vai ignorar a configuração salva.

7. Digite no para cada questão no setup ou pressione Ctrl-C de forma a pular o procedimento de configuração inicial.

8. Digite enable no prompt de comando (Router>)Você agora está em modo privilegiado e deve ver Router#.

9. Digite configure memory, ou copy startup-config running-config de forma a copiar a NVRAM não volátil para a memória.

10 Digite show running-config. O comando show running-config permite ver a configuração do roteador. Você poderá ver todas as senhas que não estejam criptografadas. As interfaces também estão no estado down.

11. Digite configure terminal O prompt hostname# vai aparecer. Sete novamente a senhas com enable secret e não esqueça de setar a senha de login nas portas VTY também.

12. Entre com no shutdown em todas as interfaces

13. Retorne o register do roteador para 0×2102 (normalmente) usando:config-register 0x2102Se o registro original (obtido no passo 2)for diferente de 0×2102, use o original

14. Use Ctrl-z para sair do modo de configuração

15. Use write memory para gravar as configurações com as novas senhas.

16. Reinicialize o roteador.

Fonte: networkexperts

É sempre útil ler algumas dicas rápidas para melhorar a sua codificação. Geralmente temos vícios que adquirimos no dia-a-dia que, sem sabermos, tornam o nosso código mais lento.

Seguem abaixo 12 dicas para melhorar o processamento dos seus códigos PHP.

1. Se um método pode ser static, declare-o como static! O desempenho aumenta 4 vezes;

2. Evite utilizar metódos mágicos como __get, __set e __autoload, se possível;

3. require_once() é dispensável e demanda bastante memória;

4. Use caminhos completos (full path) nos includes e requires, pois é gasto menos tempo resolvendo os caminhos do sistema operacional;

5. Se você quer descobrir o tempo em que o script começou a ser executado, é preferível utilizar $_SERVER[´REQUEST_TIME´] do que time();

6. Veja se pode utilizar strncasecmp, strpbrk e stripos ao invés de regex;

7. str_replace é mais rápido que preg_replace, mas strtr é 4 vezes mais rápido que str_replace;

8. Se uma função, como de substituição de strings, aceitar tanto arrays como caracteres simples como argumentos, e se a sua lista de argumentos não é muito longa, considere fazer algumas declarações redundantes de substituição, passando um caractere por vez, ao invés de uma linha de código que aceita arrays como argumentos de busca e substituição;

9. Supressão de erro com @ é muito lento;

10. $row[´id´] é 7 vezes mais rápido que $row[id];

11. Mensagens de erro demandam mais processamento;

12. Não utilize funções dentro de loops, como por exemplo: for ($x=0; $x < count($array); $x). A função count() é chamada todas as vezes que o loop é executado.;

Fonte:http://www.moskalyuk.com/blog/php-optimization-tips/1272

Tradução: http://imasters.uol.com.br/artigo/8962/php/12_dicas_para_otimizar_seus_codigos_php/

Boa referencia pra quem se vê (literalmente) no limite de sua capacidade por conta da demanda destes acessos, na sua maioria não produtivos.

Depois desse artigo, algumas pessoas vão querer te matar… hehehehe.

Sem querer achei um link muito bom no site LinuxSecurity que falava justamente sobre isso: http://www.onlamp.com/pub/a/php/2007/05/10/migrating-web-based-php-applications-to-ajax.html .

Pra quem, assim como eu, está sempre às voltas com aplicações defasadas mas que têm que dar um novo gás nas mesmas, este artigo traz dicas interessantes que todos deveriam levar em conta.

  Sniffando o SSH com o Strace
  ============================

É possivel Sniffar as Conexões via SSH simplesmente escutando as chamadas
System Calls do daemon SSHD.  Existe um ponto de comunicação entre o SSHD e
o Kernel, entre a Criptografia e a Descriptografia, em que os dados passam em
Texto Plano (plain text) e este tráfego pode ser capturado com o uso do Strace.

  1. Sniffando a Senha do Login:
  ==============================

1. No servidor que está com o Server do SSH rodando descubra qual o pid do daemon sshd:

  Zion:~# ps aux | grep sshd | grep -v grep
  root      6097  0.0  0.1   4792  1076 ?        Ss   16:49   0:00 /usr/sbin/sshd

2. De posse deste pid dispare o Strace (como root):

  Zion:~# strace -f -p 6097 -o snif_ssh.txt &

Este comando irá logar no arquivo sniff_ssh.txt todas as chamadas  do processo
de pid 6097 (sshd).  Uma lida no man do strace ajuda a entender e experimentar
outras opções de filtragem e paãmetros.

3. De um outro servidor, ou para fins de teste da mesma máquina, faça um ssh
com um usuário qualquer:

  godoy@Zion:~$ ssh localhost
  Password: textoplano
  Last login: Mon May  7 17:01:15 2007 from localhost.localdomain
  godoy@Zion:~$

4. Agora analíse as saídas que foram logadas no arquivo sniff_ssh.txt, procure
pelas chamadas read ou write:

  Zion:~# cat snif_ssh.txt | grep read | more
  6521  write(4,  1ntextoplano , 18 <unfinished  >
  6520  <  read resumed>  71ntextoplano , 19) = 19
  6520  write(7,  ntextoplano , 14 <unfinished  >
  6522  <  read resumed>  6ntextoplano , 15) = 15

  2. Sniffando as demais transferências de dados:
  ===============================================

1. Digite o seguinte comando, restringindo a busca as chamadas read e write:

  Zion:~# strace -f -p 6097 -o snif_ssh.txt -v -e trace=read,write -s 128 &

2. Teste alguns comandos no cliente:

  godoy@Zion:~$ cat > teste.txt
  ======== OK =======
  Sniffou??
  ======= OK =======
  godoy@Zion:~$

3. Verifique o log o servidor pesquisando por write ou read:

  Zion:~# cat snif_ssh.txt | grep  ===
  6586  <  read resumed>  ======== OK =======n , 4096) = 20
  6586  write(1,  ======== OK =======n , 20) = 20
  6586  <  read resumed>  ======= OK =======n , 4096) = 19
  6586  write(1,  ======= OK =======n , 19) = 19
  Zion:~# cat snif_ssh.txt | grep  Sniff
  6586  <  read resumed>  Sniffou??n , 4096) = 10
  6586  write(1,  Sniffou??n , 10)       = 10
  Zion:~#

Como a saída do Strace é muito prolixa e pode rapidamente criar um arquivo
bem grande, cabe aqui um script  para filtrar melhor o log que será gravado
no arquivo sniff_ssh.txt.

Pode-se imaginar que é perfeitamente possível disparar tais comandos no lado do cliente!!

E que também pode-se criar um rootkit que se aproveite desta comunicação de
SystemCalls para pegar o tráfego entre o Servidor SSH e seus clientes.

Portanto tome muito cuidado com os seus servidores SSH e coms seus clientes.

Fonte: Leandro Godoy http://www.blogmind.com.br/