Perguntas[ssh](server)

Resumo da questão

Estou enfrentando um atraso muito longo (~20–40 segundos) ao abrir uma nova sessão SSH ou ao usar sudopela primeira vez um terminal no meu sistema Debian 11. sudoComandos subsequentes no mesmo terminal são instantâneos, mas o atraso retorna em um novo terminal. Para sua informação, isso acontece tanto com SSH remoto quanto com SSH local ( ssh admin@localhost).

O que eu tentei

• UseDNS noe GSSAPIAuthentication nosão definidas em sshd_config.
• Nenhum módulo PAM personalizado ou relacionado à rede (sem pam_ldap, pam_krb5, pam_sss, etc.).
• Comentado pam_systemd.soem sessão comum sem efeito.
• nsswitch.conf é padrão: somente filese dnspara hosts, sem LDAP/NIS para usuários/grupos.
• hosts está correto e inclui ambos 127.0.1.1e o IP real com o nome do host.
• Nenhum /etc/nologinarquivo.
• As permissões tmp estão corretas ( drwxrwxrwt).
• Nenhuma regra access.conf.
• profile, bash.bashrc, environment e dotfiles do usuário estão limpos ou foram movidos temporariamente.
• Sem cotas ou problemas de espaço em disco.
• o correio existe e é acessível.
• passwd e group são normais.
• Nenhuma entrada incomum em sudoers ou sudoers.d.
• Nenhum /etc/motd.d/script MOTD ou scripts personalizados.
• Nenhum problema com limits.conf ou limits.d.
• Não /etc/ldap.confou /etc/sssd/sssd.confpresente.
• systemd-logind, dbus, e polkitestão em execução e foram reiniciados.
• Nenhum erro em dmesg, auth.log ou syslog.
• Sem alta carga de CPU, memória ou E/S durante o atraso.
• Nenhuma montagem de rede ou autofs.
• As permissões pts estão corretas.
• Os diretórios pessoais existem, têm permissões corretas e são locais.
• O shell é bash e funciona.
• Testado com o mínimo de usuários e sh como shell
• straceligado sudoe sshdmostra que o atraso ocorre antes que os scripts do shell ou do perfil do usuário sejam executados.
• straceon sshde seus filhos mostram longas esperas em select()ou read()em descritores de arquivo internos (não soquetes de rede).
• O atraso ocorre depois que a autenticação da senha é bem-sucedida, mas antes que o prompt do shell apareça.
• ssh -vvva saída mostra o atraso antes debug2: we sent a password packet, wait for replye depois debug1: Authentication succeeded (password).

Atualizar

• Entropia disponível: 256
• O hardware é Armv7 Cortex A7 dual-core 1GHz, 2GB DDR3L, o armazenamento é eMMC

Estou completamente sem ideias... O que inicialmente parecia um simples problema de DNS me deixou sem a mínima ideia do que realmente está acontecendo.

Obrigado por qualquer ajuda ou informação!

Usando o Rocky 9.4 e o OpenSSH 8.7p1, tenho um par de chaves RSA que não é aceito, a menos que o sshd esteja em modo de depuração. (Felizmente, tenho um par antigo que funciona).

Desativei o SSH_AUTH_SOCK e verifiquei que nenhum agente está envolvido. Movi o ~/.ssh/config para evitar essa complicação. Verifiquei que o ~/.ssh/ está no modo 0700, id_rsa e authorized_keys estão em 0400 e known_hosts está em 0600. Confirmei que a chave pública correta está em authorized_keys e verifiquei usando 'ssh-keygen -l'.

Quando o sshd está sendo executado como um serviço e eu executo 'ssh -avv -i ~/.ssh/id_rsa localhost', vejo:

Offering public key:  (with the correct filename and SHA256 fingerprint)
we sent a publickey packet, wait for reply
Authentications that can continue:  publickey, ...
we did not send a packet, disable method
Next authentication method: keyboard-interactive

... e sou solicitada minha senha normal.

/var/log/secure mostra:

