serviços de transferência de arquivos e de acesso remoto · 1 - serviÇo ftp ftp, file transfer...

Prática e Administração de Sistemas Operacionais de Redes Livres

Serviços de transferência de arquivose de acesso remoto

Serviços FTP, TELNET, SSH eSegurança TCP-WRAPPERS

Outubro/2017

Prof. Jairo

[email protected]

[email protected]

http://www.jairo.pro.br/

SERVIÇOS FTP, TELNET, SSH E SEGURANÇA TCP-WRAPPERS http://www.jairo.pro.br/ 1/24


Este material tem por única intenção reunir um conteúdo acadêmico necessário para auxiliar no ensino da disciplina "Prática e Administração de Sistemas Operacionais de Redes Livres", ministrado nos cursos de Tecnologias em Redes de Computadores e Segurança da Informação.

O conteúdo aqui exposto pode ser livremente redistribuído e usado como apoio de aula, desde que mantenha a sua integridade original.

O arquivo "ftp-telnet-ssh.pdf" pode ser livremente acessado em "http://www.jairo.pro.br/prat_adm_sist_oper/".

Qualquer crítica ou sugestão, favor entrar em contato com o Prof. Jairo no endereço eletrônico "[email protected]" ou "[email protected]".

Sumário1 - SERVIÇO FTP................................................................................................................................3

1.1 - Instalação do serviço FTP standalone.....................................................................................31.2 - Configuração do serviço FTP vsftpd.......................................................................................41.3 - Cliente de serviço FTP............................................................................................................5

2 - SEGURANÇA TCP-WRAPPERS..................................................................................................73 - SERVIÇO TELNET........................................................................................................................8

3.1 - Instalação do serviço TELNET xinetd....................................................................................83.2 - Configuração do serviço TELNET xinetd...............................................................................93.3 - Cliente de serviço TELNET..................................................................................................13

4 - SERVIÇO SSH..............................................................................................................................144.1 - Instalação do serviço OpenSSH............................................................................................154.2 - Clientes do serviço SSH........................................................................................................17

4.2.1 - Cliente ssh......................................................................................................................184.2.2 - Cliente scp.....................................................................................................................194.2.3 - Cliente sftp.....................................................................................................................20

4.3 - Relação de confiança SSH.....................................................................................................214.4 - Impedir o root de logar diretamente no serviço.....................................................................23



1 - SERVIÇO FTP

FTP, File Transfer Protocol, é um protocolo bem antigo que teve origem no início dos anos 1970. Surpreendentemente, nos dias de hoje continua sendo muito usado.

Um dos principais serviços FTP usados hoje é o vsftpd, que tem esse nome das iniciais very secure file transfer protocol daemon, e por isso será usado.

NOTA: no mundo do software livre, existem muitas implementações de um mesmo conceito, implementações estas que competem entre si. Cabe ao administrador do sistema escolher qual é a melhor implementação para o momento.

1.1 - Instalação do serviço FTP standalone

Como primeiro passo, verificar se o serviço vsftpd está instalado. Num Ubuntu (ou Debian), comandar:

NOTA 1: não havendo saída no comando acima, significa que não está instalado.

NOTA 2: num CentOS ou Red Hat, o comando seria "rpm -aq | grep -i vsftpd".

Para instalar o vsftpd num Ubuntu ou Debian, comandar:

NOTA: num CentOS ou Red Hat, o comando para instalar seria "yum install vsftpd".

Num sistema SystemV, depois de instalado o serviço, deverá haver o arquivo de inicialização (administração) do serviço, /etc/init.d/vsftpd:

NOTA: num sistema SystemD, por exemplo CentOS 7, o arquivo equivalente é o


root# apt-get install vsftpd

root# dpkg -l | grep -i vsftpd

root# ls /etc/init.d | grep vsftpd/etc/init.d/vsftpd


/usr/lib/systemd/system/vsftpd.service.

Verificar as configurações do arquivo com o comando more:

Para funcionar o serviço, também é necessário que esteja instalado o executável /usr/sbin/vsftpd [daemon do serviço FTP]. Isso pode ser verificado com o comando ls:

1.2 - Configuração do serviço FTP vsftpd

Num Ubuntu ou Debian, o arquivo de configuração é /etc/vsftpd.conf. Para saber o que está configurado, verificar as linhas sem comentário com o comando grep:

