Comando slogin do Linux
Em sistemas operacionais do tipo Unix, o comando slogin é um alias para o cliente ssh , usado para conectar-se com segurança a um shell remoto .
Descrição
O ssh (o cliente SSH) é um programa para efetuar login em uma máquina remota e executar comandos. Ele pretende substituir o rlogin e o rsh e fornecer comunicações criptografadas seguras entre dois hosts não confiáveis em uma rede insegura. Conexões X11 e portas TCP arbitrárias também podem ser encaminhadas pelo canal seguro.
O ssh se conecta e faz login no nome do host especificado (com nome de usuário opcional ). O usuário deve provar sua identidade à máquina remota usando um dos vários métodos, dependendo da versão do protocolo usada (veja abaixo).
Se o comando for especificado, ele será executado no host remoto em vez de no shell de logon.
Esta documentação particular, refere-se pesadamente no OpenSSH implementação de SSH. Outras implementações estão disponíveis; se você tiver uma dessas versões instaladas, consulte seu manual para obter opções exclusivas e detalhes de funções.
Sintaxe
ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b endereço de ligação ] [-c cipher_spec ]
[-D [ endereço_address :] porta ] [-e escape_char ] [-F arquivo de configuração ]
[-I pkcs11 ] [-i identity_file ] [-L [ bind_address :] porta : host : hostport ]
[-l nome_do_usuário ] [-m mac_spec ] [-O ctl_cmd ] [-o opção ] [-p porta ]
[-R [ endereço_industrial :] porta : host : hostport ] [-S ctl_path ] [-W host : porta ]
[-w local_tun [: remote_tun ]] [ user @] hostname [ command ]Opções
| -1 | Força o ssh a tentar apenas a versão 1 do protocolo . |
| -2 | Força o ssh a tentar apenas a versão 2 do protocolo. |
| -4 | Força o ssh a usar apenas endereços IPv4 . |
| -6 | Força o ssh a usar apenas endereços IPv6 . |
| -UMA | Permite o encaminhamento da conexão do agente de autenticação . Isso também pode ser especificado por host em um arquivo de configuração . O encaminhamento de agente deve ser ativado com cuidado. Os usuários com a capacidade de ignorar as permissões de arquivo no host remoto (para o soquete do domínio Unix do agente ) podem acessar o agente local por meio da conexão encaminhada. Um invasor não pode obter o material da chave do agente; no entanto, ele pode executar operações nas chaves que permitem a autenticação usando as identidades carregadas no agente. |
| -uma | Desativa o encaminhamento da conexão do agente de autenticação. |
| -b bind_address | Use bind_address na máquina local como o endereço de origem da conexão. Útil apenas em sistemas com mais de um endereço. |
| -C | Solicita a compactação de todos os dados (incluindo stdin , stdout, stderr e dados para conexões X11 e TCP / IP encaminhadas ). O algoritmo de compactação é o mesmo usado pelo gzip , e o “nível” pode ser controlado pela opção CompressionLevel para a versão do protocolo 1. A compactação é desejável em linhas de modem e outras conexões lentas, mas só atrasa as coisas em redes rápidas. O valor padrão pode ser definido host a host nos arquivos de configuração; consulte a opção Compactação. |
| -c cipher_spec | Seleciona a cifra a ser usada para criptografar a sessão. Os valores suportados são 3des , blowfish e des . 3des é usado por padrão. No momento da redação deste documento, é uma cifra relativamente segura. 3des (triple-des) é um triplo de criptografia-decriptografia-criptografia com três chaves diferentes. blowfish é uma cifra de bloco rápida; parece muito seguro e é muito mais rápido que o 3des. O des é suportado apenas no cliente ssh para interoperabilidade com implementações do protocolo herdado 1 que não suportam a cifra 3des . Seu uso é fortemente desencorajado devido à criptografia fraquezas. |
| -D porta [bind_address:] | Especifica um encaminhamento de porta “dinâmico” local no nível do aplicativo . Isso funciona alocando um soquete para escutar a porta no lado local, opcionalmente vinculada ao endereço bind_ad especificado . Sempre que uma conexão é feita a essa porta, a conexão é encaminhada pelo canal seguro e o protocolo do aplicativo é usado para determinar para onde se conectar a partir da máquina remota. Atualmente, os protocolos SOCKS4 e SOCKS5 são suportados, e o ssh atuará como um servidor SOCKS . Somente o root pode encaminhar portas privilegiadas. O encaminhamento de porta dinâmico também pode ser especificado no arquivo de configuração. Os endereços IPv6 podem ser especificados colocando o endereço entre colchetes. Somente o superusuário (raiz) pode encaminhar portas privilegiadas. Por padrão, a porta local é vinculada de acordo com a configuração GatewayPorts . No entanto, um bind_address explícito pode ser usado para vincular a conexão a um endereço específico. O endereço de ligação de ” localhost ” indica que a porta de atendimento deve ser ligada apenas para uso local, enquanto um endereço vazio ou ‘ * ‘ indica que a porta deve estar disponível em todas as interfaces. |
| -e escape_char | Define o caractere de escape para sessões com um pty (padrão: ‘ ~ ‘). O caractere de escape é reconhecido apenas no início de uma linha. O caractere de escape seguido por um ponto (‘ . ‘) Fecha a conexão; seguido pelo controle-Z suspende a conexão; e seguido por si só envia o caractere de escape uma vez. Definir o caractere como ” none ” desativa os escapes e torna a sessão totalmente transparente. |
| -F configfile | Especifica um arquivo de configuração alternativo por usuário. Se um arquivo de configuração for fornecido na linha de comando, o arquivo de configuração em todo o sistema ( / etc / ssh / ssh_config ) será ignorado. O padrão para o arquivo de configuração por usuário é $ HOME / .ssh / config . |
| -f | Requests ssh to go to background just before command execution. This is useful if ssh is going to ask for passwords or passphrases, but the user wants it in the background. This implies -n. The recommended way to start X11 programs at a remote site is with something like ssh -f host xterm. |
| -g | Allows remote hosts to connect to local forwarded ports. |
| -I smartcard_device | Specifies which smartcard device to use. The argument is the device ssh should use to communicate with a smartcard used for storing the user’s private RSA key. |
| -i identity_file | Seleciona um arquivo do qual a identidade (chave privada) para autenticação de chave pública é lida. O padrão é ~ / .ssh / identity para a versão 1 do protocolo e ~ / .ssh / id_dsa , ~ / .ssh / id_ecdsa e ~ / .ssh / id_rsa para a versão 2. do protocolo. Arquivos de identidade também podem ser especificados em um arquivo per- host no arquivo de configuração. É possível ter várias opções -i (e várias identidades especificadas nos arquivos de configuração). O ssh também tentará carregar as informações do certificado a partir do nome do arquivo obtido anexando -cert.pub aos nomes dos arquivos de identidade. |
| -K | Permite autenticação e encaminhamento (delegação) baseados em GSSAPI de credenciais GSSAPI para o servidor. |
| -k | Desativa o encaminhamento (delegação) de credenciais GSSAPI para o servidor. |
| -L [bind_address:] port: host: hostport | Especifica que a porta especificada no host local (cliente) deve ser encaminhada para o host especificado e a porta no lado remoto. Isso funciona alocando um soquete para escutar a porta no lado local, opcionalmente ligada ao endereço bind_ad especificado . Sempre que uma conexão é feita a essa porta, a conexão é encaminhada pelo canal seguro e uma conexão é feita para hospedar o hostport da porta da máquina remota. Os encaminhamentos de porta também podem ser especificados no arquivo de configuração. Os endereços IPv6 podem ser especificados colocando o endereço entre colchetes. Somente o superusuário pode encaminhar portas privilegiadas. Por padrão, a porta local é vinculada de acordo com a configuração GatewayPorts . No entanto, um bind_address explícitopode ser usado para ligar a conexão a um endereço específico. O endereço de ligação de ” localhost ” indica que a porta de atendimento deve ser ligada apenas para uso local, enquanto um endereço vazio ou ‘ * ‘ indica que a porta deve estar disponível em todas as interfaces. |
| -l login_name | Especifica o usuário para efetuar login como na máquina remota. Isso também pode ser especificado por host no arquivo de configuração. |
| -M | Coloca o cliente ssh no modo “mestre” para compartilhamento de conexão. Várias opções -M colocam o ssh no modo “mestre”, com a confirmação necessária antes que as conexões escravas sejam aceitas. Consulte a descrição do ControlMaster em ssh_config para obter detalhes. |
| -m mac_spec | Para a versão 2 do protocolo, uma lista separada por vírgula de algoritmos MAC (código de autenticação de mensagens) pode ser especificada em ordem de preferência. |
| -N | Não execute um comando remoto. Isso é útil apenas para encaminhamento de portas (somente protocolo versão 2). |
| -n | Redireciona stdin de / dev / null (na verdade, impede a leitura de stdin ). Isso deve ser usado quando o ssh é executado em segundo plano. Um truque comum é usar isso para executar programas X11 em uma máquina remota. Por exemplo, ssh -n shadows.cs.hut.fi emacs & iniciará um emacs em shadows.cs.hut.fi , e a conexão X11 será encaminhada automaticamente por um canal criptografado. O programa ssh será colocado em segundo plano. Isso não funciona se o ssh precisar solicitar uma senha ou senha; veja também a opção -f |
| -O ctl_cmd | Controlar um processo mestre de multiplexação de conexão ativa . Quando a opção -O é especificada, o argumento ctl_cmd é interpretado e passado para o processo mestre. Os comandos válidos são: ” cheque ” (verifique se o processo mestre está em execução), ” encaminhamento ” (solicitação de encaminhamento sem execução de comando), ” cancelamento ” (cancelamento de encaminhamento), ” exit ” (solicitação de saída do mestre) e ” parada “(solicite ao mestre que pare de aceitar outros pedidos de multiplexação). |
| -o opção | Pode ser usado para fornecer opções no formato usado no arquivo de configuração. Isso é útil para especificar opções para as quais não há sinalizador de linha de comando separado. Para detalhes completos das opções listadas abaixo e seus possíveis valores, consulte ssh_config . AddressFamily BATCHMODE BindAddress ChallengeResponseAuthentication CheckHostIP Cipher Ciphers ClearAllForwardings Compression CompressionLevel ConnectionAttempts ConnectTimeout ControlMaster ControlPath ControlPersist DynamicForward EscapeChar ExitOnForwardFailure ForwardAgent ForwardX11 ForwardX11Timeout ForwardX11Trusted GatewayPorts GlobalKnownHostsFile GSSAPIAuthentication GSSAPIDelegateCredentials HashKnownHosts Anfitrião HostbasedAuthentication HostKeyAlgorithms HostKeyAlias HostName IdentityFile IdentitiesOnly IPQoS KbdInteractiveAuthentication KbdInteractiveDevices KexAlgorithms LocalCommand LocalForward LogLevel MACs NoHostAuthenticationForLocalhost NumberOfPasswordPrompts PasswordAuthentication PermitLocalCommand PKCS11Provider Porto PreferredAuthentications Protocolo ProxyCommand PubkeyAuthentication RekeyLimit RemoteForward RequestTTY RhostsRSAAuthentication RSAAuthentication SendEnv ServerAliveInterval ServerAliveCountMax StrictHostKeyChecking TcpKeepAlive Tunnel TunnelDevice UsePrivilegedPort usuário UserKnownHostsFile VerifyHostKeyDNS VisualHostKey XAuthLocation |
| porta -p | Porta à qual se conectar no host remoto. Isso pode ser especificado por host no arquivo de configuração. |
| -q | Quiet mode. Causes all warning and diagnostic messages to be suppressed. Only fatal errors are displayed. If a second -q is given then even fatal errors are suppressed. |
| -R [bind_address:] port:host:hostport | Specifies that the given port on the remote (server) host is to be forwarded to the given host and port on the local side. This works by allocating a socket to listen to the port on the remote side, and whenever a connection is made to this port, the connection is forwarded over the secure channel, and a connection is made to host port hostport from the local machine. Port forwardings can also be specified in the configuration file. Privileged ports can be forwarded only when logging in as root on the remote machine. IPv6 addresses can be specified by enclosing the address in square brackets. By default, the listening socket on the server will be bound to the loopback interface only. This may be overridden by specifying a bind_address. An empty bind_address, or the address ‘*’, indicates that the remote socket should listen on all interfaces. Specifying a remote bind_address will only succeed if the server’s GatewayPorts option is enabled; see sshd_config. If the port argument is ‘0’, the listen port will be dynamically allocated on the server and reported to the client at run time. When used together with -O forward the allocated port will be printed to the standard output. |
| -S ctl_path | Specifies the location of a control socket for connection sharing, or the string “none” to disable connection sharing. Refer to the description of ControlPath and ControlMaster in ssh_config for details. |
| -s | May be used to request invocation of a subsystem on the remote system. Subsystems are a feature of the SSH2 protocol which facilitate the use of SSH as a secure transport for other applications (eg. sftp). The subsystem is specified as the remote command. |
| -T | Disable pseudo-tty allocation. |
| -t | Force pseudo-tty allocation. This can be used to execute arbitrary screen-based programs on a remote machine, which can be very useful, e.g., when implementing menu services. Multiple -t options force tty allocation, even if ssh has no local tty. |
| -V | Display the version number and exit. |
| -v | Verbose mode. Causes ssh to print debugging messages about its progress. This is helpful in debugging connection, authentication, and configuration problems. Multiple -v options increase the verbosity. The maximum is 3. |
| -W host:port | Requests that standard input and output on the client be forwarded to host on port over the secure channel. Implies -N, -T, ExitOnForwardFailure and ClearAllForwardings. Works with Protocol version 2 only. |
| -w local_tun[:remote_tun] | Requests tunnel device forwarding with the specified tun devices between the client (local_tun) and the server (remote_tun). The devices may be specified by numerical ID or the keyword “any“, which uses the next available tunnel device. If remote_tun is not specified, it defaults to “any“. See also the Tunnel and TunnelDevice directives in ssh_config. If the Tunnel directive is unset, it is set to the default tunnel mode, which is “point-to-point“. |
| -X | Enables X11 forwarding. This can also be specified on a per-host basis in a configuration file. X11 forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the user’s X authorization database) can access the local X11 display through the forwarded connection. An attacker may then be able to perform activities such as keystroke monitoring. For this reason, X11 forwarding is subjected to X11 SECURITY extension restrictions by default. Please refer to the ssh -Y option and the ForwardX11Trusted directive in ssh_config for more information. |
| -x | Disables X11 forwarding. |
| -Y | Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls. |
| -y | Send log information using the syslog system module. By default, this information is sent to stderr. |
Authentication
The OpenSSH SSH client supports SSH protocols 1 and 2. The default is to use protocol 2 only, though this can be changed via the Protocol option in ssh_config or the -1 and -2 options (see above). Both protocols support similar authentication methods, but protocol 2 is the default since it provides additional mechanisms for confidentiality (the traffic is encrypted using AES, 3DES, Blowfish, CAST128, or Arcfour) and integrity (hmac-md5, hmac-sha1, hmac-sha2-256, hmac-sha2-512, umac-64, hmac-ripemd160). Protocol 1 lacks a strong mechanism for ensuring the integrity of the connection.
The methods available for authentication are: GSSAPI-based, host-based, public key, challenge-response, and password. Authentication methods are tried in the order specified above, though protocol 2 has a configuration option to change the default order: PreferredAuthentications.
Host-based authentication works as follows: If the machine the user logs in from is listed in /etc/hosts.equiv or /etc/ssh/shosts.equiv on the remote machine, and the user names are the same on both sides, or if the files ~/.rhosts or ~/.shosts exist in the user’s home directory on the remote machine and contain a line containing the name of the client machine and the name of the user on that machine, the user is considered for login. Additionally, the server must be able to verify the client’s host key (see the description of /etc/ssh/ssh_known_hosts and ~/.ssh/known_hosts, below) for login to be permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing, and routing spoofing. Note to the administrator: /etc/hosts.equiv, ~/.rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.
Public key authentication works as follows: The scheme is based on public-key cryptography, using cryptosystems where encryption and decryption are done using separate keys, and it is unfeasible to derive the decryption key from the encryption key. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key. ssh implements public key authentication protocol automatically, using one of the DSA, ECDSA or RSA algorithms. Protocol 1 is restricted to using only RSA keys, but protocol 2 may use any.
The file ~/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use checks that the corresponding public key is authorized to accept the account.
The user creates his/her key pair by running ssh-keygen. This stores the private key in ~/.ssh/identity (protocol 1), ~/.ssh/id_dsa (protocol 2 DSA), ~/.ssh/id_ecdsa (protocol 2 ECDSA), or ~/.ssh/id_rsa (protocol 2 RSA) and stores the public key in ~/.ssh/identity.pub (protocol 1), ~/.ssh/id_dsa.pub (protocol 2 DSA), ~/.ssh/id_ecdsa.pub (protocol 2 ECDSA), or ~/.ssh/id_rsa.pub (protocol 2 RSA) in the user’s home directory. The user should then copy the public key to ~/.ssh/authorized_keys in his/her home directory on the remote machine. The authorized_keys file corresponds to the conventional ~/.rhosts file, and has one key per line, though the lines can be very long. After this, the user can log in without giving the password.
A variation on public key authentication is available in the form of certificate authentication: instead of a set of public/private keys, signed certificates are used. This has the advantage that a single trusted certification authority can be used in place of many public/private keys. See the CERTIFICATES section of ssh-keygen for more information.
The most convenient way to use public key or certificate authentication may be with an authentication agent. See ssh-agent for more information.
Challenge-response authentication works as follows: The server sends an arbitrary “challenge” text, and prompts for a response. Protocol 2 allows multiple challenges and responses; protocol 1 is restricted to just one challenge/response. Examples of challenge-response authentication include BSD Authentication (see login.conf) and PAM (some non-OpenBSD systems).
Finally, if other authentication methods fail, ssh prompts the user for a password. The password is sent to the remote host for checking; however, since all communications are encrypted, the password cannot be seen by someone listening on the network.
ssh automatically maintains and checks a database containing identification for all hosts it has ever been used with. Host keys are stored in ~/.ssh/known_hosts in the user’s home directory. Additionally, the file /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any new hosts are automatically added to the user’s file. If a host’s identification ever changes, ssh warns about this and disables password authentication to prevent server spoofing or man-in-the-middle attacks, which could otherwise be used to circumvent the encryption. The StrictHostKeyChecking option can be used to control logins to machines whose host key is not known or has changed.
When the user’s identity has been accepted by the server, the server either executes the given command, or logs into the machine and gives the user a normal shell on the remote machine. All communication with the remote command or shell will be automatically encrypted.
If a pseudo-terminal has been allocated (normal login session), the user may use the escape characters noted below.
If no pseudo-tty has been allocated, the session is transparent and can be used to reliably transfer binary data. On most systems, setting the escape character to “none” will also make the session transparent even if a tty is used.
The session terminates when the command or shell on the remote machine exits and all X11 and TCP connections have been closed.
Escape Characters
When a pseudo-terminal has been requested, ssh supports a number of functions through the use of an escape character.
A single tilde character can be sent as ~~ or by following the tilde by a character other than those described below. The escape character must always follow a newline to be interpreted as special. The escape character can be changed in configuration files using the EscapeChar configuration directive or on the command line by the -e option.
The supported escapes (assuming the default ‘~’) are:
| ~. | Disconnect. |
| ~^Z | Background ssh. |
| ~# | List forwarded connections. |
| ~& | Background ssh at logout when waiting for forwarded connection / X11 sessions to terminate. |
| ~? | Display a list of escape characters. |
| ~B | Send a BREAK to the remote system (only useful for SSH protocol version 2 and if the peer supports it). |
| ~C | Open command line. Currently this allows the addition of port forwardings using the -L, -R and -D options (see above). It also allows the cancellation of existing port-forwardings with -KL[bind_address:]port for local, -KR[bind_address:]port for remote and -KD[bind_address:]port for dynamic port-forwardings. !command allows the user to execute a local command if the PermitLocalCommand option is enabled in ssh_config. Basic help is available, using the -h option. |
| ~R | Request rekeying of the connection (only useful for SSH protocol version 2 and if the peer supports it). |
TCP Forwarding
Forwarding of arbitrary TCP connections over the secure channel can be specified either on the command line or in a configuration file. One possible application of TCP forwarding is a secure connection to a mail server; another is going through firewalls.
In the example below, we look at encrypting communication between an IRC client and server, even though the IRC server does not directly support encrypted communications. This works as follows: the user connects to the remote host using ssh, specifying a port to be used to forward connections to the remote server. After that it is possible to start the service that is to be encrypted on the client machine, connecting to the same local port, and ssh will encrypt and forward the connection.
The following example tunnels an IRC session from client machine “127.0.0.1” (localhost) to remote server “server.example.com“:
ssh -f -L 1234:localhost:6667 server.example.com sleep 10
irc -c '#users' -p 1234 pinky 127.0.0.1
This tunnels a connection to IRC server “server.example.com“, joining channel “#users“, nickname “pinky“, using port 1234. It doesn’t matter which port is used, as long as it’s greater than 1023 (remember, only root can open sockets on privileged ports) and doesn’t conflict with any ports already in use. The connection is forwarded to port 6667 on the remote server, since that’s the standard port for IRC services.
The -f option backgrounds ssh and the remote command “sleep 10” is specified to allow an amount of time (10 seconds, in the example) to start the service that is to be tunnelled. If no connections are made within the time specified, ssh will exit.
X11 Forwarding
If the ForwardX11 variable is set to “yes” (or see the description of the -X, -x, and -Y options above) and the user is using X11 (the DISPLAY environment variable is set), the connection to the X11 display is automatically forwarded to the remote side in such a way that any X11 programs started from the shell (or command) will go through the encrypted channel, and the connection to the real X server will be made from the local machine. The user should not manually set DISPLAY. Forwarding of X11 connections can be configured on the command line or in configuration files.
O valor DISPLAY exibido por ssh apontará para a máquina do servidor, mas com um número de exibição maior que zero. Isso é normal e acontece porque o ssh cria um servidor X “proxy” na máquina do servidor para encaminhar as conexões pelo canal criptografado.
O ssh também configurará automaticamente os dados do Xauthority na máquina do servidor. Para isso, ele gera um cookie de autorização aleatório , armazena-o no Xauthority no servidor e verifica se todas as conexões encaminhadas carregam esse cookie e o substituem pelo cookie real quando a conexão é aberta. O cookie de autenticação real nunca é enviado para a máquina do servidor (e nenhum cookie é enviado na planície).
Se a variável ForwardAgent estiver definida como ” yes ” (ou ver a descrição das opções -A e -a acima) e o usuário estiver usando um agente de autenticação, a conexão com o agente será encaminhada automaticamente para o lado remoto.
Verificando chaves do host
Ao conectar-se a um servidor pela primeira vez, uma impressão digital da chave pública do servidor é apresentada ao usuário (a menos que a opção StrictHostKeyChecking tenha sido desativada). As impressões digitais podem ser determinadas usando ssh-keygen :
ssh-keygen -l -f / etc / ssh / ssh_host_rsa_key
Se a impressão digital já é conhecida, ela pode ser correspondida e a chave pode ser aceita ou rejeitada. Devido à dificuldade de comparar chaves de host apenas olhando para cadeias hexadecimais , também há suporte para comparar visualmente chaves de host, usando arte aleatória. Ao definir a opção VisualHostKey como ” yes “, um pequeno ASCIIO gráfico é exibido em todos os logins de um servidor, independentemente de a sessão ser interativa ou não. Aprendendo o padrão que um servidor conhecido produz, um usuário pode descobrir facilmente que a chave do host mudou quando um padrão completamente diferente é exibido. Como esses padrões não são inequívocos, no entanto, um padrão semelhante ao padrão lembrado apenas fornece uma boa probabilidade de que a chave do host seja a mesma, não uma prova garantida.
Para obter uma lista das impressões digitais, juntamente com sua arte aleatória, para todos os hosts conhecidos, a seguinte linha de comando pode ser usada:
ssh-keygen -lv -f ~ / .ssh / known_hosts
Se a impressão digital for desconhecida, um método alternativo de verificação estará disponível: impressões digitais SSH verificadas pelo DNS . Um registro de recurso adicional (RR), SSHFP, é adicionado a um arquivo de zona e o cliente de conexão pode corresponder a impressão digital com a da chave apresentada.
Neste exemplo, estamos conectando um cliente a um servidor, ” host.example.com “. Os registros de recurso SSHFP devem primeiro ser adicionados ao arquivo de zona para host.example.com :
ssh-keygen -r host.example.com.
As linhas de saída deverão ser adicionadas ao arquivo de zona. Para verificar se a zona está respondendo a consultas de impressão digital:
dig -t SSHFP host.example.com
Finalmente, o cliente se conecta:
ssh -o "VerifyHostKeyDNS ask" host.example.com
e saídas:
[...] Impressão digital da chave do host correspondente encontrada no DNS. Tem certeza de que deseja continuar se conectando (sim / não)?
Consulte a opção VerifyHostKeyDNS em ssh_config para obter mais informações.
Redes privadas virtuais baseadas em SSH
O ssh contém suporte para encapsulamento de rede virtual privada ( VPN ) usando o pseudo-dispositivo da rede tun , permitindo que duas redes sejam unidas com segurança. A opção de configuração sshd_config PermitTunnel controla se o servidor suporta isso e em que nível (tráfego de camada 2 ou 3).
O exemplo a seguir conectaria a rede do cliente 10.0.50.0/24 à rede remota 10.0.99.0/24 usando uma conexão ponto a ponto de 10.1.1.1 a 10.1.1.2 , desde que o servidor SSH em execução no gateway da rede remota , em 192.168.1.15 , permite.
No cliente:
ssh -f -w 0: 1 192.168.1.15 true
ifconfig tun0 10.1.1.1 10.1.1.2 máscara de rede 255.255.255.252
route add 10.0.99.0/24 10.1.1.2
No servidor:
ifconfig tun1 10.1.1.2 10.1.1.1 máscara de rede 255.255.255.252
route add 10.0.50.0/24 10.1.1.1
O acesso do cliente pode ser ajustado com mais precisão por meio do arquivo /root/.ssh/authorized_keys (veja abaixo) e a opção do servidor PermitRootLogin . A entrada a seguir permitirá conexões no dispositivo tun 1 do usuário ” jane ” e no dispositivo tun 2 do usuário ” john “, se PermitRootLogin estiver definido como “somente comandos forçados”:
tunnel = "1", command = "sh / etc / netstart tun1" ssh-rsa ... jane
tunnel = "2", command = "sh / etc / netstart tun2" ssh-rsa ... john
Since an SSH-based setup entails a fair amount of overhead, it may be more suited to temporary setups, such as for wireless VPNs. More permanent VPNs are better provided by tools such as ipsecctl and isakmpd.
Environment
ssh will normally set the following environment variables:
| DISPLAY | A variável DISPLAY indica a localização do servidor X11. É definido automaticamente pelo ssh para apontar para um valor no formato ” hostname: n “, em que ” hostname ” indica o host em que o shell é executado e ‘ n ‘ é um número inteiro ≥ 1 . O ssh usa esse valor especial para encaminhar conexões X11 pelo canal seguro. O usuário normalmente não deve definir o DISPLAY explicitamente, pois isso tornará a conexão X11 insegura (e exigirá que o usuário copie manualmente todos os cookies de autorização necessários). |
| CASA | Defina como o caminho do diretório inicial do usuário. |
| LOGNAME | Sinônimo de USER ; definido para compatibilidade com sistemas que usam essa variável. |
| ENVIAR | Defina como o caminho da caixa de correio do usuário. |
| CAMINHO | Defina como PATH padrão , conforme especificado ao compilar ssh . |
| SSH_ASKPASS | Se o ssh precisar de uma senha, ela lerá a senha do terminal atual se tiver sido executada a partir de um terminal. Se o ssh não tiver um terminal associado, mas DISPLAY e SSH_ASKPASS estiverem configurados, ele executará o programa especificado por SSH_ASKPASS e abrirá uma janela X11 para ler a frase secreta. Isso é particularmente útil ao chamar ssh de uma sessão .xs ou script relacionado. Observe que em algumas máquinas pode ser necessário redirecionar a entrada de / dev / null para fazer isso funcionar. |
| SSH_AUTH_SOCK | Identifica o caminho de um soquete do domínio UNIX usado para se comunicar com o agente. |
| SSH_CONNECTION | Identifica as extremidades do cliente e do servidor da conexão. A variável contém quatro valores separados por espaço: endereço IP do cliente, número da porta do cliente, endereço IP do servidor e número da porta do servidor. |
| SSH_ORIGINAL_COMMAND | Essa variável contém a linha de comando original se um comando forçado for executado. Pode ser usado para extrair os argumentos originais. |
| SSH_TTY | É definido como o nome do tty (caminho para o dispositivo) associado ao shell ou comando atual. Se a sessão atual não tiver tty, essa variável não está definida. |
| TZ | Esta variável é configurada para indicar o fuso horário atual, se foi configurada quando o daemon foi iniciado (ou seja, o daemon passa o valor para novas conexões). |
| DO UTILIZADOR | Defina como o nome do usuário que está efetuando login. |
Além disso, o ssh lê ~ / .ssh / environment e adiciona linhas do formato ” VARNAME = value ” ao ambiente, se o arquivo existir e os usuários puderem alterar seu ambiente. Para obter mais informações, consulte a opção PermitUserEnvironment em sshd_config .
arquivos
| ~ / .rhosts | Este arquivo é usado para autenticação baseada em host (veja acima). Em algumas máquinas, esse arquivo pode precisar ser legível pelo mundo se o diretório inicial do usuário estiver em uma partição NFS , porque o sshd o lê como raiz. Além disso, esse arquivo deve pertencer ao usuário e não deve ter permissões de gravação para mais ninguém. A permissão recomendada para a maioria das máquinas é de leitura / gravação para o usuário e não é acessível por outras pessoas. |
| ~ / .shosts | Esse arquivo é usado exatamente da mesma maneira que .rhosts , mas permite autenticação baseada em host sem permitir o login com rlogin / rsh. |
| ~ / .ssh / | Este diretório é o local padrão para todas as informações de configuração e autenticação específicas do usuário. Não existe um requisito geral para manter todo o conteúdo deste diretório em segredo, mas as permissões recomendadas são de leitura / gravação / execução para o usuário e não podem ser acessadas por outros. |
| ~ / .ssh / chaves_autorizadas | Lista as chaves públicas (DSA / ECDSA / RSA) que podem ser usadas para efetuar login como este usuário. O formato deste arquivo é descrito na página de manual do sshd . Este arquivo não é altamente sensível, mas as permissões recomendadas são de leitura / gravação para o usuário e não podem ser acessadas por outros. |
| ~ / .ssh / config | Este é o arquivo de configuração por usuário. O formato do arquivo e as opções de configuração são descritas em ssh_config. Devido ao potencial abuso, esse arquivo deve ter permissões estritas: leitura / gravação para o usuário e não acessível por outros. Pode ser gravável em grupo, desde que o grupo em questão contenha apenas o usuário. |
| ~ / .ssh / ambiente | Contém definições adicionais para variáveis de ambiente; veja AMBIENTE, acima. |
| ~ / .ssh / identity ~ / .ssh / id_dsa ~ / .ssh / id_ecdsa ~ / .ssh / id_rsa | Contém a chave privada para autenticação. Esses arquivos contêm dados confidenciais e devem ser legíveis pelo usuário, mas não acessíveis por outros (leitura / gravação / execução). O ssh ignora um arquivo de chave privada, se estiver acessível por outras pessoas. É possível especificar uma senha ao gerar a chave que será usada para criptografar a parte sensível desse arquivo usando o 3DES . |
| ~ / .ssh / identity.pub ~ / .ssh / id_dsa.pub ~ / .ssh / id_ecdsa.pub ~ / .ssh / id_rsa.pub | Contém a chave pública para autenticação. Esses arquivos não são sensíveis e podem (mas não precisam) ser legíveis por qualquer pessoa. |
| ~ / .ssh / unknown_hosts | Contains a list of host keys for all hosts the user has logged into that are not already in the systemwide list of known host keys. See sshd for further details of the format of this file. |
| ~/.ssh/rc | Commands in this file are executed by ssh when the user logs in, just before the user’s shell (or command) is started. See the sshd manual page for more information. |
| /etc/hosts.equiv | This file is for host-based authentication (see above). It should only be writable by root. |
| /etc/ssh/shosts.equiv | This file is used in exactly the same way as hosts.equiv, but allows host-based authentication without permitting login with rlogin/rsh. |
| /etc/ssh/ssh_config | Systemwide configuration file. The file format and configuration options are described in ssh_config. |
| /etc/ssh/ssh_host_key /etc/ssh/ssh_host_dsa_key /etc/ssh/ssh_host_ecdsa_key /etc/ssh/ssh_host_rsa_key | These files contain the private parts of the host keys and are used for host-based authentication. If protocol version 1 is used, ssh must be setuid root, since the host key is readable only by root. For protocol version 2, ssh uses ssh-keysign to access the host keys, eliminating the requirement that ssh be setuid root when host-based authentication is used. By default, ssh is not setuid root. |
| /etc/ssh/ssh_known_hosts | Lista de chaves de host conhecidas em todo o sistema. Esse arquivo deve ser preparado pelo administrador do sistema para conter as chaves do host público de todas as máquinas da organização. Deve ser legível ao mundo. Veja sshd para mais detalhes sobre o formato deste arquivo. |
| / etc / ssh / sshrc | Os comandos neste arquivo são executados pelo ssh quando o usuário efetua login, imediatamente antes do shell (ou comando) do usuário ser iniciado. Veja a página de manual do sshd para mais informações. |
Exemplos
slogin shell.computerhope.com
O exemplo acima iniciaria uma conexão segura com shell.computerhope.com . Abaixo está um exemplo do que você pode ver durante o login:
A autenticidade do host 'shell.computerhope.com (204.228.150.3)' não pode ser estabelecida. A impressão digital da chave DSA é 58: 1f: 6d: 32: 8d: 1e: 2d: 5c: 8f: 00: f7: 14: 02: f0: c5: cb. Tem certeza de que deseja continuar se conectando (sim / não)? sim Aviso: Adicionado permanentemente 'shell.computerhope.com, 204.228.150.3' (DSA) à lista de hosts conhecidos. Nome de usuário: hopeuser Senha: Computerhope Linux 2.4.30-grsec # 4 SMP Segunda-feira, 13 de junho 19:38:13 MDT 2005 i686 GNU / Linux Bem-vindo ao servidor de shell do computador. ...
O servidor fornece uma chave de impressão digital DSA, verifica se você deseja se conectar e, se verificado, adiciona o endereço à sua lista de hosts conhecidos. Em seguida, solicita nome de usuário e senha.
Comandos relacionados
scp – Copie arquivos com segurança em uma conexão de rede.
sftp – Conduza uma sessão FTP interativa em uma conexão de rede segura.