Connection from 127.0.0.1 ...
Failed publickey for (user) and shows the same correct SHA256 code.

Encontrei o conselho de que eu deveria interromper o serviço sshd e executá-lo manualmente em modo de depuração. Abri uma segunda sessão como root e executei:

systemctl stop sshd
/usr/sbin/sshd -D -ddd -e

Quando repito o comando 'ssh -avv -i ~/.ssh/id_rsa localhost' na janela do usuário original, vejo:

Offering public key:  (with the correct filename and SHA256 fingerprint)
we sent a publickey packet, wait for reply
Server accepts key:   (with the correct filename and SHA256 fingerprint)
Enter passphrase for key '(filename)':  (I type passphrase)
Authenticated to 127.0.0.1 (via proxy) using "publickey".

... e consegui fazer login usando a mesma chave.

Eu esperava que sshd -D -ddd me ajudasse a descobrir o problema, mas ele aceita minha chave com prazer.

Atualização 2024-04-30

Seguindo a sugestão de @mircea-vutcovici , a configuração LogLevel: DEBUGgerou sshdsequências diferentes de mensagens ao tentar chaves diferentes: a tentativa com falha incluiu uma mensagem que authorized_keysnão era legível, apesar de todas as chaves estarem no mesmo arquivo e na mesma sshdinstância!

Meu diretório home é um compartilhamento NFS e o SELinux está sendo aplicado, então pesquisei mais usando a sugestão do @grawity : ls -LZproduziu system_u:object_r:nfs_t:s0um rótulo genérico do SELinux. Aparentemente, isso é um problema se a montagem NFS preceder o patchwork de carregamento da política SELinux: selinux: faça o NFS rotulado funcionar quando montado antes do carregamento da política . Esse problema foi corrigido em 2023 e deveria ter sido incluído no Rocky 9.4 (meados de 2024). Dito isso, /homeé montado com NFS, vers=3a propósito.

Finalmente, encontrei um encantamento útil serverfault: Rótulos SELinux errados em casas NFS? : setsebool -P use_nfs_home_dirs on. Agora posso usar ambas as chaves, mas ainda não consigo entender por que elas foram tratadas de forma diferente, já que ambas as chaves públicas estão no mesmo arquivo e ambas as chaves privadas têm as mesmas permissões na mesma pasta.

Acabei de me deparar com uma pergunta semelhante de 13 anos atrás: a autenticação de chave pública falha SOMENTE quando sshd é daemon . Aparentemente, o SELinux é sempre o problema :-) Vou dar os créditos ao @grawity por uma resposta que me fez cair em uma grande enrascada.

A situação: host Debian12, apache2 httpd servindo git CGI (localizado em /repos/git) para clonagem de repositórios. Repos são armazenados no /reposdiretório e são de propriedade do gitusuário para habilitar acesso ssh a eles (por exemplo, para poder escrever no console).git push [email protected]:repos/repo.git

O problema é que, ao executar git clone https://example.com/repos.gitquando tudo é propriedade do usuário git, o git CGI imprime isso em stderr:

(13)Permission denied: [client <ip>:<port>] AH00035: access to /repos.git/info/refs denied (filesystem path '/repos/git') because search permissions are missing on a component of the path

e os comandos clone funcionam bem se eu executar chown -R www-data:www-data /repos. Mas dessa forma, não consigo acessar o repositório via ssh ( fatal: detected dubious ownership in repository at /repos/repo.gitno cliente, mesmo quando gito usuário está dentro www-datado grupo)

Tentei fazer o diretório ser de propriedade de use gite group www-datae habilitar sharedRepository=0640na configuração (eu também tentei valores diferentes), mas então o script CGI falha com esse dubious ownershiperro. Tentei configurar a configuração global, tentei fazer diretório 2777e 0666permissões, mas nada funciona.

Para esclarecer, eu realmente não gosto de fazer login como www-datausuário para acesso ssh a repositórios git. E eu sinto que deve haver algo sharedRepositoryque eu possa executar, mas não consigo entender o que deveria ser.

