Redirecionamento X11 via SSH

Aproveitando que essa memória aqui tem bastante espaço colocar mais uma dicazinha:

Requerimentos para redirecionar as aplicações do X via SSH.

No servidor SSH:

arquivo /etc/ssh/sshd_config:

X11Forwarding yes

---

No cliente SSH:

arquivo /etc/ssh/ssh_config:

ForwardX11 yes

Log into the remote system and type xclock &. This starts a X clock program that can be used for testing the forwarding connection. If the X clock window is displayed properly, you have X11 forwarding working.

Retirado daqui.

Túnel via SSH

A idéia é bastante simples. Pode-se chamar de uma "VPN simples". Esse recurso pode ser usado quando se está em uma rede não segura e precisa criptografar o tráfego. Por exemplo, você está numa lan house, onde pode ter alguém "esnifando" (de sniffing) a rede , e precisa acessar um serviço que não possui criptografia.

Isso é chamado de Dynamic Port Forwarding e é um recurso que o SSH possui. Tudo o que você precisa é de um usuário em algum servidor rodando SSHD e que esse servidor tenha acesso liberado a internet. Para ficar mais fácil a compreensão de como o túnel é feito vamos supor um exemplo:

Você está em uma estação qualquer, chamaremos de Host1. Você tem uma conta em um servidor, com acesso a internet, chamado Server1 e deseja se conectar ao site www.terra.com.br

Alguns pontos a considerar:

• Server1 pode estar dentro de uma rede privada ou mesmo na internet em qualquer lugar do planeta;
• Host1 pode estar em qualquer lugar do planeta onde consiga se conectar à Server1;
  
• E o site do Terra está há duas quadras de onde eu estou escrevendo esse artigo. Mas isso não vem ao caso.

Para configurar Host1 precisamos apenas ter um cliente ssh. Pode ser no UNIX ou mesmo Windows. Depois do procedimento descrito a seguir, Host1 vai se tornar um servidor. O qual vai receber conexões e encaminhar para Server1 que vai fazer o papel de um proxy que suporta socks.

Configurar Host1 no Unix:

ssh -D 1080 joao@server1

Depois de estabelecida a conexão com server1 é só manter essa conexão ativa. E, teoricamente está pronto. Assim.. simples ou como diria os gringos out of the blue...

Nesse momento Host1 tornou-se um servidor que encaminha todas as conexões que chegam até ele com destino a porta 1080 para Server1.

Para fazer uso disso vá até seu navegador, por exemplo, e configure-o para usar proxy socks. No endereço do socks proxy vai localhost e a porta é a 1080. Pronto! Funcionando!


Configurar Host1 no Windows:

Como dito anteriormente, é necessário apenas um cliente SSH. Que no windows vai ser o Putty.
Aqui tem um vídeo de todo o processo incluindo a configuração do Putty.

Pra ser mais prático pode ser feito via linha de comando no windows também.

putty -ssh -D 1080 joao@server1

Estamos prontos para fazer a configuração do navegador, cliente MSN, seja lá o que for.
É a mesma coisa que fizemos antes. Configurar o software para utilizar proxy socks.


Só para deixar claro: A conexão é criptografada de Host1 até Server1. Do Server1 até o site do terra que é o nosso exemplo a conexão não é segura.

Links sobre o assunto:

http://www.debian-administration.org/articles/449
http://www.panix.com/~ruari/censorship.html
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/portfwd-dynamic.html
http://www.ssh.com/support/documentation/online/ssh/adminguide/32/Dynamic_Port_Forwarding.html
http://www.irongeek.com/i.php?page=videos/sshdynamicportforwarding

Unidades de medida de memória

Sempre quis saber o que é maior que peta e menor pico!

Aqui e aqui.

eu vou precisar dessa imagem ainda...

Dica de shell no BSD

Conecto via SSH em um servidor com FreeBSD 6.2 e quando pressiono delete para apagar caracteres à direita do cursor aparece um til(~) e não apaga.

Rapidamente pode ser solucionado editando ~/.cshrc e inserindo a seguinte linha

bindkey "\e[3~" delete-char

Outra dica legal é pressionar TAB ao invés de ctrl+d para completar os comandos. Para isso insira no mesmo arquivo:

set autolist='ambiguous'

Dica retirada daqui http://www.fug.com.br/historico/html/freebsd/2005-10/msg00290.html
Tcharã!!

Busca no LDAP

Não sei porque cargas d'água um dia parou de fazer autenticação do apache no AD do windows 2000. Juro que não mudei nada... Tinha 3 servidores configurados pra autenticar via LDAP no AD. Um dia pararam os 3. Sendo ambiente Microsoft até não me surpreendeu tanto... risos.
Conversei com o Adminstrador da rede windows e fui informado de que tudo continuava como no dia anterior quando ainda funcionava.

Sendo assim meu pensamento foi: "ixxx...".

Debugei o Apache e não me dava informações suficientes do porque do problema. Antes de continuar exponho aqui o arquivo .htaccess que usei e apresentou problemas:

<Directory /usr/local/nagios/sbin>
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all


AuthType Basic
AuthName "Acesso ao Nagios"

AuthLDAPUrl "ldap://ad.xyz.com.br/dc=xyz,DC=com,DC=br?sAMAccountname?sub?(objectClass=*)"

AuthLDAPBindDN user@xyz.com.br
AuthLDAPBindPassword ***

require group CN=TI,OU=Groups,OU=SEDE,DC=xyz,DC=com,DC=br

</Directory>