NOTA: num CentOS ou Red Hat o arquivo está em /etc/vsftpd/vsftpd.conf.

O arquivo vsftpd.conf precisa ser configurado e incluído (ou descomentado) o seguinte conteúdo:

=== /etc/vsftpd/vsftpd.conf ===local_enable=YESwrite_enable=YESchroot_local_user=NOtcp_wrappers=YES========================

As configurações acima são:

• local_enable=YES: para permitir o acesso para todos os usuários locais;• write_enable=YES: para permitir a escrita (upload) no servidor FTP;• chroot_local_user=NO: para não manter os usuários restritos (jail) a suas homes;


root# ls /usr/sbin/vsftpd/usr/sbin/vsftpdroot# file /usr/sbin/vsftpd/usr/sbin/vsftpd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32

root# more /etc/init.d/vsftpd

root# grep -v "^#" /etc/vsftpd.conf


• tcp_wrappers=YES: para ter controle sobre quem está acessando o serviço.

Depois de feita a configuração acima, o serviço precisa ser (re)iniciado. Num Ubuntu ou Debian o serviço já inicia por default com a instalação pelo apt-get, então neste caso reiniciar o serviço.

Num sistema SystemV, comandar:

NOTA: comandar "systemctl restart vsftpd" para reiniciar o serviço num sistema SystemD.

1.3 - Cliente de serviço FTP

Sabendo que foi disponibilizado serviço FTP na máquina com endereço IP, por exemplo, 192.168.1.10, usar a aplicação cliente ftp para fazer o acesso a este serviço:

NOTA: obtendo o acesso, ganha o prompt do shell cliente ftp.

Nesse prompt, comandar "?" para visualizar a lista de comandos disponíveis no acesso ftp:


shell$ ftp 192.168.1.10Connected to 192.168.1.10.220 (vsFTPd 2.3.5)Name (Lab10:aluno): aluno331 Password required for alunoPassword:230 User aluno logged in.Remote system type is UNIX.Using binary mode to transfer files.ftp>

root# /etc/init.d/vsftpd restart


Para enviar um arquivo, usar "put", para enviar vários arquivos de uma única vez, usar "mput". Para baixar um arquivo, usar "get", para baixar vários arquivos de uma única vez usar "mget". O comando "ascii" configura a transferência para arquivo de texto [e não binário].

Por exemplo, o usuário aluno logado no servidor FTP em 192.168.1.10 irá baixar o arquivo /etc/passwd para o diretório /tmp da sua máquina local (Linux):

Se fosse o caso de enviar um arquivo do cliente para o servidor, o comando seria "put" e não "get". Com "mget" ou "mput" podem ser usados curingas "*", e assim transferir vários arquivos de uma única vez. Mas antes de usar "mget" ou "mput", é usual comandar "prompt off" para não precisar confirmar o download ou upload de arquivo por arquivo.


ftp> ?Commands may be abbreviated. Commands are:

! debug mdir sendport site$ dir mget put sizeaccount disconnect mkdir pwd statusappend exit mls quit structascii form mode quote systembell get modtime recv suniquebinary glob mput reget tenexbye hash newer rstatus tickcase help nmap rhelp tracecd idle nlist rename typecdup image ntrans reset userchmod lcd open restart umaskclose ls prompt rmdir verbosecr macdef passive runique ?delete mdelete proxy send

ftp> pwd257 "/home/aluno" is the current directoryftp> cd /etc250 CWD command successfulftp> lcd /tmpLocal directory now /tmpftp > ascii200 Type set to Aftp> get passwdlocal: passwd remote: passwdftp> bye221 Goodbye.shell$


2 - SEGURANÇA TCP-WRAPPERS

TCP-Wrappers é um controle no acesso pela rede, usado como filtro para impedir clientes dedeterminados endereços ou redes de acessarem serviços. O controle TCP-Wrappers é feito na mesma máquina aonde está o serviço.

Ter controle no acesso a determinado serviço é muito importante para a segurança, especialmente quando estamos disponibilizando serviços típicos da internet, onde os acessos podemocorrer de qualquer lugar do mundo.