PS: Não preciso, gitwebpois estou executando o cgit, e apache2a configuração deveria (pelo menos em teoria) ser irrelevante aqui.

Acabei de ler esta resposta. Execute o script de shell sempre que qualquer usuário fizer logon .

Debian estável aqui. Meu servidor SSH tem conexão de chave pública, não por senha. No entanto, eu gostaria de executar um script no servidor quando um usuário se conecta, antes que ele possa obter acesso à máquina. Se o script retornar falso, o usuário é rejeitado, mesmo que ele tenha a chave adequada para se conectar.

Entendo que /etc/profile poderia ser usado, mas existe uma maneira melhor, no momento em que escrevo esta pergunta, que possa lidar com essa situação? (ou ainda mais segura ou mais fácil? Não vejo nenhum problema com /etc/profile, mas talvez alguém mais versado nessa área saiba)

Não quero escapar desse controle de forma alguma.

Obrigado, rapazes

Tenho o seguinte sistema Linux antigo e uso uma ferramenta de software proprietária que tenta copiar arquivos (com sftp ou curl) para um sistema Linux mais novo, mas falha. Os sistemas são:

Cheirando a troca vemos:

• O pacote de resposta de troca do Grupo Diffie-Hellman do servidor confirma os seguintes parâmetros negociados:
  • Algoritmo de troca de chaves (KEX): diffie-hellman-group-exchange-sha256 (corresponde ao suporte do cliente ✅)
  • Algoritmo de criptografia: aes128-ctr (corresponde ao suporte do cliente ✅)
  • Algoritmo MAC: hmac-sha2-256 (corresponde ao suporte do cliente ✅)
  • Compressão: nenhuma (corresponde ao suporte do cliente ✅)
  • Tipo de chave do host: ssh-rsa (corresponde ao suporte do cliente ✅, mas veja abaixo)
  • Tipo de assinatura do host: rsa-sha2-256 (problema potencial ⚠️)

O tipo de chave de host na resposta KEX do servidor é ssh-rsa, que o cliente suporta. No entanto, o tipo de assinatura usado pelo servidor é rsa-sha2-256, que o cliente não anunciou suporte em sua mensagem SSH_MSG_KEXINIT.

Tenho olhado o arquivo /etc/ssh/ssh_configand /etc/ssh/sshd_configpara uma modificação de configuração que eu poderia fazer no sistema Rocky Linux 9.5 para suportar a troca, mas não encontrei nenhuma. Também tentei adicionar o seguinte a /etc/ssh/sshd_config (conforme proposto por este outro caso ), mas isso também falhou:

# Allow mildly-outdated cipher selection                                                                                                                                                                                                                                                                                                                              
Ciphers +aes128-cbc                                                                                                                                                                                                                                                                                                                                                   
                                                                                                                                                                                                                                                                                                                                                                        
# Allow negotiating cipher key using weak DH                                                                                                                                                                                                                                                                                                                          
# (only add group1 if you *really* need it)                                                                                                                                                                                                                                                                                                                           
KexAlgorithms +diffie-hellman-group14-sha1,diffie-hellman-group1-sha1                                                                                                                                                                                                                                                                                                 
                                                                                                                                                                                                                                                                                                                                                                        
# Offer SHA1 signatures for host pubkey                                                                                                                                                                                                                                                                                                                               
HostKeyAlgorithms +ssh-rsa                                                                                                                                                                                                                                                                                                                                            
                                                                                                                                                                                                                                                                                                                                                                        
# Accept SHA1 signatures for client pubkey                                                                                                                                                                                                                                                                                                                            
PubkeyAcceptedAlgorithms +ssh-rsa    

A solução real será atualizar esse antigo derivado do CentOS 7, mas antes de fazer isso preciso fazer a cópia do arquivo funcionar para concluir vários testes.

Estou, portanto, procurando uma solução temporária onde eu modificaria a configuração do sistema Rocky Linux 9.5 para permitir a transferência de arquivos. Alguém sabe qual alteração/adição de configuração deve ser feita?

