Quando eu ssh em outra máquina Ubuntu com minha conta (com permissões sudo), minha tecla backspace gera alguns símbolos estranhos ao pressionar. Também as teclas Tab, Del e Arrow não funcionam.
Por outro lado, também tenho outra conta na mesma máquina & amp; quando eu ssh através desta conta, o seu terminal funciona perfeitamente bem. Eu não consegui descobrir porque isso está acontecendo.
EDIT: Referência: resposta
da Mateng Mateng está perto disso e acho que você provavelmente está executando o Bourne Shell. Mas você não deveria estar editando seu arquivo /etc/passwd diretamente. Tente usar o comando chsh :
chsh -s /bin/bash
O sinalizador -s fará com que o novo shell (Bash, neste caso) seu shell de login vá em frente.
As seguintes alterações resolveram o problema para mim. Primeiro, verifiquei qual shell estava em execução:
$ echo $0
que retornou:
/bin/sh
Ao ler esta postagem no Ubuntuforums , a alteração do shell para /bin/bash traz a solução. Então eu editei minhas configurações de usuário em /etc/passwd para:
johndoe:x:1001:104:John Doe:/home/johndoe:/bin/bash
Eu fiz o logout e fiz o login novamente. Estranhamente, eu tive que mudar o shell manualmente (talvez algum cache estava ativo), digitando isso:
/bin/bash
Voila!
[O problema surgiu devido a uma atualização de distribuição.]
quando você primeiro ssh, tente estes dois comandos
stty sane
export TERM=linux
Eu tenho que fazer isso em algumas máquinas que eu vou para corrigir exatamente esse problema
Uma das maneiras mais fáceis de corrigir esse problema é digitar / bin / bash no prompt da interface da linha de comandos:
$ / bin / bash
O comando acima mencionado executará o Bourne Again Shell na parte superior do shell existente como um subprocesso. Isso apresenta a desvantagem de utilizar mais recursos, mas nada precisa ser editado e nenhuma permissão especial é necessária. Por exemplo, nas versões recentes do Kubuntu, ele iniciará uma sessão / bin / bash sobre a interface padrão da shell de linha de comando / bin / dash.
Para persistir as mudanças, uma possibilidade é editar o arquivo / etc / passwd e adicionar / editar / substituir o shell padrão para / bin / bash após o último caractere ':' na linha correspondente ao usuário. Para editar esse arquivo, porém, seriam necessários privilégios de administrador.
'Terminal Gbnome' não emula exatamente 'xterm' ..
de: Wikipedia > > Terminal do GNOME
O Terminal GNOME emula o emulador de terminal xterm e fornece algumas as mesmas características.
Um tratado sobre a questão e solução (ões) pode ser encontrado aqui:
Backspace do Linux / Excluir mini-HOWTO
% bl0ck_qu0te%A solução mais simples fornecida (que pode funcionar aqui) é usar: bash $ export TERM = gnome
Como um usuário root edite o arquivo / etc / passwd para o seu usuário e mude de / bin / sh para / bin / bash
hdfs: x: 1020: 1001 :: / home / hdfs: / bin / sh para hdfs: x: 1020: 1001 :: / home / hdfs: / bin / bash
Isso funcionou para mim.
Eu tentei todos os itens acima, além de anotações de ( este link ) sem sucesso. Você pode querer verificar se o vim está instalado.
Eu costumo usar o vi não vim. Então eu instalei o vim.
$ sudo apt-get install vim
Depois disso, os toques no teclado começaram a funcionar corretamente quando eu executei o vi. Olhando para a saída do seguinte, parece que o vi foi feito um alias para vim após a instalação:
$ ls -al /etc/alternatives | grep vi
lrwxrwxrwx 1 root root 18 Jan 13 09:38 vi -> /usr/bin/vim.basic
Este é um problema de compatibilidade com o teclado, ou seja, como ele é interpretado no sistema host. Você pode ter que usar j ou h para mover no editor vi no modo de comando. Setas não funcionam.
Verifique a compatibilidade do perfil de preferências > no sistema host para esse usuário específico.
Ok, eu sei que isso não é uma "solução" por palavra, e pode não ajudar muitos de vocês , mas espero que ajuda pelo menos um de vocês . Isso resolveu o meu problema.
Meu filho de seis meses bateu no meu teclado, e minhas teclas de seta pararam de trabalhar na minha sessão putty em uma caixa do Debian. Eles fizeram o trabalho em qualquer outro lugar (todos os outros programas fora da massa). Depois de gozar e até mesmo aterrissar aqui (eu ia fechar essa aba, não resolveu para mim). Eu tentei alguma coisa. Eu abri uma nova sessão ssh na mesma caixa e minhas teclas de seta funcionaram. Eu entrei na minha sessão de tela e eles não funcionaram. Então, algo aconteceu ligado à sessão de tela atual, desabilitando as teclas de seta. Infelizmente, eu estava no meio de um grande projeto, tenho 28 janelas abertas na minha sessão de tela e não queria fechar a sessão, perdendo meu lugar em todas as 28 janelas.
Então ..
Enquanto estava no bash, tentei todas as combinações em que eu conseguia pensar, CTRL + cima, baixo, esquerda, ALT + cima, baixo, esquerda, direita, SHIFT + cima, baixo, esquerda direita, CTRL + ALT + para cima, para baixo, esquerda direita, CTRL + SHIFT + para cima, para baixo, esquerda direita, etc Ainda sem sorte, eu também tentei o menu do Windows e Windows app chaves com para cima, baixo, esquerda direita.
Agora minhas setas funcionam novamente! Algo sobre uma das combinações do que está acima e as teclas de seta o corrigiram.
Nenhuma das respostas acima corrigiu meu problema idêntico, ou seja, não é possível usar backspace ou chaves semelhantes após sshing para um remoto de um Ubuntu (aqui ubuntu-17.10 com ncurses-6.0).
Isso acaba sendo um problema com o terminfo. Basicamente, o meu terminal gnome diz que é um terminal xterm-256color (via a variável TERM, que é exportada por ssh para o controle remoto), mas o controle remoto não tem uma configuração de terminfo para o xterm-256color.
Fazer o seguinte corrigiu o problema:
$host: echo $TERM xterm-256color $host: infocmp >terminfo.src $host: tic terminfo.src $host: scp .terminfo/x/xterm-256color $remote:/usr/share/terminfo/x/xterm-256color
infocmp, sem nenhuma opção, produz uma listagem de origem para o terminal na variável de ambiente $ TERM. Então é equivalente a infocmp -I $ TERM.
Em seguida, a fonte resultante é compilada via tic.
Por fim, instale a configuração do terminfo correspondente no local remoto. Então, da próxima vez que eu me conectar ao $ remote via $ host, ele saberá sobre o meu terminal.