O controle do acesso é feito pelo executável /usr/sbin/tcpd, que normalmente é instalado por default. Mas caso ainda não esteja instalado, basta instalar o pacote tcpd num Ubuntu ou Debian, e pacote tcp_wrappers num CentOS ou Red Hat.

As configurações do TCP-Wrapper são locais ao host, nos arquivos "/etc/hosts.allow" e "/etc/hosts.deny", mas dependem da biblioteca libwrap. Ou seja, apenas os serviços compilados contra essa biblioteca é que podem ser configurados para ter esse controle no acesso. Por questões históricas, o servidor xinetd suporta TCP-Wrappers, bem como uma parte das implementações de serviços SSH. O serviço FTP vsftpd também suporta TCP-Wrappers.

Tipicamente, as configurações TCP-Wrapper envolvem bloquear o acesso para todos no arquivo /etc/hosts.deny, e posteriormente liberar o acesso no arquivo /etc/hosts.allow para alguns endereços IPs ou redes.

Desse modo, as configurações abaixo liberam o acesso aos serviços TELNET e FTP. No caso do TELNET, apenas para clientes com IPs da rede 192.168.1.0/24 e também para o IP 10.1.2.3.No caso do serviço FTP, essas configurações liberam o acesso para qualquer IP:

=== /etc/hosts.deny ===ALL: ALL==================

=== /etc/hosts.allow ===================in.telnetd: 10.1.2.3, 192.168.1.0/255.255.255.0vsftpd: ALL===================================

Convém notar que a configuração em /etc/hosts.deny está impedindo o acesso a todo serviço [ALL] para todo IP ou rede [ALL], daí a notação ALL:ALL. Desse modo, no /etc/hosts.allow precisa declarar alguma liberação de acesso para o serviço que use TCP-Wrapper.



3 - SERVIÇO TELNET

O serviço telnet oferece acesso em linha de comando [shell] a um cliente remoto. O protocolo TELNET também é muito antigo, e foi desenvolvido em 1969. No entanto, ainda é usado atualmente.

Na época de criação do TELNET e FTP, a segurança no acesso em rede era um aspecto secundário, e por isso tanto TELNET quanto FTP não implementam criptografia na transmissão de dados. Por isso, atualmente estes serviços deveriam ser substituídos por SSH.

3.1 - Instalação do serviço TELNET xinetd

O serviço telnet, neste caso, será instalado debaixo do xinetd, portanto não será standalone.

Num Ubuntu ou Debian, para descobrir se o serviço xinetd está instalado, uma dica simples é procurar pelo pacote xinetd, com o comando dpkg:

NOTA 1: não havendo saída do comando acima, significa que não está instalado.

NOTA 2: num CentOS ou Red Hat, o comando seria "rpm -aq | grep -i xinetd".

Para instalar o xinetd num Ubuntu ou Debian, comandar:

NOTA: num CentOS ou Red Hat, o comando para instalar seria "yum install xinetd".

Após instalado, verificar se existem os seguintes arquivos:

• /etc/xinetd.conf: é o arquivo de configuração, que aponta para o diretório /etc/xinetd.d;


root# apt-get install xinetd

root# dpkg -l | grep -i xinetd


• /etc/xinetd.d: é o diretório onde estão os arquivos de configuração dos serviços xinetd;• /usr/sbin/xinetd: é o executável que ao rodar dá origem ao processo daemon.

É importante lembrar que o serviço xinetd apenas disponibiliza serviços a partir do daemon xinetd, então é necessário também verificar se o serviço telnet está instalado para rodar sobre o xinetd.

Deste modo, é necessário verificar se está instalado o serviço telnet. Num Ubuntu ou Debian, comandar:

NOTA 1: não havendo saída do comando acima, significa que não está instalado.

NOTA 2: num CentOS ou Red Hat, o comando seria "rpm -aq | grep telnet-server".

Para instalar o telnetd num Ubuntu ou Debian, comandar:

NOTA: num CentOS ou Red Hat, o comando seria "yum install telnet-server".

Após instalado, verificar se existe o arquivo /usr/sbin/in.telnetd, que é o daemon do serviçotelnet:

NOTA: o fato de instalar o serviço TELNET sobre o xinetd não significa que este serviço não possa ser disponibilizado de outro modo, por exemplo inetd ou standalone. Porém, na maior parte dos casos de instalação em Linux, TELNET será um serviço disponibilizado sobre o daemon xinetd.