Estou confuso sobre o que ssh -tfaz e por que às vezes preciso da -topção. Meu entendimento é que se eu executar ssh -t program, o ssh é forçado a alocar um pseudo tty, com o qual ele passa a entrada do teclado para program's e passa a programsaída de 's para stdout.

Mas parece que estou errado. Por exemplo, os dois seguintes parecem funcionar de forma idêntica, pois posso operar interativamente com rclone usando qualquer um deles, embora o primeiro comando o force a alocar um pseudo tty e o segundo comando o force a não alocar um pseudo tty:

1. ssh -t [email protected] rclone config
2. ssh -T [email protected] rclone config

Então o que ssh -trealmente faz?

Atualizar:

Para esclarecer melhor essa questão, criei o seguinte script python chamado hello.py.

import sys, signal

def signal_handler(sig, frame):
    print('You pressed Ctrl+C!')
    sys.exit(0)

signal.signal(signal.SIGINT, signal_handler)

print(f"stdin is tty:{sys.stdin.isatty()}")
print(f"stdout is tty:{sys.stdout.isatty()}")

s = input("Enter what you want:")
print("Hello ", s)

Em uma máquina remota, se eu invocá-lo como , obtenho a seguinte saída:ssh -t [email protected] "python hello.py"

stdin is tty: true
stdout is tty: true
Enter what you want: cat
Hello cat

Se eu invocá-lo como , obtenho o seguinte:ssh -T [email protected] "python hello.py"

stdin is tty: false
stdout is tty: false
Enter what you want: cat
Hello cat

Em ambos os casos, consigo interagir com o programa digitando "cat" no teclado.

Uma diferença que observo é que quando pressiono CTRL-C, a -tversão captura SIGINT, mas a -Tversão não.

Estou curioso para saber por que ainda consigo interagir com ele mesmo que stdin/stdout não seja um tty. Além disso, isatty()é de fato uma função de biblioteca C padrão. O que um (pseudo) TTY realmente significa aqui?

Meu objetivo é obter login SSH 2FA (senha + OTP) quando conectado de fora da minha rede local, enquanto uso login SSH "somente senha" da rede local (192.168.1.0/24).

Atualmente tenho o primeiro bit (senha + OTP) funcionando com a seguinte configuração:

Meu /etc/ssh/sshd_config:

KbdInteractiveAuthentication yes
UsePAM yes

Meu /etc/pam.d/sshd:

#@include common-auth
auth    required     pam_unix.so nullok_secure
auth    required     pam_oath.so usersfile=/etc/users.oath window=30 digits=6

Como obter o segundo bit (somente senha, sem OTP) da rede local?

Desde já, obrigado!

Estou tentando configurar minha Gen 1 Cloud Key (CK) para permitir autenticação sem senha para que eu possa executar um script bash para baixar arquivos de autobackup. Eu consigo fazer SSH na CK "manualmente" e também com meu script bash usando nome de usuário/senha, mas isso armazenaria as credenciais em texto simples, o que eu (obviamente) não quero fazer.

Eu tenho:

• gerou as chaves na minha máquina local (MBP Sequoia 15.1.1) com ssh-keygen -t rsa,
• copiou a chave pública para o arquivo CK ~/.ssh/authorized_keys,
• modificado /etc/ssh/sshd_configpara incluir as seguintes linhas (não comentadas): RSAAuthentication yes, PubkeyAuthentication yes, e AuthorizedKeysFile .ssh/authorized_keys,
• reiniciou o ssh no CK com sudo systemctl restart sshd,
• permissões verificadas com chmod 700 ~/.sshe chmod 600 ~/.ssh/authorized_keys.

Mas ainda sem alegria. O log SSH diz,

