De acordo com a documentação do WinSCP , o WinScp usa o formato de chave PuTTy e requer que as chaves geradas por OpenSSHsejam convertidas ou usemos uma /keygenopção de linha de comando.
Eu queria usar SSH certificatespara autenticar o server, para resolver problemas de escalabilidade, mas esse SSHcertificado é gerado pelo OpenSSH ssh-keygen, e não tenho certeza se os certificados gerados por isso funcionarão bem sem problemas com WinSCPou WinSCP .NETbibliotecas.
SFTPos servidores podem expor a utilização do espaço em disco para um device- um volume ou disco, implementando a space-availableextensão ou por capacidade OpenSSHproprietária [email protected].
Ao conectar-se ao Bitvise SFTPservidor, que não é um OpenSSHservidor usando WinSCP, e verificando a capabilitiescaixa de diálogo WinSCP, diz que o servidor suporta -
Isso levou a alguma confusão, não tenho certeza do que um valor 2aqui indica. Além disso, isso significa que BitViseimplementa o OpenSSHmétodo de cálculo de tamanho e não space-available?
Na space availableguia, posso ver que o tamanho foi realmente calculado, mas foi calculado usando statvfsou space-available?
Na chance (provavelmente nenhuma) de que um servidor implemente ambos, talvez para atender a mais clientes, qual deles seria usado WinSCPpara esse cálculo?
Ao conectar via SFTPa um sistema remoto, WinSCPexibe os detalhes da conexão na barra de título do aplicativo, como:
user@<system_ip> - WinSCP
Eu queria saber se existe uma maneira de ocultar essas informações na barra de título. Verifiquei as Environmentopções de preferência, mas não notei nada com um olhar casual. Há uma opção na Windowseção para ocultar o caminho que está sendo navegado no sistema remoto, mas não remove os detalhes da conexão. Toolbaras opções também não tinham nada.
Uma verificação em https://winscp.net/eng/docs/guide_protecting_credentials_for_automation não forneceu as informações que eu estava procurando.
Existe uma maneira de ocultar essas informações?
Estou usando a WinSCPversão mais recente do Windows 10.
Eu tenho 3 sistemas -
Por algum motivo, não consigo conectar esses 3 em uma única rede. Todas as 3 máquinas receberam IPs estáticos, como -
I.P. estático -
192.168.1.10, 192.168.1.125, 192.168.1.25
máscara de sub-rede -
255.255.255.0
Gateway padrão -
192.168.1.1
O sistema Linux e o Windows 10 VMhospedado em cima dele se conectam bem (através de um adaptador de host para VirtualBox, tendo IPv4o valor do adaptador como 192.168.1.11) e podem até mesmo ssh nele.
No entanto, o Windows 10sistema autônomo não consegue localizar pingou mesmo sshentrar em nenhum desses sistemas. Com dynamic IPo fornecido pelo meu provedor, eles conseguem se conectar bem o suficiente, mas quando conecto os 2 sistemas (sistemas Windows 10 e Linux) por meio de um cabo ethernet em uma rede autônoma, tipo p2p, eles simplesmente não se encontram.
IPv6está desativado em cada uma das configurações de rede. A única coisa que consigo pensar é que as máquinas não especificam o mesmo workgroup, pois meu sistema Windows 10 está conectado a um domínio, e meu sistema Linux (com Windows 10 VM) não, mas no cenário descrito acima, há não há atividade de domínio, pois as máquinas estão conectadas via cabo LAN e não estão em nenhuma outra rede.
ATUALIZAR -
endereço IP
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
link/ether 00:04:5f:9e:94:43 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global noprefixroute enp1s0
valid_lft forever preferred_lft forever
inet6 fe80::204:5fff:fe9e:9443/64 scope link
valid_lft forever preferred_lft forever
3: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
link/ether 00:04:5f:9e:94:42 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:31:3c:a5 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:31:3c:a5 brd ff:ff:ff:ff:ff:ff
6: br-c91ce55ad4d6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:e6:4e:bd:04 brd ff:ff:ff:ff:ff:ff
inet 172.18.0.1/16 brd 172.18.255.255 scope global br-c91ce55ad4d6
valid_lft forever preferred_lft forever
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 02:42:ca:60:cc:f5 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
8: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.11/24 brd 192.168.1.255 scope global vboxnet0
valid_lft forever preferred_lft forever
inet6 fe80::800:27ff:fe00:0/64 scope link
valid_lft forever preferred_lft forever
rota ip
default via 192.168.1.1 dev enp1s0 proto static metric 100 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-c91ce55ad4d6 proto kernel scope link src 172.18.0.1 linkdown
192.168.1.0/24 dev vboxnet0 proto kernel scope link src 192.168.1.11
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.10 metric 100 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown
Em um Windows 10 OSsistema, instalei VirtualBoxcom 4 GB de RAM, usando CentOs 7como sistema operacional. Ao ligar a VM, a RAMutilização do sistema operacional host aumenta conforme o esperado até um determinado nível ( o sistema geral tem 8 GB de RAM ).
Espero que o sistema operacional da VM tenha sua cota de RAM (4 GB) e todos os aplicativos iniciados dentro da VM usarão sua RAM e deixarão o sistema operacional host em paz.
No entanto, quando executo o docker dentro da VM, o overall RAM consumption of the entire system increases, e quando inicio alguns contêineres baseados em java dentro da VM, o consumo de RAM do sistema aumenta novamente. Repeti esse experimento e as observações foram semelhantes.
Estou um pouco confuso com esse comportamento. Eu esperava que, uma vez que a VM iniciasse com o sistema operacional do host, ela reservaria 4 GB de memória para si mesma e todos os aplicativos iniciados dentro (docker etc.) usariam a RAM reservada para a VM, mas vejo o consumo de RAM do host ou do sistema aumentando em vez disso.
Observei o aumento do consumo de RAM no gerenciador de tarefas do Windows 10 e no Resmon.
É possível que aplicativos docker ou java iniciados dentro da VM Linux de alguma forma vejam toda a memória do sistema disponível para uso e tentem usá-la em vez disso? Eu teria pensado que isso não aconteceria, pois uma VM fornece um bom nível de isolamento do sistema operacional host.
Se o comportamento é que o sistema operacional Linux ocupa menos RAM no início na inicialização e só aumenta quando há aplicativos dentro da VM exigindo mais, é razoável esperar que, seja qual for o estado dos aplicativos, o consumo de RAM da VM diminuirá não aumentar além da cota de 4 GB alocada para ele?
Dentro do meu SFTPservidor, pretendo ter uma pasta raiz, com várias pastas para entidades separadas. Essas pastas de entidades possuem subdiretórios próprios, que pertencem a funções específicas.
Por exemplo, o usuário faz login em uma SFTPsessão e pode ver as pastas A,B e C. Dentro de cada pasta, estão as pastas D,E e F.
Eu gostaria que o SFTPusuário tivesse permissão para acessar apenas a pasta D dentro de A, B e C. As pastas E e F em A, B e C não são destinadas ao acesso do referido usuário. Espera-se que apenas um usuário esteja usando SFTP.
Examinei o sshd_configarquivo, mas não tenho certeza de como isso pode ser aplicado usando as políticas existentes. Talvez eu possa definir uma política de usuário/grupo para esse fim Windows 10, mas isso se aplicaria ao sshd daemon?
No Windows 10 1809, habilitei o servidor SSH integrado e o configurei.
Em outra máquina, usei o gerador WinSCP e PuTTy para gerar uma chave de autenticação. Copiei a parte da chave pública e a anexei ao .ssh\authorized_keysarquivo do usuário do meu servidor SSH. Corrigi as permissões de arquivo conforme necessário, apenas para meu usuário, ou seja, o usuário conectado, para o arquivo de chave.
Na máquina cliente, usei a chave privada .PPK, com WinSCP para tentar conectar em uma sessão SFTP com meu servidor, mas recebo uma mensagem de que o servidor recusou a chave que eu havia selecionado.
Consigo autenticar usando senha, mas o par de chaves não está funcionando. Vasculhando os sshdlogs gerados no servidor, vejo isto:
10200 2019-06-07 01:38:16.376 debug1: attempt 1 failures 0 [preauth]
10200 2019-06-07 01:38:16.376 debug2: input_userauth_request: try method publickey [preauth]
10200 2019-06-07 01:38:16.376 debug1: userauth_pubkey: test pkalg ssh-rsa pkblob RSA SHA256:B6s0omPbz6HJB2cIZf3+5MKHU42wp+JfOTyAM+EVqoY [preauth]
10200 2019-06-07 01:38:16.376 debug2: userauth_pubkey: disabled because of invalid user [preauth]
Não tenho certeza do que aconteceu aqui e se esse é o motivo pelo qual a conexão foi recusada. O firewall não pode ser um problema, pois consigo fazer login no servidor usando a autenticação por senha. A máquina cliente e o WinScp estão sendo reconhecidos no servidor, só que o servidor recusa a chave fornecida.
A chave gerada pelo PuTTy (ou o conteúdo da chave copiado com a chave pública) não é suportada em nenhum dos lugares? Não há senha associada à chave, mas não acho que isso deva ser um problema.
Há apenas um usuário na máquina do servidor, que é o usuário logado. O sshdserviço está sendo executado na LOCAL SYSTEMconta. Deve ser executado em uma conta de usuário (eu tentei isso, mas o serviço não inicia, os logs de eventos reclamam de um privilégio ausente ...)
EDITAR - Mais informações
Comentei o seguinte em sshd_config:
#Match Group administrators
# AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
Mas agora, uma tentativa de conexão reclama que authorized_keystem permissão ruim. A máquina só tem um usuário, e authorized_keysdentro da pasta .ssh desse usuário só esse usuário acessa. Tentei usar Repair-AuthorizedKeyPermissionno arquivo de chave, que adicionou SYSTEM e sshd (usuário do serviço NT) como usuários ao arquivo de chave, sshd tendo acesso de leitura. Mas agora, uma tentativa de conexão reclama que uma permissão incorreta foi definida para o usuário S-1-5-80, que é o mesmo NT Service user sshdadicionado por Repair-AutorizedKeyFile. Remover a permissão de leitura (somente permissão) para este usuário novamente dá o erro antigo, dizendo Access Denied.
EDIT - sshd.exe Logs de uma tentativa de conexão:
> 2696 2019-06-10 03:57:09.020 debug2: fd 3 setting O_NONBLOCK
>
> 2696 2019-06-10 03:57:09.020 debug3: sock_set_v6only: set socket 3
> IPV6_V6ONLY
>
> 2696 2019-06-10 03:57:09.020 debug1: Bind to port 22 on ::.
>
> 2696 2019-06-10 03:57:09.020 Server listening on :: port 22.
>
> 2696 2019-06-10 03:57:09.020 debug2: fd 4 setting O_NONBLOCK
>
> 2696 2019-06-10 03:57:09.020 debug1: Bind to port 22 on 0.0.0.0.
>
> 2696 2019-06-10 03:57:09.020 Server listening on 0.0.0.0 port 22.
>
> 2696 2019-06-10 03:57:35.475 debug3: fd 5 is not O_NONBLOCK
>
> 2696 2019-06-10 03:57:35.477 debug3: spawning
> "C:\\WINDOWS\\System32\\OpenSSH\\sshd.exe" "-R"
>
> 2696 2019-06-10 03:57:35.483 debug3: send_rexec_state: entering fd = 8
> config len 287
>
> 2696 2019-06-10 03:57:35.484 debug3: ssh_msg_send: type 0
>
> 2696 2019-06-10 03:57:35.485 debug3: send_rexec_state: done
>
> 9428 2019-06-10 03:57:35.556 debug1: inetd sockets after dupping: 3, 3
>
> 9428 2019-06-10 03:57:35.556 Connection from 130.147.168.135 port
> 64534 on 161.85.17.107 port 22
>
> 9428 2019-06-10 03:57:35.556 debug1: Client protocol version 2.0;
> client software version WinSCP_release_5.15.2
>
> 9428 2019-06-10 03:57:35.556 debug1: no match: WinSCP_release_5.15.2
>
> 9428 2019-06-10 03:57:35.556 debug1: Local version string
> SSH-2.0-OpenSSH_for_Windows_7.7
>
> 9428 2019-06-10 03:57:35.556 debug2: fd 3 setting O_NONBLOCK
>
> 9428 2019-06-10 03:57:35.568 debug3: spawning
> "C:\\WINDOWS\\System32\\OpenSSH\\sshd.exe" "-y"
>
> 9428 2019-06-10 03:57:35.572 debug2: Network child is on pid 6944
>
> 9428 2019-06-10 03:57:35.573 debug3: send_rexec_state: entering fd = 6
> config len 287
>
> 9428 2019-06-10 03:57:35.573 debug3: ssh_msg_send: type 0
>
> 9428 2019-06-10 03:57:35.575 debug3: send_rexec_state: done
>
> 9428 2019-06-10 03:57:35.575 debug3: ssh_msg_send: type 0
>
> 9428 2019-06-10 03:57:35.576 debug3: ssh_msg_send: type 0
>
> 9428 2019-06-10 03:57:35.576 debug3: preauth child monitor started
>
> 9428 2019-06-10 03:57:35.607 debug1: list_hostkey_types:
> ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
> [preauth]
>
> 9428 2019-06-10 03:57:35.607 debug3: send packet: type 20 [preauth]
>
> 9428 2019-06-10 03:57:35.607 debug1: SSH2_MSG_KEXINIT sent [preauth]
>
> 9428 2019-06-10 03:57:35.794 debug3: receive packet: type 20 [preauth]
>
> 9428 2019-06-10 03:57:35.794 debug1: SSH2_MSG_KEXINIT received
> [preauth]
>
> 9428 2019-06-10 03:57:35.795 debug2: local server KEXINIT proposal
> [preauth]
>
> 9428 2019-06-10 03:57:35.796 debug2: KEX algorithms:
> curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
> [preauth]
>
> 9428 2019-06-10 03:57:35.797 debug2: host key algorithms:
> ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
> [preauth]
>
> 9428 2019-06-10 03:57:35.798 debug2: ciphers ctos:
> [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
> [preauth]
>
> 9428 2019-06-10 03:57:35.798 debug2: ciphers stoc:
> [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
> [preauth]
>
> 9428 2019-06-10 03:57:35.798 debug2: MACs ctos:
> [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
> [preauth]
>
> 9428 2019-06-10 03:57:35.798 debug2: MACs stoc:
> [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
> [preauth]
>
> 9428 2019-06-10 03:57:35.798 debug2: compression ctos: none [preauth]
>
> 9428 2019-06-10 03:57:35.798 debug2: compression stoc: none [preauth]
>
> 9428 2019-06-10 03:57:35.799 debug2: languages ctos: [preauth]
>
> 9428 2019-06-10 03:57:35.799 debug2: languages stoc: [preauth]
>
> 9428 2019-06-10 03:57:35.799 debug2: first_kex_follows 0 [preauth]
>
> 9428 2019-06-10 03:57:35.799 debug2: reserved 0 [preauth]
>
> 9428 2019-06-10 03:57:35.799 debug2: peer client KEXINIT proposal
> [preauth]
>
> 9428 2019-06-10 03:57:35.799 debug2: KEX algorithms:
> [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,rsa2048-sha256,rsa1024-sha1,diffie-hellman-group1-sha1
> [preauth]
>
> 9428 2019-06-10 03:57:35.799 debug2: host key algorithms:
> ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss [preauth]
>
> 9428 2019-06-10 03:57:35.799 debug2: ciphers ctos:
> aes256-ctr,aes256-cbc,[email protected],aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,[email protected],blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128
> [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: ciphers stoc:
> aes256-ctr,aes256-cbc,[email protected],aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,[email protected],blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128
> [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: MACs ctos:
> hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5,[email protected],[email protected],[email protected],[email protected] [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: MACs stoc:
> hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5,[email protected],[email protected],[email protected],[email protected] [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: compression ctos: none,zlib
> [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: compression stoc: none,zlib
> [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: languages ctos: [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: languages stoc: [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: first_kex_follows 0 [preauth]
>
> 9428 2019-06-10 03:57:35.800 debug2: reserved 0 [preauth]
>
> 9428 2019-06-10 03:57:35.801 debug1: kex: algorithm:
> [email protected] [preauth]
>
> 9428 2019-06-10 03:57:35.801 debug1: kex: host key algorithm:
> ssh-ed25519 [preauth]
>
> 9428 2019-06-10 03:57:35.801 debug1: kex: client->server cipher:
> aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
>
> 9428 2019-06-10 03:57:35.801 debug1: kex: server->client cipher:
> aes256-ctr MAC: hmac-sha2-256 compression: none [preauth]
>
> 9428 2019-06-10 03:57:35.801 debug1: expecting SSH2_MSG_KEX_ECDH_INIT
> [preauth]
>
> 9428 2019-06-10 03:57:35.834 debug3: receive packet: type 30 [preauth]
>
> 9428 2019-06-10 03:57:35.843 debug3: mm_key_sign entering [preauth]
>
> 9428 2019-06-10 03:57:35.843 debug3: mm_request_send entering: type 6
> [preauth]
>
> 9428 2019-06-10 03:57:35.843 debug3: mm_key_sign: waiting for
> MONITOR_ANS_SIGN [preauth]
>
> 9428 2019-06-10 03:57:35.843 debug3: mm_request_receive_expect
> entering: type 7 [preauth]
>
> 9428 2019-06-10 03:57:35.843 debug3: mm_request_receive entering
> [preauth]
>
> 9428 2019-06-10 03:57:35.843 debug3: mm_request_receive entering
>
> 9428 2019-06-10 03:57:35.843 debug3: monitor_read: checking request 6
>
> 9428 2019-06-10 03:57:35.843 debug3: mm_answer_sign
>
> 9428 2019-06-10 03:57:35.846 debug3: mm_answer_sign: hostkey proof
> signature 0000029369ED8600(83)
>
> 9428 2019-06-10 03:57:35.846 debug3: mm_request_send entering: type 7
>
> 9428 2019-06-10 03:57:35.846 debug2: monitor_read: 6 used once,
> disabling now
>
> 9428 2019-06-10 03:57:35.846 debug3: send packet: type 31 [preauth]
>
> 9428 2019-06-10 03:57:35.846 debug3: send packet: type 21 [preauth]
>
> 9428 2019-06-10 03:57:35.846 debug2: set_newkeys: mode 1 [preauth]
>
> 9428 2019-06-10 03:57:35.846 debug1: rekey after 4294967296 blocks
> [preauth]
>
> 9428 2019-06-10 03:57:35.846 debug1: SSH2_MSG_NEWKEYS sent [preauth]
>
> 9428 2019-06-10 03:57:35.846 debug1: expecting SSH2_MSG_NEWKEYS
> [preauth]
>
> 9428 2019-06-10 03:57:36.356 debug3: receive packet: type 21 [preauth]
>
> 9428 2019-06-10 03:57:36.356 debug1: SSH2_MSG_NEWKEYS received
> [preauth]
>
> 9428 2019-06-10 03:57:36.356 debug2: set_newkeys: mode 0 [preauth]
>
> 9428 2019-06-10 03:57:36.356 debug1: rekey after 4294967296 blocks
> [preauth]
>
> 9428 2019-06-10 03:57:36.356 debug1: KEX done [preauth]
>
> 9428 2019-06-10 03:57:36.399 debug3: receive packet: type 5 [preauth]
>
> 9428 2019-06-10 03:57:36.399 debug3: send packet: type 6 [preauth]
>
> 9428 2019-06-10 03:57:36.435 debug3: receive packet: type 50 [preauth]
>
> 9428 2019-06-10 03:57:36.435 debug1: userauth-request for user
> TestUser service ssh-connection method none [preauth]
>
> 9428 2019-06-10 03:57:36.435 debug1: attempt 0 failures 0 [preauth]
>
> 9428 2019-06-10 03:57:36.435 debug3: mm_getpwnamallow entering
> [preauth]
>
> 9428 2019-06-10 03:57:36.436 debug3: mm_request_send entering: type 8
> [preauth]
>
> 9428 2019-06-10 03:57:36.436 debug3: mm_getpwnamallow: waiting for
> MONITOR_ANS_PWNAM [preauth]
>
> 9428 2019-06-10 03:57:36.436 debug3: mm_request_receive_expect
> entering: type 9 [preauth]
>
> 9428 2019-06-10 03:57:36.436 debug3: mm_request_receive entering
> [preauth]
>
> 9428 2019-06-10 03:57:36.436 debug3: mm_request_receive entering
>
> 9428 2019-06-10 03:57:36.436 debug3: monitor_read: checking request 8
>
> 9428 2019-06-10 03:57:36.436 debug3: mm_answer_pwnamallow
>
> 9428 2019-06-10 03:57:36.439 debug2: parse_server_config: config
> reprocess config len 287
>
> 9428 2019-06-10 03:57:36.439 debug3: checking match for 'Group
> administrators' user TestUser host 130.147.168.135 addr
> 130.147.168.135 laddr 161.85.17.107 lport 22
>
> 9428 2019-06-10 03:57:36.446 debug3: LsaLogonUser Succeeded
> (Impersonation: 0)
>
> 9428 2019-06-10 03:57:36.448 debug1: user TestUser matched group list
> administrators at line 84
>
> 9428 2019-06-10 03:57:36.448 debug3: match found
>
> 9428 2019-06-10 03:57:36.448 debug3: reprocess config:85 setting
> AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys
>
> 9428 2019-06-10 03:57:36.449 debug3: mm_answer_pwnamallow: sending
> MONITOR_ANS_PWNAM: 1
>
> 9428 2019-06-10 03:57:36.449 debug3: mm_request_send entering: type 9
>
> 9428 2019-06-10 03:57:36.450 debug2: monitor_read: 8 used once,
> disabling now
>
> 9428 2019-06-10 03:57:36.450 debug2: input_userauth_request: setting
> up authctxt for TestUser [preauth]
>
> 9428 2019-06-10 03:57:36.450 debug3: mm_inform_authserv entering
> [preauth]
>
> 9428 2019-06-10 03:57:36.450 debug3: mm_request_send entering: type 4
> [preauth]
>
> 9428 2019-06-10 03:57:36.451 debug3: mm_request_receive entering
>
> 9428 2019-06-10 03:57:36.451 debug3: monitor_read: checking request 4
>
> 9428 2019-06-10 03:57:36.451 debug3: mm_answer_authserv:
> service=ssh-connection, style=
>
> 9428 2019-06-10 03:57:36.451 debug2: monitor_read: 4 used once,
> disabling now
>
> 9428 2019-06-10 03:57:36.451 debug2: input_userauth_request: try
> method none [preauth]
>
> 9428 2019-06-10 03:57:36.452 debug3: userauth_finish: failure
> partial=0 next methods="publickey,password,keyboard-interactive"
> [preauth]
>
> 9428 2019-06-10 03:57:36.452 debug3: send packet: type 51 [preauth]
>
> 9428 2019-06-10 03:57:36.453 debug3: receive packet: type 50 [preauth]
>
> 9428 2019-06-10 03:57:36.453 debug1: userauth-request for user
> TestUser service ssh-connection method publickey [preauth]
>
> 9428 2019-06-10 03:57:36.453 debug1: attempt 1 failures 0 [preauth]
>
> 9428 2019-06-10 03:57:36.454 debug2: input_userauth_request: try
> method publickey [preauth]
>
> 9428 2019-06-10 03:57:36.454 debug1: userauth_pubkey: test pkalg
> ssh-rsa pkblob RSA SHA256:ospJEFHH81sy96YBMFEySGGUokk1KZHV+AbgNTFRrjE
> [preauth]
>
> 9428 2019-06-10 03:57:36.455 debug3: mm_key_allowed entering [preauth]
>
> 9428 2019-06-10 03:57:36.455 debug3: mm_request_send entering: type 22
> [preauth]
>
> 9428 2019-06-10 03:57:36.455 debug3: mm_request_receive entering
>
> 9428 2019-06-10 03:57:36.455 debug3: monitor_read: checking request 22
>
> 9428 2019-06-10 03:57:36.456 debug3: mm_answer_keyallowed entering
>
> 9428 2019-06-10 03:57:36.456 debug3: mm_answer_keyallowed:
> key_from_blob: 0000029369F0D8B0
>
> 9428 2019-06-10 03:57:36.456 debug1: trying public key file
> __PROGRAMDATA__/ssh/administrators_authorized_keys
>
> 9428 2019-06-10 03:57:36.456 debug3: Failed to open
> file:C:/ProgramData/ssh/administrators_authorized_keys error:2
>
> 9428 2019-06-10 03:57:36.456 debug1: Could not open authorized keys
> '__PROGRAMDATA__/ssh/administrators_authorized_keys': No such file or
> directory
>
> 9428 2019-06-10 03:57:36.456 debug3: mm_answer_keyallowed: publickey
> authentication test: RSA key is not allowed
>
> 9428 2019-06-10 03:57:36.456 Failed publickey for TestUser from
> 130.147.168.135 port 64534 ssh2: RSA SHA256:ospJEFHH81sy96YBMFEySGGUokk1KZHV+AbgNTFRrjE
>
> 9428 2019-06-10 03:57:36.456 debug3: mm_request_send entering: type 23
>
> 9428 2019-06-10 03:57:36.457 debug3: mm_key_allowed: waiting for
> MONITOR_ANS_KEYALLOWED [preauth]
>
> 9428 2019-06-10 03:57:36.457 debug3: mm_request_receive_expect
> entering: type 23 [preauth]
>
> 9428 2019-06-10 03:57:36.457 debug3: mm_request_receive entering
> [preauth]
>
> 9428 2019-06-10 03:57:36.457 debug2: userauth_pubkey: authenticated 0
> pkalg ssh-rsa [preauth]
>
> 9428 2019-06-10 03:57:36.457 debug3: userauth_finish: failure
> partial=0 next methods="publickey,password,keyboard-interactive"
> [preauth]
>
> 9428 2019-06-10 03:57:36.457 debug3: send packet: type 51 [preauth]
>
> 9428 2019-06-10 03:57:36.482 debug3: receive packet: type 50 [preauth]
>
> 9428 2019-06-10 03:57:36.482 debug1: userauth-request for user
> TestUser service ssh-connection method keyboard-interactive [preauth]
>
> 9428 2019-06-10 03:57:36.482 debug1: attempt 2 failures 1 [preauth]
>
> 9428 2019-06-10 03:57:36.482 debug2: input_userauth_request: try
> method keyboard-interactive [preauth]
>
> 9428 2019-06-10 03:57:36.482 debug1: keyboard-interactive devs
> [preauth]
>
> 9428 2019-06-10 03:57:36.483 debug1: auth2_challenge: user=TestUser
> devs= [preauth]
>
> 9428 2019-06-10 03:57:36.483 debug1: kbdint_alloc: devices ''
> [preauth]
>
> 9428 2019-06-10 03:57:36.483 debug2: auth2_challenge_start: devices
> [preauth]
>
> 9428 2019-06-10 03:57:36.483 debug3: userauth_finish: failure
> partial=0 next methods="publickey,password,keyboard-interactive"
> [preauth]
>
> 9428 2019-06-10 03:57:36.483 debug3: send packet: type 51 [preauth]