3.2 - Configuração do serviço TELNET xinetd


root# apt-get install telnetd

root# dpkg -l | grep telnetd

root# file /usr/sbin/in.telnetd/usr/sbin/in.telnetd: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses sharedlibs), for GNU/Linux 2.6.15, BuildID[sha1]=0xe3e1bf5cc444f9ed6c6d86ca678d704029fa6cee, stripped


Nos sistemas Ubuntu, Debian, CentOS e Red Hat, a instalação do serviço telnet não instala oarquivo de configuração desse serviço em /etc/xinetd.d/telnet. Desse modo, precisa ser criado ou copiado de algum lugar. O jeito mais fácil é baixar de www.jairo.pro.br com o comando wget:

Caso haja um proxy no meio do caminho, que é o caso de acesso à internet a partir dos laboratórios acadêmicos da Uninove, antes de comandar wget precisa passar a instrução de usuárioe senha para a variável http_proxy, e isso é feito com o comando export:

Onde:

RA: é o RA do aluno;SENHA: é a senha de acesso do aluno;186.251.39.92: é o IP do serviço proxy, que atende na porta 3128 (é um Squid).

No arquivo de configuração /etc/xinetd.d/telnet baixado de www.jairo.pro.br deverá ter o seguinte conteúdo:

===== /etc/xinetd.d/telnet ===========================# default: on# description: The telnet server serves telnet sessions; it uses \# unencrypted username/password pairs for authentication.service telnet{

disable = noflags = REUSEsocket_type = streamwait = nonice = 10user = rootserver = /usr/sbin/in.telnetdlog_on_failure += USERID

}===============================================

NOTA: se a configuração disable estiver "disable = yes", o serviço telnet não vai iniciar na inicialização do xinetd.

Outra maneira de obter o arquivo de configuração /etc/xinetd.d/telnet é através do


root# cd /etc/xinetd.droot# wget www.jairo.pro.br/telnet

root# export http_proxy=http://RA:[email protected]:3128


comando man xinetd.conf:

Neste manual, existe a descrição da configuração do serviço xinetd, que inclui exemplos. Basta então procurar pelo serviço telnet e recortar 9 linhas abaixo do padrão encontrado:

Feita esta verificação, basta redirecionar a saída para o arquivo telnet:

Depois de obtido o arquivo de configuração, fazer os acertos nas configurações conforme explicado anteriormente.

E com isso está instalado e configurado o serviço TELNET para rodar sobre o servidor xinetd. Mas antes de iniciar o servidor xinetd, verificar quais portas TCP estão abertas. Para isso, é necessário a aplicação nmap para fazer um scan de portas. Se esta aplicação não estiver instalada, será necessário instalar.

Num Ubuntu ou Debian, o comando para instalar nmap é:

NOTA: num CentOS ou Red Hat, o comando acima seria "yum install nmap".

Agora, é só fazer o scan de portas:


root# apt-get install nmap

root# nmap localhost

