Pasta do Mac Dev em falta, SSH não funciona

Question

Alguns dias atrás, o SSH parou de funcionar.

1. Alguém pode me ajudar a fazer o SSH funcionar (costumava ser)
2. Ajude-me a entender a pasta de desenvolvimento do UNIX
3. Existe algum PUTTY como os clientes Mac.

Quando eu tento efetuar login com o SSH, recebo a seguinte mensagem:

PTY allocation request failed on channel 0
stdin: is not a tty
fatal: unrecognized command ''
Connection to 74.52.61.194 closed.

Pesquisas na Web mostraram que pode haver algo errado com a pasta / dev / std /.
Mas eu tenho revelado pastas ocultas e não consigo encontrar a pasta / dev / (há um alias para dev, mas o Mac afirma que é um link quebrado) idem quando eu procuro por ele com outras ferramentas como Houdini. Eu poderia fazer o cd nele, então estou confuso sobre o que há com esta pasta.

Há alguma ferramenta que possa salvar minhas preferências de SSH para que eu não precise, a cada vez, digitar o nome de usuário @ adrees, senha, caminho que é longo e complexo?

Não procurando por um cliente do tipo Filezilla, existem muitos deles. Procurando por uma linha de comando como putty, que me permite usar o bash no cliente remoto.

Estou no Macbook Pro, a última versão do Tiger.

EDITAR: Já tentei SSH com -v, aqui está a saída, se pode ajudar um super usuário experiente?

OpenSSH_5.2p1, OpenSSL 0.9.8l 5 Nov 2009
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to 74.52.61.194 [74.52.61.194] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/identity type -1
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host '74.52.61.194' is known and matches the RSA host key.
debug1: Found key in /Users/me/.ssh/known_hosts:2
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/me/.ssh/identity
debug1: Offering public key: /Users/me/.ssh/id_rsa
debug1: Remote: Forced command: perl -e 'exec qw(git-shell -c), $ENV{SSH_ORIGINAL_COMMAND}'
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Server accepts key: pkalg ssh-rsa blen 277
debug1: read PEM private key done: type RSA
debug1: Remote: Forced command: perl -e 'exec qw(git-shell -c), $ENV{SSH_ORIGINAL_COMMAND}'
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: Remote: Pty allocation disabled.
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
PTY allocation request failed on channel 0
stdin: is not a tty
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
fatal: unrecognized command ''
debug1: channel 0: free: client-session, nchannels 1
Connection to 74.52.61.194 closed.
Transferred: sent 2448, received 2856 bytes, in 0.4 seconds
Bytes per second: sent 6027.2, received 7031.8
debug1: Exit status 0

    

Answer 1

Você deve usar o Terminal.app para executar o SSH, e para os hosts aos quais você se conecta regularmente, você cria aliases e configura as chaves de criptografia para que possa fazer logins mais rápidos.

Para criar um alias:

alias gohost='ssh [email protected]'

Claro, chame o alias de algo útil para você, em vez de gohost .

Para criar uma chave ssh, você faz:

ssh-keygen

Siga os prompts, aceite os padrões a menos que você saiba o que está fazendo. Deixe a frase-chave em branco se quiser um login sem senha, se quiser manter o login com senha, basta pular o ssh-keygen e usar gohost para se conectar ao seu host.

A coisa boa sobre as chaves ssh é que você pode fazer scp (cópia segura) e rsync sobre ssh, sem ter que digitar sua senha o tempo todo, é claro que você quer ter certeza de que sua conta no Mac é seguro, para que apenas você possa usar essas chaves (elas estão vinculadas à sua conta e armazenadas na pasta ~/.ssh ).

Se você criar uma chave ssh, precisará copiar a chave pública para sua casa no servidor, então vamos copiar a chave pública para a área de transferência.

cat ~/.ssh/id_rsa.pub | pbcopy

( pbcopy pega a entrada padrão e a coloca na área de transferência do mac, pbpaste faz o oposto e envia o conteúdo da área de transferência para a saída padrão, mas apenas o texto.)

Em seguida, conecte-se ao host ssh e faça:

cat >> ~/.ssh/authorized_keys

Cole a chave da área de transferência, pressione Enter e Ctrl-D , saia do host e tente conectar-se novamente, se tudo estiver bem, você ' Você só se encontrará no prompt do host novamente, sem precisar de senha.

Por que o seu ssh não está funcionando?

Olhando para a sua saída de depuração, há algumas coisas que não estão claras. Primeiro de tudo, parece que a instalação do ssh está ok.

A mensagem de erro também sugere que /dev/pty não existe, verifique se não (no Finder) ...

Mas isso parece ser um erro do servidor, você tentou o ssh para outro servidor?

Pasta de desenvolvimento

Se você não pode fazer sudo ls /dev , então algo está errado com o seu sistema.

Para explicar o que é /dev , o Unix (no qual o OS X é baseado) usa /dev para acessar dispositivos, entrada padrão, saída padrão, discos rígidos, unidades de cd / dvd, etc.

Isso permite que o Unix acesse dispositivos como parte do sistema de arquivos, comunicar com eles.

No uso geral, você deve deixar a pasta /dev sozinha, algumas ferramentas GUI (software de backup, por exemplo, ou no seu caso Houdini) ocasionalmente reportarão algum erro ou outro sobre ele, porque não é uma pasta entenderá. (O ideal é que eles devessem ignorá-lo.)

    

Answer 2

O seguinte é o que funcionou para mim.
Está sendo escrito para ajudar outras pessoas que se deparam com o mesmo problema, mas não é a resposta "correta", pois tenho certeza de que não deveria ter funcionado. Leia o tópico na resposta de slomojo para obter o resumo completo.

1. Sintoma : O SSH no Mac parou de funcionar no meu servidor hospedado no Site5. Consegui o SSH para outros servidores sem um problema.
   Problema : O SSH enviará automaticamente qualquer chave nos arquivos .ssh / id_rsa ou .ssh / id_dsa.
   Ao configurar contas do GitHub, é comum criar esses arquivos.
   O Site5 estava obtendo e explorando as chaves não reconhecidas do GitHub.
   Solução : Mudei a chave privada do GitHub de .ssh / id_rsa para outro arquivo (por exemplo, .ssh / GitHub) e adicionei um arquivo de configuração para direcionar o SSH para essa chave. Depois que a chave do GitHub não estava sendo enviada para o site5, tudo funcionou.
   Do ponto de vista da segurança, isso parece um grande problema, pois, do contrário, seria fácil roubar minhas chaves. (Eu não entendo SSH, então pode estar faltando algo óbvio.)

2. A pasta dev não tinha nada a ver com o meu problema, que era do lado do servidor.
   No entanto, a pasta dev é melhor explicada aqui: link

3. Para criar aliases, Slomojo escreve:

alias commands should be in your shell startup, if you use bash, ~/.bash_profile is the place to put them. Just edit/create it and put your aliases at the end. More info on alias here - ss64.com/bash/alias.html

Boa sorte a todos!