Perguntas[ssh](server)

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.

Tenho usado a abordageminternal-sftp de subsistema desde 2021 sem problemas para permitir SFTP, mas não permitir SSH.

O código do meu arquivo ssh_config é:

ForceCommand internal-sftp
Subsystem  sftp   sftp-server.exe -d \%
ChrootDirectory \%

PermitTunnel no
AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no
AllowUsers sftpuser

Assim como outros , no fim de semana após as atualizações do Windows de outubro de 2024, não consegui me conectar ao servidor via SSH.

No servidor, o servidor SSH OpenSSH não inicia e recebo um erro 1067.

Conforme recomendado, quando excluo a pasta \ssh, o serviço agora pode ser reiniciado com sucesso, mas a nova pasta ssh criada automaticamente tem o código de arquivo ssh_config padrão:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

Quando substituo esse código pelo internal-sftpcódigo acima, recebo novamente o erro 1067.

Querendo saber o que torna esse código incompatível com as novas atualizações.

Estou tentando seguir este tutorial https://p11-glue.github.io/p11-glue/p11-kit/manual/remoting.html , mas há muitos pontos que me deixam confuso.

• De que lado está o servidor pkcs11?

Ele disse "Configurando o servidor de encaminhamento PKCS#11 em um cliente local". Então eu entendo que minha máquina local desempenha um papel como servidor p11, onde se conecta diretamente com o smart-card (na configuração posterior eu uso softhsm como um smart card). Eles mencionam o P11_KIT_SERVER_ADDRESS, mas o comando é executado no "cliente local", o que é confuso.

• De que lado está o cliente pkcs11?

Na sessão "Preparando o sistema remoto para encaminhamento de socket PKCS#11". "Encaminhando o socket PKCS#11", eles localizam o diretório de tempo de execução do usuário, mas um deles é feito por "ssh". Então eu pensei que runtime directoryestava no sistema remoto. (Eles também usam o termo remote serveror remote host)

Conforme abaixo, descrevo o passo a passo que fiz em 2 contêineres, A - como minha máquina local, e B - como um host remoto. Eu uso softhsm para um smart card estimulado. Na máquina local A:

$ p11tool --list-tokens
Token 0:
    URL: pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
    Label: System Trust
    Type: Trust module
    Flags: uPIN uninitialized
    Manufacturer: PKCS#11 Kit
    Model: p11-kit-trust
    Serial: 1
    Module: p11-kit-trust.so


Token 1:
    URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=d1472478b9829554;token=mimi
    Label: mimi
    Type: Generic token
    Flags: RNG, Requires login
    Manufacturer: SoftHSM project
    Model: SoftHSM v2
    Serial: d1472478b9829554
    Module: /usr/local/lib/softhsm/libsofthsm2.so

Então, há 2 tokens disponíveis na máquina A. Eu também preciso criar um diretório de tempo de execução no host local. Caso contrário, ele mostra erro quando eu faço issop11-kit server --provider ...

export XDG_RUNTIME_DIR=/tmp/$(id -u)-today
mkdir -p $XDG_RUNTIME_DIR
chmod 700 $XDG_RUNTIME_DIR
p11-kit server --provider /usr/local/lib/softhsm/libsofthsm2.so "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=01165599c52ea1fe;token=mimi"
P11_KIT_SERVER_ADDRESS=unix:path=/tmp/0-today/p11-kit/pkcs11-73; export P11_KIT_SERVER_ADDRESS;
P11_KIT_SERVER_PID=74; export P11_KIT_SERVER_PID;

No host remoto - B (172.18.0.3):

root@1de661b77dbd:~# export XDG_RUNTIME_DIR=/tmp/$(id -u)-nginx
root@1de661b77dbd:~# mkdir -p $XDG_RUNTIME_DIR && chmod 700 $XDG_RUNTIME_DIR
root@1de661b77dbd:~# systemd-path user-runtime
/tmp/0-nginx
root@1de661b77dbd:~#  systemctl enable p11-kit-client.service
Failed to enable unit, unit p11-kit-client.service does not exist.
root@1de661b77dbd:~# systemctl list-unit-files | grep p11
p11-kit-client.service                 enabled  enabled
root@1de661b77dbd:~# mkdir /tmp/0-nginx/p11-kit 