Starting Nmap 5.21 ( http://nmap.org ) at 2017-07-22 16:06 BRTNmap scan report for localhost (127.0.0.1)Not shown: 999 closed portsPORT STATE SERVICE631/tcp open ipp

Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds

root# man xinetd.conf

root# man xinetd.conf | grep -A 9 "service telnet"

root# man xinetd.conf | grep -A 9 "service telnet" > /etc/xinetd.d/telnet


NOTA: o nmap mostrou que apenas a porta 631 [servidor de impressão] está aberta.

Depois de verificado quais portas estão abertas, (re)iniciar o serviço xinetd. É interessante notar que o serviço TELNET foi configurado para funcionar sob o xinetd, portanto sem a sua própria inicialização.

Para verificar se o serviço xinetd está rodando, procurar pelo processo daemon:

No exemplo acima, o processo do serviço xinetd está rodando. Para padronizar a inicialização, este deve ser parado agora.

Num sistema SystemV, usar o script de inicialização no /etc/init.d:

NOTA: num sistema SystemD, o comando acima seria "systemctl stop xinetd".

Agora pode ser notado que o processo daemon xinetd não está mais rodando:

Por fim, iniciar o servidor xinetd. Num sistema SystemV, o comando é:

NOTA: num sistema SystemD, o comando acima seria "systemctl start xinetd".

Porém, o comando acima só mostrou que o serviço xinetd iniciou, mas como saber se foi habilitado telnet? Num Ubuntu ou Debian, para saber o número de serviços habilitados pelo xinetd na inicialização, consultar os logs do sistema:


root# ps -ef | grep xinetd

root# /etc/init.d/xinetd startIniciando o xinetd: [ OK ]

root# ps -ef | grep xinetdroot 3234 1 0 15:05 ? 00:00:00 /usr/sbin/xinetd

root# /etc/init.d/xinetd stopParando o xinetd: [ OK ]


NOTA 1: a saída acima indica 1 serviço disponível debaixo do xinetd, que no caso é o serviço telnet.

NOTA 2: Num CentOS ou Red Hat, usar o comando "grep xinetd /var/log/messages".

Depois disso, o scan de portas vai mostrar que a porta 23 também está aberta:

E o comando ps vai mostrar que o daemon xinetd está rodando:

3.3 - Cliente de serviço TELNET

Sabendo que foi disponibilizado serviço TELNET na máquina remota com endereço IP, por exemplo, 192.168.1.10, usar a aplicação cliente telnet para fazer o acesso a esse serviço:



Starting Nmap 5.21 ( http://nmap.org ) at 2017-07-22 16:10 BRTNmap scan report for localhost (127.0.0.1)Not shown: 998 closed portsPORT STATE SERVICE23/tcp open telnet631/tcp open ipp


root# ps -ef | grep xinetdroot 3314 1 0 15:41 ? 00:00:00 /usr/sbin/xinetd

root# grep xinetd /var/log/syslog...xinetd: Started working: 1 available service...


Uma vez conectado no acesso telnet, pode disparar comandos no servidor remoto.

O acesso telnet é usado para administrar sistemas remotos, tais como servidores, roteadores, switches e firewalls.

4 - SERVIÇO SSH

SSH vem de Secure SHell, ou shell seguro, e foi criado para resolver os problemas de segurança dos antigos protocolos TELNET e FTP que, embora funcionais, não implementam criptografia de dados.

Desse modo, quando se faz um acesso a um serviço FTP ou TELNET, tanto usuário e senha quanto dados enviados ou recebidos são transportados pela rede expostos como texto. E qualquer um que intercepte essa informação obtém diretamente a senha de acesso ao serviço, além dos dados que estão trafegando pela rede.

Existe pelo menos quatro vantagens em usar SSH ao invés de TELNET e FTP:

• i) o SSH usa uma única porta, que é a 22, tanto para acesso shell remoto quanto transferir arquivos;

• ii) o SSH implementa criptografia de dados;

• iii) o SSH tem pelo menos três aplicações clientes: ssh, sftp e scp;

• iv) com SSH é possível criar relação de confiança com par de chave pública e privada.


shell$ telnet 192.168.1.10Trying 192.168.1.10...Connected to 192.168.1.10.Escape character is '^]'.Ubuntu 12.04.5 LTSLab10 login: alunoPassword: Last login: Sun Sep 13 11:36:57 from 192.168.1.13[[email protected]]$ hostnameLab-10[[email protected]]$ exit


O serviço SSH usa criptografiaassimétrica, com par de chave pública eprivada. Nesse acesso [por exemplo], osdados são criptografados no servidorusando a chave pública do cliente[previamente recebida pelo servidor], eentão decriptografados no cliente com achave privada do cliente.

O uso de protocolos seguros nãoimpede que os pacotes de dados sejaminterceptados, porém só quem consegueextrair a informação é o detentor da chaveprivada.

O estabelecimento de uma conexão segura inicia com o envio da chave pública, tanto por parte do cliente quanto do servidor. As chaves privadas são mantidas protegidas.

4.1 - Instalação do serviço OpenSSH

A implementação mais comum de serviço SSH é o OpenSSH.

Num sistema SystemV, para descobrir se o serviço sshd está instalado, uma dica simples é procurar pelo seu script de inicialização em /etc/init.d. Numa distribuição Debian ou Ubuntu, o comando é:

NOTA 1: num Red Hat ou CentOS, o arquivo é "/etc/init.d/sshd".

NOTA 2: num sistema SystemD, o arquivo equivalente é sshd.service e está em /usr/lib/systemd/system.