Encontrei um ser humano com o mesmo problema que eu aqui. Acompanhem o desespero do mesmo. :-)

Encontrei informações no site Microsoft TechNet de como fazer buscas em AD windows. Uma das seções do texto ensina como conectar ao AD para fazer buscas e deixa claro:

For standard LDAP searches, directory clients connect to TCP port 389. To search the Active Directory global catalog, directory clients must instead connect to TCP port 3268.

Ativando Lutieri's translator
.
..
...
.... OK loaded!

Para buscas convencionais LDAP, clientes conectam a porta 389/TCP. Para buscar no catálogo global do Active Directory, clientes precisam conectar a porta 3268/TCP.

Agora eu me coloco a pensar e vejo que: "Sim, eu estava querendo buscar no AD inteiro, pois meu Base DN é dc=xyz,DC=com,DC=br, e conectando na porta 389 que é a padrão.

Para mais informações da opção "AuthLDAPUrl" e saber o que é Base DN consulte a documentação do apache aqui.

Por isso o que me surpreende não foi ter parado de funcionar de um dia pro outro. E sim ter funcionado por algum tempo. Mas... C'est la fucking vie...

Enfim pra solucionar o problema e funcionar de uma vez apresento duas soluções. Ou muda o Base DN e coloca-se um grupo(OU) ou muda-se a porta para conectar. Bom.. qualquer que seja a escolha vai mudar apenas a diretiva "AuthLDAPUrl", portanto vou mostrar apenas o que muda no valor dela:

Solução 1ª:

AuthLDAPUrl "ldap://ad.xyz.com.br/ou=user,dc=xyz,DC=com,DC=br?sAMAccountname?sub?(objectClass=*)"


Solução 2ª:

AuthLDAPUrl "ldap://ad.xyz.com.br:3268/dc=xyz,DC=com,DC=br?sAMAccountname?sub?(objectClass=*)"

Apache 2.2.4 + LDAP = Mudanças [updated]

Recentemente instalei o Apache 2.2.4 no FreeBSD para rodar o Nagios. Porém algumas modificações ocorreram nas versões mais recentes. Já falo mais sobre isso.

A instalação foi tranqüila:

cd /usr/ports/www/apache22
make WITH_LDAP_MODULES=yes install clean

Preciso de suporte a LDAP pois uso autenticação no AD do Windows.
Pra minha surpresa tive alguns erros na autenticação. Alterei o nível do log para degub.

vi /usr/local/etc/apache22/httpd.conf
LogLevel debug
:x

/usr/local/etc/rc.d/apache22 restart ; tail -f /var/log/httpd-error.log

Acompanhando o log de erro, com o comando acima, encontrei essas mensagens ao tentar me autenticar no navegador:

Internal error: pcfg_openfile() called with NULL filename
[client x.x.x.x] (9)Bad file descriptor: Could not open password file: (null)

Googlin' encontrei uma GRANDE quantidade de pessoas com o mesmo problema e encontrei a solução que seria inserir isso no arquivo .htaccess ou na configuração de diretório, enfim no mesmo lugar onde está a configuração da autenticação LDAP:

AuthBasicProvider ldap
AuthUserFile /dev/null

Finalmente não apareceram mais erros no logo, however, a opção "require valid-user" não funciona mais. Encontrei a solução na documentação do apache http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html.en#reqvaliduser.

Para funcionar a diretiva "require valid-user" a opção "AuthzLDAPAuthoritative" precisa ser setada para off.

Outra coisa que mudou foi a opção "require group". Agora se está usando ldap e quer se fazer consulta por grupos deve substituir por "require ldap-group".

Resumindo, meu arquivo de autenticação contra o AD que era assim:

<directory /usr/local/www/nagios/cgi-bin>
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all


AuthType Basic
AuthName "Acesso ao Nagios"

AuthLDAPUrl "ldap://ad.xyz.com.br/ou=sede,dc=xyz,DC=com,DC=br?sAMAccountname?sub?(objectClass=*)"

AuthLDAPBindDN algumuser@xyzcom.br
AuthLDAPBindPassword *******

require group CN=TI,OU=Groups,OU=SEDE,DC=xyz,DC=com,DC=br

</directory>

Acabou ficando assim:

<directory /usr/local/www/nagios/cgi-bin>
AllowOverride None
Options ExecCGI
Order allow,deny
Allow from all

AuthBasicProvider ldap
AuthUserFile /dev/null

AuthType Basic
AuthName "Acesso ao Nagios"

AuthLDAPUrl "ldap://ad.xyz.com.br/ou=sede,dc=xyz,DC=com,DC=br?sAMAccountname?sub?(objectClass=*)"

AuthLDAPBindDN algumuser@xyzcom.br
AuthLDAPBindPassword *******

require ldap-group CN=TI,OU=Groups,OU=SEDE,DC=xyz,DC=com,DC=br
</directory>

Fonte: Google :-D
http://www.mail-archive.com/debian-apache@lists.debian.org/msg08106.html


----

Depois de mais uma instalação agora no FreeBSD 7.0 tive o seguinte warning quando iniciava o apache:

[warn] (2)No such file or directory: Failed to enable the 'httpready' Accept Filter

Numa busca rápida encontrei a solução no VOL. Carregar o módulo accf_http ou usando o comando kldload:

kldload accf_http

ou pra sempre, inserindo no arquivo /boot/loader.conf a seguinte linha:

accf_http_load="YES"

Fonte:
http://www.vivaolinux.com.br/artigos/verArtigo.php?codigo=5277&pagina=3

O tempo passa...

delphi