O SSH (Secure SHell) é ao mesmo tempo um protocolo e uma aplicação para acesso remoto. Os protocolos foram desenvolvidos em 1995 por Tatu Ylonen, fundador da empresa SSH Communications Security. O conjunto permaneceu livre até a sua versão 1.2.12, quando se tornou um produto proprietário desta empresa. Foi desta versão que se originou o aplicativo OpenSSH (uma implementação destes protocolos e várias ferramentas auxiliares), em 1999. Existem também várias outras opções comerciais de implementação do SSH porém, por ser livre, o OpenSSH é a mais popular.

O SSH tem como objetivo principal fazer a autenticação cliente -> servidor de modo seguro através de troca de chave ou senha. Criando entre os dois um tunel de conexão segura. Existem muitas diferenças entre esses dois protocolos, uma vez que o SSH2 não foi apenas uma atualização do SSH1, ele foi reescrito aumentando sua segurança, suas formas de autenticação e funcionalidades que foram criadas a fim de possibilitar um maior grau de segurança.

A primeira versão, conhecida como SSH1, foi desenvolvida principalmente com a intenção de substituir os “comandos r”: rlogin (permite que o usuário logue no sistema remoto utilizando a porta 513/TCP), rsh (que permite executar comandos no shell remoto como outro usuário. Na ponta onde o usuário irá se conectar é necessário que o daemon rshd esteja sendo executado) e rcp (permite fazer uma cópia de arquivos entre sistemas remotos através da Internet). A segunda versão (SSH2, incompativel com a versão SSH1) tem o intuito de resolver falhas de segurança sérias encontradas na primeira versão e melhora o método de transferência de arquivos entre os hosts (através do SFTP).

O protocolo SSH1, já é considerado por muitos como ultrapassado e inseguro, está cada vez mais caindo em desuso, de forma que os novos aplicativos utilizem apenas o SSH2.

O SSH2 tem como principal vantagem, quando comparado ao SSH1, uma maior segurança. As principais mudanças foi a retirada dos algoritmos de criptografia DES e IDEA e a adição do método de autenticação DSA.

Com essas mudanças obtivemos melhora no uso de aplicativos para transferência de arquivos tanto em Linux (SFTP e SCP) e em Windows.

Existem duas falhas mais conhecidas do SSH1. A primeira mais conhecida, permite que a chave de sessão seja recuperada por aquele que está atacando, de modo que deixa vulnerável as próximas conexões. O que acontece, de fato, é que é feita uma escuta de todas as informações que estão sendo transmitidas, e se observa problemas de design ou implementação no cliente ou no servidor que permitam obter a chave de sessão. Apartir daí o texto pode ser decifrado.

A outra falha já documentada é relacionada a um overflow de inteiros no código, que foi criada para detectar ataques contra uma outra falha já detectada no SSH1, envolvendo o CRC checksum dos pacotes de dados. O problema é que esse overflow pode resultar em uma inscrição de dados sobre uma área de memória já utilizada para outros fins. O ataque é feito colocando pacotes maliciosos entre as informações trocadas, permitindo a execução de comandos arbitrários tanto no servidor quanto no cliente. Essa questão se torna ainda mais complexa quando quem está rodando o arquivo é o root, o que pode gerar um dano ainda maior.

Basicamente, ambos os protocolos tem por princípio fazer a autenticação do usuário, e, em seguida, trocar a chave de sessão. Assim, é possível transmitir todas as informações totalmente encriptadas.

Site em inglês para um conhecimento mais aprofundado: SecureShell

/etc/pptpd.conf

procurar as linhas:

# TAG: logwtmp
 #       Use wtmp(5) to record client connections and disconnections.
 #
 logwtmp

E comentar a linha do logwtmp, salvar o arquivo e reiniciar ou iniciar o pptpd.

# TAG: logwtmp
#       Use wtmp(5) to record client connections and disconnections.
#
#logwtmp [root@VPN01 ~]# service pptpd restart 

Essa foi a solução que encontrei procurando pela internet e simplificando aqui para vocês.

A solução mais óbvia, é claro, colocar permissão pra o usuário executor do programa na pasta para escrita ou arquivo para leitura, porém, dependendo da pasta não podemos adicionar o usuário ao grupo dono da pasta, então podemos ter alguma soluções de contorno.