Se não houvesse saída no comando acima, seria indicativo de que o serviço SSH não está instalado. Neste caso, num Debian ou Ubuntu, poderia ser instalado com o comando apt-get:

NOTA: num Red Hat ou CentOS, o comando seria "yum install openssh-server".


root# ls /etc/init.d | grep ssh/etc/init.d/ssh

root# apt-get install openssh-server

Criptografia assimétrica (par de chave pública e privada).


Neste caso, o serviço SSH foi instalado como standalone [que é o padrão] e não inetd. Após instalado num SystemV, verificar se existem os seguintes arquivos:

NOTA 1: os arquivos acima são relativos a um Ubuntu 12.

NOTA 2: Num Red Hat ou CentOS SystemV, o script é /etc/init.d/sshd.

Na saída dos comando acima, temos:

• /etc/init.d/ssh: é o script de inicialização do serviço ssh (CentOS: /etc/init.d/sshd). Num SystemD o equivalente é o arquivo de unit, que num Ubuntu é /lib/systemd/system/ssh.service e num CentOS é /usr/lib/systemd/system/sshd.service;

• /usr/sbin/sshd: é o executável do serviço, ao rodar dá origem ao processo daemon;

• /etc/ssh/sshd_config: é o arquivo de configuração do serviço ssh.

Para verificar se existe um processo de nome sshd, comandar:

Havendo saída no comando acima, isso indica que o processo está rodando. Para parar o serviço num sistema SystemV, comandar:

NOTA 1: num CentOS ou Red Hat, o script é sshd e não ssh.

NOTA 2: num sistema SystemD, o comando equivalente é "systemctl stop sshd".


root# file /etc/init.d/ssh/etc/init.d/sshd: Bourne shell script text executableroot# file /usr/sbin/sshd/usr/sbin/sshd: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, strippedroot# file /etc/ssh/sshd_config/etc/ssh/sshd_config: ASCII English text

root# ps -ef | grep sshdroot 3234 1 0 15:05 ? 00:00:00 /usr/sbin/sshd

root# /etc/init.d/ssh stopParando o ssh: [ OK ]


Nesta situação, o scan de portas com nmap não deve mostrar a porta 22 aberta.

Agora, então, iniciar o serviço ssh. Num sistema SystemV, o comando é:

NOTA 1: este comando foi executado num Ubuntu. Num CentOS, o nome do script é sshd;

NOTA 2: num sistema SystemD, o comando equivalente é "systemctl start sshd".

Depois disso, o scan de portas vai mostrar que a porta 22 está aberta:

E o comando ps vai mostrar que o daemon sshd está rodando:

4.2 - Clientes do serviço SSH

Antes de acessar o serviço com as aplicações clientes, verificar se o TCP-Wrappers está bloqueando o acesso em /etc/hosts.deny. Se sim, incluir uma linha em /etc/hosts.allow para permitir o acesso ao serviço ssh:


root# /etc/init.d/ssh startIniciando o ssh: [ OK ]