Eu tentei fazer ssh de A para a máquina B, mas recebi o aviso, então precisei criar em B, então o aviso acabou. Na/da máquina Assh -R /tmp/0-nginx/p11-kit/pkcs11:${P11_KIT_SERVER_ADDRESS#*=} [email protected]/tmp/0-nginx/p11-kit

root@b1d0c05c4ec6:~# ssh -R /tmp/0-nginx/p11-kit/pkcs11:${P11_KIT_SERVER_ADDRESS#*=}  [email protected]
and then
root@1de661b77dbd:~# ls -l /tmp/0-nginx/p11-kit/pkcs11
srw------- 1 root root 0 Oct 17 10:56 /tmp/0-nginx/p11-kit/pkcs11
p11tool --provider /usr/lib/x86_64-linux-gnu/pkcs11/p11-kit-client.so --list-tokens
p11tool --provider /usr/local/lib/pkcs11/p11-kit-client.so --list-tokens

=> Nenhum token aparece p11-kit-client.sona máquina remota.

Cometi um erro em algum dos passos? Por que nenhum token aparece na máquina remota ao usar p11-kit-client.so?

Eu uso um script wrapper rsync para sincronizar ou fazer backup de/para vários diretórios em diferentes servidores. O script invoca rsync(obviamente), e em algumas configurações lnno servidor.

Restringir o acesso SSH usando o commandparâmetro in authorized_keyspara uma única chave with rrsync(conforme recomendado aqui ) ou chrooting o usuário nos servidores não é viável, pois preciso acessar (ler ou escrever) diretórios em muitos lugares diferentes. Usar um script wrapper para avaliar $SSH_ORIGINAL_COMMAND(conforme sugerido aqui ) permitiria chamadas estáticas para rsyncand ln, mas não para todos os parâmetros diferentes rsynccriados pelo meu script local.

Existe outra maneira de bloquear o acesso nessas circunstâncias?

Após a atualização do openssh-server é impossível remover chaves antigas do known_hostsarquivo porque ssh-keygen:

$ ssh-keygen -R oldserver
/home/grin/.ssh/known_hosts:1: invalid line
/home/grin/.ssh/known_hosts:12: invalid line
/home/grin/.ssh/known_hosts:123: invalid line
Not replacing existing known_hosts file because of errors

Preciso remover essas linhas individualmente?

Estou automatizando a geração de chaves com ssh-keygen(OpenSSH v8.9), em um servidor headless. Isso é direto se nenhuma senha for necessária, mas fica difícil se você precisar de uma senha. ssh-keygenprecisa de 3 coisas no stdin ao gerar uma nova chave: y, porque o arquivo de chaves já existe, e a senha necessária, repetida duas vezes.

Com alguma simplificação, estou fazendo isso da seguinte maneira:

$ printf -v input "y\npassword\npassword\n"
$ echo -n "$input"
y
password
password
$ echo -n "$input" | ssh-keygen -t ed25519 -a100 -f tmpkey

Quando fiz isso inicialmente, obtive esta saída:

Generating public/private ed25519 key pair.
tmpkey already exists.
Overwrite (y/n)? ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory

O par de chaves foi criado, mas a chave privada não foi criptografada. Então, eu instalei ssh-askpass, em um sistema de teste com X. Quando eu executo ssh-keygenagora, eu recebo um pop-up de autenticação OpenSSH, e stdin agora é ignorado. Obviamente, eu não posso ter um pop-up gráfico em um servidor headless, mesmo se eu quisesse.

Então o que está acontecendo? Posso persuadir ssh-keygena automatizar a entrada de senha? Se não, posso usar opensslpara adicionar uma senha ou até mesmo criar o arquivo? Eu quero obter uma chave de formato OpenSSH disso - já estou automatizando o PKCS#8 com o openssl.

EDITAR

Eu encontrei o SSH_ASKPASS_REQUIREenvvar para ssh(não ssh-keygen). Se eu configurá-lo para 'never', ele para o ssh-askpasspopup, mas ssh-keygenagora lê apenas a primeira linha de stdin e ignora a senha nas próximas duas linhas. Então, não me leva a lugar nenhum.

Isso seria útil em situações onde:

• servindo chaves SSH via KeePass onde não há caminho de arquivo e
• caso contrário, há muitas chaves: como sshtenta todas elas e alguns hosts são configurados para permitir um pequeno número de tentativas (então um "Too many authentication failures"erro é dado)

Problema: Para atividades de suporte técnico, os técnicos devem fazer login nos sistemas do cliente usando credenciais fornecidas pelo cliente, mas precisamos registrar qual técnico está conectado a qual sistema para segurança e conformidade com a ISO.

Configuração atual: configurei hosts bastion ssh (Debian 12) para essas atividades de suporte ao cliente. Reforçamos o acesso aos sistemas do cliente através do(s) bastião(ões); cada técnico possui uma conta no bastião e se autentica por meio de chaves ssh.

O bastião é usado para acesso ssh e web aos sistemas do cliente. O acesso SSH é realizado por meio do recurso de salto SSH (ssh -J) e o acesso à Web é realizado por meio de proxy SSH SOCKS5.

Precisamos registrar cada conexão TCP de saída do bastião com pelo menos o nome de usuário do técnico que iniciou a conexão, o endereço IP de destino e a porta.

Fomos auditados, os logs são ingeridos em um SIEM por meio do RSyslog. A configuração de trabalho atual usa uma configuração auditada simples para registrar conexões:

auditctl -a always, exit -S connect -F success=1

Por algum motivo que ainda não entendi, quando um usuário inicia uma conexão com um sistema do cliente usando o bastião como jumphost, uma consulta DNS é registrada (com atribuição correta do usuário), mas não a conexão real com o host de destino.

Aqui está o que recebo nos logs de auditoria:

Aug 20 15:26:09 bastion1 audisp-syslog: type=SYSCALL msg=audit(**1724167569.113:16994887**): arch=c000003e syscall=42 success=yes exit=0 a0=b a1=7f49a2dfa454 a2=10 a3=7ffe86122474 items=0 ppid=3840918 pid=3840929 auid=1002 uid=1002 gid=1002 euid=1002 suid=1002 fsuid=1002 egid=1002 sgid=1002 fsgid=1002 tty=(none) ses=5005 comm="sshd" exe="/usr/sbin/sshd" subj=unconfined key=(null) ARCH=x86_64 SYSCALL=connect AUID="firstname-lastname" UID="firstname-lastname" GID="firstname-lastname" EUID="firstname-lastname" SUID="firstname-lastname" FSUID="firstname-lastname" EGID="firstname-lastname" SGID="firstname-lastname" FSGID="firstname-lastname"
Aug 20 15:26:09 bastion1 audisp-syslog: type=SOCKADDR msg=audit(**1724167569.113:16994887**): saddr=02000035080808080000000000000000 SADDR={ saddr_fam=inet **laddr=8.8.8.8 lport=53** }
Aug 20 15:26:09 bastion1 audisp-syslog: type=PROCTITLE msg=audit(**1724167569.113:16994887**): proctitle=737368643A20726F646F6C666F2D73616363616E69205B707269765D
Aug 20 15:26:09 bastion1 audisp-syslog: type=EOE msg=audit(**1724167569.113:16994887**):

Esta consulta DNS é registrada, mas não há registro sobre a conexão SSH real.

Em relação ao proxy SOCKS, o auditd não parece ser capaz de fornecer os logs que precisamos, as conexões de saída parecem ser iniciadas pelo usuário sshd.

Alguma sugestão sobre como resolver esse problema?

Obrigado