O problema citado no título aconteceu quando instalava o Quagga (http://www.quagga.net/).

Após terminar a instalação, na hora de executar ele não devolveu resposta alguma, fui olhar no log e lá estava a mensagem:

ZEBRA: Can't create pid lock file /var/run/zebra.pid (Permission denied), exiting

Assim que tentei carregar o Zebra ele disse que não tinha permissão para criar o .pid, como ele utiliza o usuário e o grupo quagga eu não colocaria permissão para esse usuário escrever direto no /var/run então a minha solução foi:

Criar uma pasta dentro do /var/run com nome quagga:

mkdir /var/run/quagga

Depois adicionar permissão para o usuário e o grupo quagga de escrita e leitura:

chown quagga:quagga /var/run/quagga

Depois de criada a pasta e dada a permissão, teremos que recompilar o Quagga e definir a pasta onde ficaram os arquivos .pid do Quagga. Dentro da pasta do source digitaremos:

./configure --localstatedir=/var/run/quagga

Pronto! Agora assim que executo o Zebra ele já consegue criar o zebra.pid dentro do /var/run/quagga/ sem problema algum.

Como sempre digo, essa foi a solução mais rápida que encontrei, caso alguém tenha uma sugestão melhor, só comentar o post.

Eu precisava fazer a atualização urgente então, procurando na internet encontrei a seguinte solução:

<comando> –nogpgcheck

Não parece ser a melhor solução mas como era urgente não pensei duas vezes.
Ainda não investiguei para corrigir o problema, caso alguem saiba só colocar um post!

[root@elastix ~]# service asterisk restart Stopping safe_asterisk:                                    [FAILED] Shutting down asterisk:                                    [FAILED] Starting asterisk:                                         [  OK  ] Asterisk ended with exit status 1 Asterisk died with code 1. Automatically restarting Asterisk. 

E ficava dando essa mensagem em um loop constante até você parar o serviço novamente.  Procurando pela internet encontrei um bocado de “dica” mas nenhuma funcionou comigo, talvez por causa da versão (que já atualizei e não lembro da antiga depois posto aqui), a primeira foi dizendo o seguinte, “o serviço já está rodando e você está tentando inicializa-lo novamente”, a solução para essa seria:

killall -9 asterisk safe_asterisk

E depois iniciar o serviço:

service asterisk start

Mas ele não matou nenhuma instância com o kill e continuou repetindo o mesmo erro. Ainda no site do FreePBX descobri outro tópico com o mesmo erro que talvez me ajudasse, mas como já disse, nada é fácil. Ele dizia para digitar o seguinte:

amportal start

Então ele retornou a mesma mensagem

Tentei conectar no console através do (asterisk -r) então veio uma mensagem que não tinha visto aindo.

Unable to connect to remote asterisk (does /var/run/asterisk/asterisk.ctl exist?)

Quando acessei a pasta, os arquivos estavam lá (lembrando que o asterisk continuava não rodando) então achei que pudesse ser permissão, coloquei a máxima e continou com o problema. Foi então que na ultima tentativa eu digitei direto no console:

[root@elastix ~]# safe_asterisk

Ele rodou normal e ficou funcionando, consegui criar meus ramais, configurar meu tronco, tudo!

Depois disso atualizei meu Elastix, como ele é baseado em CentOS bastou um “yum update” para deixar a versão atualizada.

Agora posso rodar o serviço através do service asterisk start/restart que ele funciona normalmente.

Sinceramente não descobri o problema, porém, consegui uma solução!

== Manager 'admin' logged on from 127.0.0.1 

Ela acontece quando utilizamos alguma interface web (Elastix no meu caso) para configurar o Asterisk.

Então procurando por alguns foruns, encontrei no forum do FreePBX (http://www.freepbx.org) a solução. Ela é bem simples, apenas adicionando uma linha nós acabamos com essa mensagem.

A linha é:

displayconnects=no

No campo:

 [general] 

No arquivo:

/etc/asterisk/manager.conf

Depois só recarregar as configurações ou reiniciar o serviço do Asterisk.

0 = nenhuma operação permitida
1 = permite execução de um arquivo ou acesso a uma pasta 
2 = permite escrever/alterar um arquivo/pasta
4 = permite apenas leitura

Todo arquivo tem permissão para o dono(owner), para o grupo(group) e para outros[world(são aqueles que não são o dono(claro) e não estão no grupo)].

Para definir as permissões que você quer para o arquivo/pasta, devemos somar os bits que você quer para cada classe.

Exemplos:

#1 Seu diretório “home” terá por padrão a permissão 711.

7 = 4 + 2 + 1 - você (o dono) pode ler/escrever/executar
1 = 1 - o grupo pode executar/acessar diretorio, mas nao podem ler nem escrever.
1 = 1 - outros podem executar/acessar diretorio, mas nao podem ler nem escrever.

#2 Seu diretório da web terá permissões 755:

7 = 4 + 2 + 1 - você (o dono) pode ler/escrever/executar
5 = 4 + 1 - o grupo pode executar/acessar diretorio/ler, mas nao pode escrever.
5 = 4 + 1 - outros podem executar/acessar diretorio/ler, mas nao pode escrever.

Tudo muito simples, você só precisa somar os números conforme a permissão necessária.

Há também uma outra maneira de se dar permissão usando o chmod, que algumas pessoas dizem ser mais simples e só fazem uso da mesma. Vejo as duas como simples.

É o seguinte, ao invés dos números usaremos “letras”.

Para definir qual o tipo de pessoa que irá ter permissão, utilizaremos as seguintes:

"u" - para dono (owner)
"g" - para groupo (group)
"o" - para outros (others)
"a" - para todos (all) 

Os operadores serão:

"+" - para adicionar 
"-" - para remover
"=" - define para todos, todas as permissões que o arquivo/pasta terão.
Caso não seja definido nenhum valor, ele apagará todas as permissões.
obs: Mesmo que coloque =rwx(sem definir usuario)ele nunca dará permissão
de escrita para grupo e outros, só para o dono.

As permissões são:

"r" - para leitura(read)
"w" - para escrita(write)
"x" - para execução(execute)

Seguem alguns exemplos:

chmod u=rx arquivo - Da permissão de leitura e execução para o dono
chmod go-r arquivo - Retira permissão de leitura do groupo e dos outros
chmod g+w arquivo - Adiciona permissão de escrita para o grupo
chmod a+x arquivo1 arquivo2 - Adiciona permissão de execução para todos
chmod g+rx,o+x arquivo - Adiciona permissão para o grupo de leitura e
execução e para outros apenas execução

Bem, estão ai as duas maneiras possíveis, cabe agora a vocês escolherem a melhor! Lembrando sempre que isso é apenas o “básico” caso queria entender melhor o chmod use o man.

"cannot find name for user ID xxx"
ou
"cannot find name for group ID xxx"

Pode ter dois motivos:
#1 – Ser devido a um problema de permissão no /etc/passwd ou /etc/group files.  Para solucionar, usaremos os seguintes comandos:

chmod 644 /etc/passwd
chmod 644 /etc/group

#2 – A pasta /usr/sbin não está no seu “path”. A solução nesse caso e a mais recomendada é usar o caminho completo:

Como root deletamos o usuário já criado:
userdel <usuário>

Então criamos o usuário novamente utilizando o caminho completo:
/usr/sbin/useradd <usuário>

Estão ai duas soluções simples, para esse problema chato.  Lembrando que a segunda opção é a ideal para manter a segurança do seu ambiente.

Uma explicação breve do que seria Martian Source.  Pacotes Marcianos no português  são pacotes que o Linux não está esperando que cheguem pela interface que estão chegando, exemplo, pacotes da rede interna chegando pela interface externa. A causa pode ser um servidor mal configurado ou uma VLAN.

martian source 72.14.204.101 from 192.168.1.15, on dev eth0
ll header: 45:00:00:28

Podemos desabilitar o Log, para evitar que fique cheio só de mensagens dele.

cd /proc/sys/net/ipv4/conf/
echo 0 > ethx/log_martians
(onde x é o numero da interface)

Fiz isso no CentOS 5.4, ainda não testei reiniciar o servidor, mas aparentemente essa solução é “temporaria” até o proximo boot.
Pesquisando pela a internet a solução definitiva seria como vou citar abaixo, porém, fiz aqui e não funcionou de imediato. No meu caso, onde não posso reiniciar o servidor quando bem entender então, não foi a solução. De qualquer forma adicionei a linha pois não existia.

edite o arquivo:
/etc/sysctl.conf
adicione/altere
net.ipv4.conf.all.log_martians = 0

Para descobrir a versão do Kernel, é padrão em todas as distribuições então é só digitar no console:

# uname -a

Teremos como resultado algo do tipo:

Linux 2.6.18-164.10.1.el5 #1 SMP Thu Jan 7 20:00:41 EST 2010 i686 athlon i386 GNU/Linux

O resultado vai variar conforme a versão instalada e o hardware.

Para descobrir a versão do Linux instalada, para cada distribuição teremos uma particularidade. Vejamos:

Para baseadas em RedHat e Debian:

# cat /etc/issue

Para Slackware:

# cat /etc/slackware-version