Starting Nmap 5.21 ( http://nmap.org ) at 2017-07-22 16:22 BRTNmap scan report for localhost (127.0.0.1)Not shown: 998 closed portsPORT STATE SERVICE22/tcp open ssh631/tcp open ipp


root# ps -ef | grep sshdroot 1327 1 0 19:22 ? 00:00:00 /usr/sbin/sshd


=== /etc/hosts.allow ==========sshd: 192.168.1.0/255.255.255.0=========================

NOTA: a configuração acima libera o acesso a todos os clientes na rede 192.168.1.0/24.

4.2.1 - Cliente ssh

A aplicação cliente ssh é semelhante ao cliente telnet, mas com a segurança da criptografia.

Sabendo que foi disponibilizado serviço SSH na máquina remota com endereço IP 192.168.1.10, usar a aplicação cliente ssh para fazer o acesso a este serviço:

NOTA: no primeiro acesso ao serviço SSH é oferecido o fingerprint da chave pública do servidor, e para continuar o acesso o usuário precisa concordar escrevendo "yes". Com isso, a chave pública do servidor é escrita no arquivo /home/aluno/.ssh/known_hosts, de modo que a partir do segundo acesso não será mais feita esta pergunta. O fingerprint é uma pequena sequência de bytes, usada para identificar uma chave pública.

Uma vez conectado no acesso ssh, pode disparar comandos no servidor remoto.

O acesso ssh também é usado para administrar hosts remotos e equipamentos de rede como roteadores, switches e firewalls.

Para desconectar do serviço ssh, comandar exit:

Uma alternativa à notação "ssh [email protected]" é usar a opção -l, de login name:


shell$ ssh [email protected] authenticity of host 'localhost (192.168.1.10)' can't be established.RSA key fingerprint is 66:39:9d:7a:8f:4c:af:1b:40:c4:a7:35:42:15:3b:d6.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added 'localhost' (RSA) to the list of known [email protected]'s password: Last login: Sat Jul 22 11:37:30 2017 from 192.168.1.13[[email protected]]$

shell$ ssh [email protected][[email protected]]$ exitshell$


Uma outra maneira de usar a aplicação cliente ssh, é para disparar diretamente comandos remotos, sem a necessidade de fazer o acesso remoto shell. Por exemplo:

NOTA: a máquina local com IP 192.168.1.11 tem hostname lab-11, e o servidor remoto é lab-10.

4.2.2 - Cliente scp

A aplicação cliente scp [secure copy] serve para transferir arquivos usando o protocolo SSH.

Por exemplo, para transferir o arquivo /etc/passwd do host remoto 192.168.1.10 para o diretório /tmp local [download], comandar:

Para enviar o arquivo local /etc/group para o diretório /var/tmp do servidor remoto [upload], comandar:

NOTA: a sintaxe do scp é semelhante à do comando cp.


shell$ ssh -l aluno 192.168.1.10

shell$ scp [email protected]:/etc/passwd /[email protected]'s password: passwd 100% 2023 2.0KB/s 00:00shell$

shell$ scp /etc/group [email protected]:/var/[email protected]'s password: group 100% 875 0.9KB/s 00:00shell$

shell$ ssh [email protected] 'hostname'[email protected]'s password:lab-10shell$ hostnamelab-11


Outra vantagem do cliente scp é possibilitar transferir diretórios com todo o conteúdo, usando a opção "-r" (recursivo):

NOTA 1: neste exemplo, todo o diretório local /bin (e seu conteúdo) foi transferido para o /tmp da máquina em 192.168.1.10.

NOTA 2: o ftp não transfere diretórios.

4.2.3 - Cliente sftp

A aplicação cliente sftp tem esse nome de secure ftp, pois transfere arquivos usando criptografia de dados.

A funcionalidade do sftp é similar a do cliente ftp, incluindo a interatividade, o que significa dizer que todos os comandos ftp funcionam do mesmo jeito no sftp.

Por exemplo, para acessar o host no IP 192.168.1.10, comandar:


shell$ sftp [email protected]@192.168.1.10's password:sftp> ?Available commands:cd path Change remote directory to 'path'lcd path Change local directory to 'path'chgrp grp path Change group of file 'path' to 'grp'chmod mode path Change permissions of file 'path' to 'mode'chown own path Change owner of file 'path' to 'own'df [path] Display statistics for current directory or filesystem containing 'path'help Display this help textget remote-path [local-path] Download filells [ls-options [path]] Display local directory listingln oldpath newpath Symlink remote filelmkdir path Create local directorylpwd Print local working directoryls [path] Display remote directory listinglumask umask Set local umask to 'umask'mkdir path Create remote directoryprogress Toggle display of progress meter...sftp>

shell$ scp -r /bin [email protected]:/tmp


Mas o sftp não fica só na imitação do ftp, ele também tem a sua própria sintaxe, que é bastante eficiente para transferir arquivos.

No exemplo abaixo, temos alguns destes comandos próprios do cliente sftp:

NOTA 1: o comando get é para baixar arquivos, e put para enviar. Não é necessário usar mget ou mput.

NOTA 2: algumas versões do cliente sftp suportam o modo recursivo "-r" para transferir diretórios, enquanto outras não.

4.3 - Relação de confiança SSH

Com ssh, é possível (e recomendado) criar relação de confiança entre o cliente e o servidor, desse modo dispensando o uso de senhas. Isto é seguro, recomendado e muito importante no caso de transferência agendada de arquivos, pelo uso de scripts. Neste caso, não existe a necessidade de escrever a senha em algum lugar.

A relação de confiança é obtida a partir da criação de um par de chaves, com o comando ssh-keygen:


shell$ sftp [email protected]@192.168.1.10's password:sftp> get /bin/c* /tmpsftp> put /tmp/c* /var/tmpsftp> get -r /bin /tmpsftp> exit

shell$ ssh-keygen -b 1024 -t rsaGenerating public/private rsa key pair.Enter passphrase (empty for no passphrase):Enter same passphrase again:Your identification has been saved in /home/aluno/.ssh/id_rsa.Your public key has been saved in /home/aluno/.ssh/id_rsa.pub.The key fingerprint is:d8:b8:de:5b:2c:2d:1d:ed:c8:ea:a1:10:a0:63:c4:63 aluno@lab-11The key's randomart image is:+--[RSA 1024]---+| ||. || E. |...


NOTA 1: no comando acima, a opção "-b" especifica o número de bits na chave e "-t" o tipo da chave, no caso algoritmo rsa. Não foi usado passphrase para esta chave, portanto elanão foi criptografada, mas isso não é inseguro pois esta chave será transportada pela rede usando scp, que é seguro;

NOTA 2: como não foi especificado o local onde seria criado o par de chaves, estas foram criadas no subdiretório .ssh na home do usuário, na máquina lab-11 (192.168.1.11).

Para ver o par de chaves, comandar:

NOTA: as chaves do par são indissociáveis, se perder uma precisa recriar as duas de novo.

O passo seguinte é enviar a chave pública id_rsa.pub para o servidor ssh remoto, no caso 192.168.1.10. Lá, esta chave deverá ser renomeada para authorized_keys, no caminho absoluto /home/aluno/.ssh/authorized_keys.

Para este envio ser seguro, deve ser usado o serviço ssh:

NOTA: caso já existisse um arquivo /home/aluno/.ssh/authorized_keys em 192.168.1.10, para não perder a(s) chave(s) que houvesse(m) lá, o conteúdo do arquivo id_rsa.pub deveria ser acrescentado no final de authorized_keys.

No servidor ssh, as permissões de authorized_keys devem ser, no mínimo, 600. Para garantirisso, comandar:

Depois disso, já deverá funcionar o acesso sem a necessidade de usar senha:


shell$ ls -l /home/aluno/.ssh/id_rsa*-rw------- 1 aluno aluno 891 Fev 11 17:20 /home/aluno/.ssh/id_rsa-rw-r--r-- 1 aluno aluno 227 Fev 11 17:20 /home/aluno/.ssh/id_rsa.pub

shell$ cd /home/aluno/.sshshell$ scp id_rsa.pub [email protected]:/home/aluno/.ssh/authorized_keys

shell$ ssh [email protected] 'chmod 600 /home/aluno/.ssh/authorized_keys'[email protected]'s password:


Um exemplo bem simples de script para agendar copia de arquivos de 192.168.1.11 (o cliente) para 192.168.1.10 (o servidor SSH remoto), é:

=== copy.sh ==================#!/bin/bashfile=$1scp $file [email protected]:/tmp===========================

Dar permissão de execução para o script copy.sh:

Depois, disparar este script para copiar para o /tmp do servidor o arquivo passado como primeiro argumento:

4.4 - Impedir o root de logar diretamente no serviço

Uma configuração importante no serviço SSH é impedir o acesso direto do usuário root, poisisso caracteriza um acesso genérico com privilégios. O modo correto [e recomendado] é o administrador logar com o seu usuário e depois comandar su ou sudo para ganhar privilégios de root, e com isso registrar em logs do sistema quem é a pessoa que está executando estes comandos.

Para impedir o acesso direto do usuário root no serviço SSH basta que haja a seguinte linha de configuração no arquivo /etc/ssh/sshd_config:


shell$ ssh [email protected][[email protected]]$[[email protected]]$ exitshell$

shell$ /home/aluno/copy.sh /etc/passwdpasswd 100% 2746 2.7KB/s 00:00shell$

shell$ chmod 755 /home/aluno/copy.sh


=== /etc/ssh/sshd_config =========PermitRootLogin no============================

Depois de feita esta configuração, precisa reiniciar (ou fazer um reload) do serviço SSH.


serviços de transferência de arquivos e de acesso remoto · 1 - serviÇo ftp ftp, file transfer...

Documents