...
debug1: Next authentication method: publickey
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /Users/Hank/.ssh/id_rsa RSA SHA256:KEY_VALUE_REDACTED
debug1: Will attempt key: /Users/Hank/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/Hank/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /Users/Hank/.ssh/id_ed25519 
debug1: Will attempt key: /Users/Hank/.ssh/id_ed25519_sk 
debug1: Will attempt key: /Users/Hank/.ssh/id_xmss 
debug1: Will attempt key: /Users/Hank/.ssh/id_dsa 
debug1: Offering public key: /Users/Hank/.ssh/id_rsa RSA SHA256:KEY_VALUE_REDACTED
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Trying private key: /Users/Hank/.ssh/id_ecdsa
debug1: Trying private key: /Users/Hank/.ssh/id_ecdsa_sk
debug1: Trying private key: /Users/Hank/.ssh/id_ed25519
debug1: Trying private key: /Users/Hank/.ssh/id_ed25519_sk
debug1: Trying private key: /Users/Hank/.ssh/id_xmss
debug1: Trying private key: /Users/Hank/.ssh/id_dsa
debug1: Next authentication method: password
[email protected]'s password: 
...

e então ainda sou solicitado a digitar uma senha. Acredito que a pista para o problema esteja nesta linha:

nenhum algoritmo de assinatura mútua

Isso significa que as instâncias de SSH nos dois dispositivos são incompatíveis e, portanto, usar autenticação baseada em chave não é possível? Parece que deveria ser simples, mas algo não está certo.

TLDR; O software do controlador Unifi suporta autenticação baseada em chave SSH, mas isso só se aplica à conexão a dispositivos de rede como APs, switches e roteadores. O CK é um cliente e aparentemente não é possível atingir meu objetivo por meio do software do controlador.

Há muita conversa em torno dessa abordagem, mas nada parece abordar esse problema específico.

EDIT: Eu encontrei isso, o que está me levando a acreditar que meu CK (que é reconhecidamente antigo) pode ser a fonte do problema. Atualizar o ssh no CK, embora teoricamente possível, é uma solução abaixo do ideal porque eu esperaria que futuras atualizações de firmware sobrescrevessem quaisquer alterações intermediárias.

A resposta é usar algo diferente de RSA?

EDIT2 : Solução - FTF, aqui estão os comandos revisados ​​que funcionaram no meu caso:

• Gerar par de chaves:ssh-keygen -t ed25519
• Copie a chave pública para o servidor:ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]
• Verifique as permissões: chmod 700 ~/.sshechmod 600 ~/.ssh/authorized_keys
• Reiniciar: sudo systemctl restart sshd(pode não ser necessário)

Preciso fazer um backup temporário de ca 1 TB antes de mover um servidor local, e o outro local de armazenamento que tenho é um cluster HPC remoto com cota de armazenamento suficiente, mas um limite na contagem de arquivos, e há muitos arquivos. Criar um arquivo tar na máquina local é muito lento (velocidade de gravação?).

Então, como posso transferir os arquivos locais para um arquivo tar remoto? Eu estava pensando em montar o sistema de arquivos remoto localmente (com sshfs?) e então usar algo como tar -cf /mnt/remote/backup.tar local_folder(Deve funcionar, certo?). Mas isso pode ser feito sem montar? Talvez usando algum magic pipe de ssh, scpe tar?

Se eu conseguir fazer isso funcionar, também é possível atualizar o arquivo remoto com arquivos locais atualizados como uma solução de backup adequada? (Isso não é necessário para a tarefa atual.)

De tempos em tempos e por vários motivos, o PyTTY perde a conexão com sessões SSH no meu servidor CentOS 7 (o PuTTY está com bugs, o servidor SSH está com bugs, o roteador foi reinicializado, a conexão caiu, o cabo foi desconectado etc.). Essas sessões abandonadas são um fardo para o servidor e consomem recursos. O servidor SSH CentOS 7 pode ser configurado para encerrar automaticamente qualquer sessão SSH após 24 horas, independentemente do propósito e do estado da sessão?

Por que independentemente do propósito e status da sessão? Porque, na minha opinião, às vezes pode ser difícil distinguir entre uma sessão normal e uma sessão abandonada.