{"id":378,"date":"2012-10-26T12:57:28","date_gmt":"2012-10-26T14:57:28","guid":{"rendered":"http:\/\/www.viazap.com.br\/?p=378"},"modified":"2012-10-26T12:57:28","modified_gmt":"2012-10-26T14:57:28","slug":"autenticacao-por-desafio-e-resposta-no-ssh","status":"publish","type":"post","link":"https:\/\/blog.clusterweb.com.br\/?p=378","title":{"rendered":"Autentica\u00e7\u00e3o por desafio e resposta no SSH"},"content":{"rendered":"\n\n\n\n\n\n\n
Introdu\u00e7\u00e3o<\/strong><\/p>\n
Acredito que o SSH<\/em> n\u00e3o precise ser apresentado e tampouco detalhes de sua instala\u00e7\u00e3o. At\u00e9 porque em praticamente todas as instala\u00e7\u00f5es ele j\u00e1 vem instalado por padr\u00e3o, seja o cliente ssh ou o servidor. Em algumas o servidor precisa ser explicitamente instalado, como \u00e9 o caso do Ubuntu<\/em>. Mas n\u00e3o se apresse, \u00e9 prov\u00e1vel que voc\u00ea n\u00e3o precise de um servidor SSH em seu console, j\u00e1 que este \u00e9 um recurso desej\u00e1vel justamente em servidores.<\/p>\n

O SSH funciona sobre o protocolo SSL<\/em>, da mesma forma que o HTTPS. Como o uso do SSH \u00e9 feita por administradores e n\u00e3o por usu\u00e1rios leigos, \u00e9 extremamente incomum o uso de certificados digitais neste caso. Afinal um administrador de redes experiente n\u00e3o ir\u00e1 cair na pegadinha do ataque do homem do meio (onde uma outra m\u00e1quina se faz passar pelo teu servidor).<\/p>\n

Durante o primeiro acesso seria prudente que o cliente verificasse se realmente \u00e9 o servidor. Observe no exemplo a seguir as mensagens gerados pelo servidor no primeiro acesso:<\/p>\n

$ ssh elgio@10.2.3.4<\/strong>
\nThe authenticity of host ‘10.2.3.4 (10.2.3.4)’ can’t be established.<\/p>\n

RSA key fingerprint is ff:7b:35:74:cd:4c:59:0b:4b:b5:cf:fe:eb:f4:ec:7a.<\/p>\n

Are you sure you want to continue connecting (yes\/no)? yes<\/strong>
\nWarning: Permanently added ‘10.2.3.4,10.2.3.4’ (RSA) to the list of known hosts.<\/p>\n

Observe que ele lhe pede que confirme que este \u00e9 mesmo o servidor. Neste ponto, se tiver certeza (e pode verificar o fingerprint), ao digitar “yes” a chave do servidor ser\u00e1 armazenada em ~\/.ssh\/know_hosts<\/em>.<\/p>\n

A partir deste momento, nenhuma outra mensagem de aviso ocorrer\u00e1, salvo se o servidor for reinstalado ou se estiver mesmo sobre um ataque do homem do meio. Mas a\u00ed a mensagem ser\u00e1 de recusar a conex\u00e3o.<\/p>\n

Meu objetivo n\u00e3o \u00e9 exatamente descrever o SSH em si, mas sim alguns recursos pouco usados do mesmo. Um deles \u00e9 o login por desafio\/resposta usando uma chave p\u00fablica e privada.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n

Como funciona o desafio resposta<\/strong><\/p>\n
Basicamente consiste em o servidor enviar um desafio para voc\u00ea que somente voc\u00ea poderia resolver. Se voc\u00ea acertar o desafio, passou no teste e pode autenticar-se.<\/p>\n

Para explicar melhor o que \u00e9 o desafio resposta, costumo usar um exemplo did\u00e1tico, por\u00e9m extremamente fraco. Serve para explicar a ideia, mas n\u00e3o deve jamais ser usado por ser fr\u00e1gil.<\/p>\n

Suponha que o cliente possua um segredo que \u00e9 um n\u00famero inteiro. Podemos cham\u00e1-lo de senha. O servidor conhece este segredo e permitir\u00e1 login para qualquer um que provar conhec\u00ea-lo. A autentica\u00e7\u00e3o poderia ser da forma cl\u00e1ssica:<\/p>\n

    \n
  1. o cliente conta para o servidor a sua senha;<\/li>\n
  2. o servidor verifica se ele acertou a senha;<\/li>\n
  3. servidor aceita ou n\u00e3o o login.<\/li>\n<\/ol>\n

    Por\u00e9m o m\u00e9todo anterior possui um problema: a senha \u00e9 enviada pela rede e algu\u00e9m poder\u00e1 capturar ela e se logar no futuro como sendo o cliente.<\/p>\n

    A mesma solu\u00e7\u00e3o anterior, por\u00e9m baseada em desafio e resposta, poderia ser:<\/p>\n

      \n
    1. servidor envia uma express\u00e3o matem\u00e1tica para cliente resolver usando o seu segredo;<\/li>\n
    2. cliente resolve a express\u00e3o e envia apenas a resposta;<\/li>\n
    3. servidor, que tamb\u00e9m conhece o segredo, v\u00ea se cliente acertou a resposta;<\/li>\n
    4. se acertou, aceita login.<\/li>\n<\/ol>\n

      Pode parecer a mesma coisa, mas a ideia \u00e9 que a express\u00e3o matem\u00e1tica mude aleatoriamente a cada solicita\u00e7\u00e3o. Se algu\u00e9m estiver capturando o tr\u00e1fego n\u00e3o poder\u00e1 usar a resposta em um login futuro, pois o servidor ir\u00e1 solicitar outra express\u00e3o matem\u00e1tica. Esta express\u00e3o pode ser uma simples multiplica\u00e7\u00e3o, como demonstra a figura:<\/p>\n

      \"Linux:<\/a><\/div>\n

      O exemplo da figura anterior ilustra como \u00e9 a t\u00e9cnica, mas n\u00e3o deve ser usado. Isto porque um atacante conseguir\u00e1 descobrir muito facilmente a chave, bastando dividir 4305 por 123, pois ele viu o desafio e viu a resposta. Opera\u00e7\u00f5es matem\u00e1ticas que possam ser revertidas n\u00e3o devem ser usadas (divis\u00e3o reverte a multiplica\u00e7\u00e3o, soma reverte a subtra\u00e7\u00e3o). Se usar outra opera\u00e7\u00e3o mais complexa que n\u00e3o possa ser desfeita e com n\u00fameros realmente muito grandes a t\u00e9cnica poder\u00e1 ser usada.<\/p>\n

      Um exemplo de uma opera\u00e7\u00e3o matem\u00e1tica irrevers\u00edvel \u00e9 a de m\u00f3dulo, usada no RSA. Apesar de fugir um pouco do foco deste artigo, pois ainda est\u00e1 na minha gaveta um artigo sobre RSA, vale o exemplo:<\/p>\n

Desafio e resposta no ssh<\/strong><\/p>\n
O ssh<\/em> \u00e9 suficientemente seguro se bem usado. Se voc\u00ea tem certeza da idoneidade do servidor e se tem certeza de que realmente \u00e9 o servidor, tudo bem. N\u00e3o h\u00e1 qualquer problema voc\u00ea digitar sua senha de acesso. Ela n\u00e3o poder\u00e1 ser lida por mais ningu\u00e9m.<\/p>\n

Isto porque toda a sess\u00e3o ssh \u00e9 protegida por um forte algoritmo de criptografia sim\u00e9trico. Quando voc\u00ea digita sua senha ela \u00e9 cifrada com este algoritmo e transmitida pela Internet. Algu\u00e9m, em posi\u00e7\u00e3o de capturar o tr\u00e1fego, n\u00e3o conseguir\u00e1 obter esta senha.<\/p>\n

Por\u00e9m existe ainda uma forma de executar o login sem precisar enviar a senha. E uma forma segura. Mas porque n\u00e3o enviar a senha? V\u00e1rios motivos.<\/p>\n

Primeiro uma seguran\u00e7a a mais, pois agora a senha sequer viaja pela Internet, nem mesmo cifrada. Na hip\u00f3tese, mesmo remota, de algu\u00e9m estar aplicando um ataque do homem do meio ou de que o servidor estar corrompido, o atacante realmente n\u00e3o ter\u00e1 sua senha, de forma alguma.<\/p>\n

Um segundo motivo pode ser a facilidade de manuten\u00e7\u00e3o. As vezes \u00e9 chato ter que ficar colocando v\u00e1rias vezes a senha, principalmente se todos fizerem a coisa certa, de n\u00e3o usar a mesma senha em todos os servidores (por experi\u00eancia pessoal, sou c\u00e9tico quanto a isto!).<\/p>\n

Para resolver este problema o ssh possui o login por desafio e resposta atrav\u00e9s do uso de um par de chaves p\u00fablica e privada. Voc\u00ea primeiro deve criar um par de chaves para si, uma chave p\u00fablica e privada. A chave privada voc\u00ea mant\u00e9m em segredo, guarda-a em seguran\u00e7a. J\u00e1 a chave p\u00fablica voc\u00ea deposita no servidor e diz para o ssh aceitar conex\u00f5es de qualquer um que prove ser o conhecedor da chave privada.<\/p>\n

O conceito dos algoritmos assim\u00e9tricos garante que tudo que foi cifrado com a chave p\u00fablica, apenas a chave privada poder\u00e1 abrir. Assim o desafio gerado pelo servidor passa a ser o seguinte:<\/p>\n

    \n
  1. servidor escolhe aleatoriamente uma sequ\u00eancia de bits grande (exemplo: 2048 bits aleat\u00f3rios);<\/li>\n
  2. servidor cifra estes bits com a chave p\u00fablica do suposto cliente e envia;<\/li>\n
  3. cliente precisa dizer ao servidor qual era a sequ\u00eancia escolhida;<\/li>\n
  4. cliente s\u00f3 pode fazer isto com sucesso se conhecer a chave privada.<\/li>\n<\/ol>\n

    Este m\u00e9todo \u00e9 ainda melhor que o descrito antes, pois n\u00e3o envolve a senha do usu\u00e1rio em nenhum momento, apenas a chave privada dele. Esta chave passar\u00e1 a ser a parte sens\u00edvel e deve ser protegida. Como ningu\u00e9m conseguir\u00e1 decorar uma chave de milhares de bits, ela precisa ser armazenada.<\/p>\n

    Armazenar \u00e9 um problema, pois pode-se supor at\u00e9 o roubo do HD onde um atacante teria a chave e se logaria em seus servidores. Para evitar isto, o ssh permite que voc\u00ea proteja sua chave com uma frase de passagem, que voc\u00ea poder\u00e1 lembrar-se. Pode ser qualquer sequ\u00eancia de caracteres que ser\u00e1 solicitada pelo seu programa cliente quando voc\u00ea fizer o login.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n

Configura\u00e7\u00e3o do ssh para autentica\u00e7\u00e3o por desafio e resposta<\/strong><\/p>\n
A autentica\u00e7\u00e3o por desafio resposta no ssh<\/em> deve estar habilitada no ssh server. Por minha experi\u00eancia, todos os servidores ssh j\u00e1 vem com isto habilitado, mas conv\u00e9m verificar. Apenas verifique se a informa\u00e7\u00e3o PubkeyAuthentication<\/em> no \/etc\/ssh\/sshd_config<\/em> n\u00e3o est\u00e1 em “no”. Normalmente ela est\u00e1 comentada no arquivo, o que significa que est\u00e1 ativa (o padr\u00e3o \u00e9 permitir):<\/p>\n

# grep Pubkey \/etc\/ssh\/sshd_config <\/strong>
\n#PubkeyAuthentication yes<\/p>\n

Se ela estiver comentada ou com “yes”, tudo bem. Mas se estiver com “no”, comente a regra ou mude para “yes” e reinicie o ssh server.<\/p>\n

Com o servidor configurado para aceitar esta forma de autentica\u00e7\u00e3o, deve-se ainda realizar os seguintes passos:<\/p>\n

    \n
  1. criar um par de chaves<\/li>\n
  2. instalar a tua chave p\u00fablica no servidor<\/li>\n<\/ol>\n

    Usarei o usu\u00e1rio fulano como teste neste artigo.<\/p>\n

    Cria\u00e7\u00e3o do par de chaves<\/h1>\n

    Usu\u00e1rio fulano tem um login e senha no servidor 10.2.3.4. O cliente \u00e9 a m\u00e1quina didak\u00e9 (nome do meu notebook). Primeiro ele se logou com seu usu\u00e1rio e senha, s\u00f3 para testar:<\/p>\n

    $ ssh 10.2.3.4 <\/strong>
    \nThe authenticity of host ‘10.2.3.4 (10.2.3.4)’ can’t be established.
    \nRSA key fingerprint is fb:a9:ac:b6:3d:3f:42:76:11:cc:44:2f:7f:55:49:97.
    \nAre you sure you want to continue connecting (yes\/no)? yes<\/strong>
    \nWarning: Permanently added ‘10.2.3.4’ (RSA) to the list of known hosts.
    \nPassword:
    \nHave a lot of fun…<\/p>\n

    Voltando a m\u00e1quina cliente, a didak\u00e9, ele cria seu par de chaves com o ssh-keygen. Os par\u00e2metros indicam criar chaves usando o algoritmo dsa e com 1024 bits de tamanho. Se voc\u00ea n\u00e3o especificar o DSA, o algoritmo RSA ser\u00e1 usado. O protocolo RSA n\u00e3o \u00e9 usado por padr\u00e3o no ssh e n\u00e3o funcionar\u00e1 a menos que voc\u00ea coloque o par\u00e2metro RSAAuthentication yes<\/em> no \/etc\/ssh\/sshd_config<\/em>. Este \u00e9 desabilitado por padr\u00e3o.<\/p>\n

    $ ssh-keygen -b 1024 -t dsa <\/strong>
    \nGenerating public\/private dsa key pair.
    \nEnter file in which to save the key (\/home\/fulano\/.ssh\/id_dsa):
    \nEnter passphrase (empty for no passphrase):
    \nEnter same passphrase again:
    \nYour identification has been saved in \/home\/fulano\/.ssh\/id_dsa.
    \nYour public key has been saved in \/home\/fulano\/.ssh\/id_dsa.pub.
    \nThe key fingerprint is:
    \n4e:e4:ab:5c:5d:06:58:83:95:4a:77:1d:a0:7d:e7:ba fulano@didake
    \nThe key’s randomart image is:<\/p>\n

    +--[ DSA 1024]----+ \r\n|         o+..o.. | \r\n|        ooo+. .  | \r\n|       .ooo.. . .| \r\n|       o.  . . o | \r\n|        S   o   .| \r\n|       o o o   . | \r\n|        + .   .  | \r\n|     . o       . | \r\n|      o       E  | \r\n+-----------------+<\/pre>\n
    Quando ele perguntar “Enter file in which to save the key (\/home\/fulano\/.ssh\/id_dsa): ” simplesmente d\u00ea um enter aceitando esta sugest\u00e3o.<\/p>\n
    Como frase de passagem eu coloquei “Viva o Linux<\/a> 2009″. Pode ser qualquer coisa, mas tome cuidado pois voc\u00ea deve digitar exatamente a mesma coisa quando solicitado. Se digitar “Viva o LINUX 2009” j\u00e1 n\u00e3o ser\u00e1 a mesma frase, pois Linux est\u00e1 tudo em caixa alta. Desaconselha-se deixar sem frase de passagem, mas \u00e9 uma configura\u00e7\u00e3o poss\u00edvel.<\/p>\n
    Instala\u00e7\u00e3o da chave p\u00fablica no servidor<\/h1>\n
    A instala\u00e7\u00e3o da chave p\u00fablica no servidor consiste em simplesmente colocar ela dentro do arquivo ~\/.ssh\/authorized_keys<\/em>. Este arquivo pode ter v\u00e1rias chaves p\u00fablicas, n\u00e3o apenas uma.<\/p>\n
    Para realizar esta tarefa o usu\u00e1rio fulano precisar\u00e1 logar-se no servidor, usando ainda sua senha. A chave p\u00fablica criada est\u00e1 em ~\/.ssh\/id_dsa.pub<\/em> no cliente e home do fulano. Ela \u00e9 texto puro (base64) logo pode-se at\u00e9 dar um cat nela:<\/p>\n
    $ cat id_dsa.pub <\/strong>
    \nssh-dss AAAAB3NzaC1kc3MAAACBAKaOHlNYzozRRr0Ub1kAi\/mBap55fQCda0t4T4rZnskdqX \/gMnKvLP8B514b3Oq8exNCkTym6nyv1LyxxG1VmhpjKN8N8eDaErp\/8qEif\/GvH3HaFx4GJBWFed4Z6K9HkxsBy2yFwfcBmkvGFP3ggMwhBnKYFf7DSa9\/0QzHDDx3AAAAFQDEb5c3RMsEo8xU6YsvVXnIlJteLQAAAIA+3Oa2X2oW2gprZkCRe7JE +KWvH+O9xjep\/7l6iGFww9IDj35VgEHMzAr6LPvw+rAOB1P5qoXZr3hbTU6pzfHiSLy6UD G+LzHLRbyImZOH\/p+n7hWtEfZs6mO5ZuJFxO3fStQKWy0r48XUEaduHY5PGQc+sa\/fpjyS2BPToM46XgAAAIAzsUHfOZnFhGK5cmMGjEFyjQBIKqYxRo3pR2H0au\/ObwrKan6rCEqWropJElI234AeIymOS2h4Hr3lHnbmyXsxxCt14xqE7ZQlq5X7DV2QCl 0PUcgGlbVSLNTGLXapW1KN2tiBv7u8Q0agNgZ3ek3XHTKtZ6jVm0eb\/ACsg0D+Sw== fulano@didake<\/p>\n
    N\u00e3o fa\u00e7a o mesmo para a chave privada, pois ela n\u00e3o \u00e9 em formato texto, \u00e9 bin\u00e1rio.<\/p>\n
    Ent\u00e3o, basta pegar esta sequ\u00eancia esquisita de caracteres e copi\u00e1-la, assim como est\u00e1, para o servidor. No Gnome pode-se at\u00e9 mesmo usar o recurso de copiar e colar do sistema, como demonstra a sequ\u00eancia de imagens.<\/p>\n
    \"Linux:<\/a><\/div>\n
    Selecionando a chave p\u00fablica no cliente, arquivo ~\/.ssh\/id_dsa.pub e usando o “Copy” do pr\u00f3prio Gnome.<\/p>\n
    \"Linux:<\/a><\/div>\n
    Ap\u00f3s, loga-se no servidor 10.2.3.4 ainda usando sua senha, e coloca-se a chave dentro do arquivo authorized_keys em ~\/.ssh. No caso eu usei o simples cat com redirecionamento (cat >> authorized_keys).<\/p>\n
    \"Linux:<\/a><\/div>\n
    Ao final, ap\u00f3s colar, deve-se pressionar Control+D e o arquivo est\u00e1 com a chave p\u00fablica. Na imagem, ap\u00f3s o t\u00e9rmino, executei um cat para verificar.<\/p>\n
    Outras tantas formas podem ser usadas para obter-se o mesmo resultado, como simplesmente editar o arquivo authorized-keys<\/em> com algum editor qualquer. O fato \u00e9 que ele deve ter a chave p\u00fablica.<\/p>\n
    Por fim, ap\u00f3s a instala\u00e7\u00e3o, pode-se verificar se est\u00e1 funcionando. fulano sai do servidor e tenta-se logar novamente:<\/p>\n
    $ ssh 10.2.3.4 <\/strong>
    \nEnter passphrase for key ‘\/home\/fulano\/.ssh\/id_dsa’:
    \nLast login: Mon Jul 27 13:40:02 2009 from 10.1.0.10
    \nHave a lot of fun…<\/p>\n
    Agora ele pediu a frase de passagem que protege a chave p\u00fablica. No caso eu tive que digitar o “Viva o Linux 2009” para poder me logar.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n

Conclus\u00e3o<\/strong><\/p>\n
O uso desta forma de autentica\u00e7\u00e3o \u00e9 considerado mais seguro que com usu\u00e1rio e senha. Por\u00e9m a maior vantagem, na minha opini\u00e3o, \u00e9 ser bem mais pr\u00e1tico.<\/p>\n

Pr\u00e1tico porque voc\u00ea pode colocar senhas diferentes em seus servidores e logar-se neles apenas por desafio e resposta, decorando apenas a sua frase de passagem. Pode colocar sua chave p\u00fablica em todas as m\u00e1quinas Linux<\/a> que voc\u00ea deseja acessar.<\/p>\n

Mais pr\u00e1tico tamb\u00e9m porque hoje muitos chaveiros permitem armazenar a frase de passagem, solicitando-a apenas uma \u00fanica vez por sess\u00e3o e fazendo realmente um login sem senha nas conex\u00f5es posteriores. \u00c9 o caso do Gnome (e n\u00e3o uso KDE para testar).<\/p>\n

Muitas coisas fant\u00e1sticas podem ser realizadas com esta t\u00e9cnica, algumas com bastante cuidado, evidente. Eu, por exemplo, em um curso de Linux, criei um par de chaves e o coloquei no \/root\/.ssh\/authorized_keys de todas as m\u00e1quinas dos alunos. Assim, a partir do meu notebook, eu podia executar remotamente qualquer comando nas m\u00e1quinas e sem senha, pois usava o lembrete de senhas do Gnome.<\/p>\n

Para desligar uma m\u00e1quina, bastou um:<\/p>\n

$ ssh root@10.2.3.4 “\/sbin\/shutdown -h now” <\/strong><\/p>\n

Isto dentro de um for, permite executar em todas as m\u00e1quinas. Um exemplo mais interessante foi quando precisei que os alunos tivessem poderes de root as vezes, mas n\u00e3o sempre. Quando eu queria lhes dar esta permiss\u00e3o para todas as 20 m\u00e1quinas, executava do meu notebook:<\/p>\n

$ for IP in `cat ubuntu.txt`; do
\nssh root@$IP “\/usr\/sbin\/adduser aluno admin”
\ndone
\necho OK<\/strong><\/p>\n

E dentro do arquivo ubuntu.txt tinha os IPs dos clientes, um por linha (nota: no ubuntu o adduser pode ser usado para inserir um usu\u00e1rio j\u00e1 existente em um grupo). Se, depois, n\u00e3o quero mais que o usu\u00e1rio aluno tenha poderes de root, ent\u00e3o:<\/p>\n

$ for IP in `cat ubuntu.txt`; do
\nssh root@$IP “\/usr\/sbin\/deluser aluno admin”
\ndone
\necho OK<\/strong><\/p>\n

Isto porque no Ubuntu para poder usar o sudo basta estar no grupo admin (e no ubuntu o deluser pode ser usado para remover um usu\u00e1rio de um grupo. Nesta forma de uso, o usu\u00e1rio em si n\u00e3o \u00e9 removido, apenas sai do grupo).<\/p>\n

Se voc\u00ea gerencia dezenas de m\u00e1quinas pode ser extremamente criativo e deixar os scripts trabalharem por voc\u00ea.<\/p><\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n","protected":false},"excerpt":{"rendered":"

Introdu\u00e7\u00e3o Acredito que o SSH n\u00e3o precise ser apresentado e tampouco detalhes de sua instala\u00e7\u00e3o. At\u00e9 porque em praticamente todas as instala\u00e7\u00f5es ele j\u00e1 vem instalado por padr\u00e3o, seja o cliente ssh ou o servidor. Em algumas o servidor precisa ser explicitamente instalado, como \u00e9 o caso do Ubuntu. Mas n\u00e3o se apresse, \u00e9 prov\u00e1vel […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[1,51,68],"tags":[205,14,206,204],"class_list":["post-378","post","type-post","status-publish","format-standard","hentry","category-viazap","category-linux-linuxrs","category-redes-2","tag-desafio","tag-linux","tag-scripts","tag-ssh"],"_links":{"self":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/378","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=378"}],"version-history":[{"count":1,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/378\/revisions"}],"predecessor-version":[{"id":379,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=\/wp\/v2\/posts\/378\/revisions\/379"}],"wp:attachment":[{"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=378"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=378"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.clusterweb.com.br\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=378"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}