Quando tentei fazer a conexão com a VM deu o seguinte erro:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED21111 key sent by the remote host is
________
Please contact your system administrator.
Add correct host key in C:\\Users\\jtsm_/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in C:\\Users\\jtsm_/.ssh/known_hosts:3
Host key for 192.168.1.100 has changed and you have requested strict checking.
Host key verification failed.

Gostei MUITO desse erro, me fez pesquisar sobre algo interessante que eu nunca tinha ouvido falar. um ciberataque em que um invasor se insere na comunicação entre duas partes, interceptando e, potencialmente, alterando os dados trocados sem que nenhuma delas perceba.
https://www.kaspersky.com.br/blog/what-is-a-man-in-the-middle-attack/462/

Solução:

No cmd eu coloquei

ssh-keygen -R 192.168.1.100

que removeu a chave antiga e resolveu o problema!

Olá, Juliene, muito bom! Tenho a impressão de que no nosso dia a dia de dev (sou iniciante), isso é super comum com VMs e contêineres.
Eu mesmo gelei quando vi o aviso! rsrsrs
No meu caso foi por conta da mudança do ip da VM, mas também fui buscar informação sobre isso e diferenciar o ambiente de desenvolvimento para o de produção. Vou deixar um relato sobre o assunto:

Quando se está trabalhando localmente, talvez com VMs, Docker, ou em uma branch de desenvolvimento na nuvem que é só sua.
Como diferenciar uma invasão de uma mudança mais simples da VM: Se faça uma pergunta: "Eu acabei de fazer uma ação que justificaria isso?"

a) vagrant destroy && vagrant up? Sim.

b) Mudei a configuração de rede da VM? Sim.

c) Subi um novo contêiner no lugar do antigo? Sim.

d) Peguei um IP que meu colega estava usando 10 minutos atrás? Sim.

A "Solução" (Ação): Como você tem praticamente certeza de que a mudança foi causada por você mesmo, o risco é quase nulo.
Então, execute: ssh-keygen -R [ip_ou_host]
Reconecte e aceite a nova chave.

A solução em um ambiente de produção
Uso de Autoridades Certificadoras (CAs) de SSH. Funciona assim:

a) Não se confia em chaves individuais: Em vez de cada servidor ter sua própria chave "auto-asssinada" que seu PC precisa memorizar (o known_hosts), a empresa cria uma "Autoridade Certificadora" (CA) interna.

b) Servidores recebem Certificados: Quando um novo servidor de produção (como uma instância de auto-scaling) é criado, ele automaticamente solicita um certificado de host a essa CA interna. Esse certificado é de curta duração (ex: vale por 1 hora).

c) Clientes confiam na CA: O seu notebook de dev é configurado para confiar na CA (uma única linha no seu arquivo known_hosts), e não nas milhões de chaves de servidores individuais.

d) O Resultado Mágico: Você tenta se conectar a um servidor novo que nunca viu. Seu SSH não pergunta nada. Ele vê o certificado do servidor, checa se foi assinado pela CA confiável e te conecta.

e) O erro "REMOTE HOST IDENTIFICATION HAS CHANGED!" simplesmente deixa de existir para trocas legítimas de servidores.

Conclusão
Se uma empresa usa uma CA de SSH e mesmo assim esse erro aparece... aí sim você tem que se preocupar muito, pois pode ter 100% de certeza de que é um ataque Man-in-the-Middle, pois um servidor legítimo sempre teria um certificado válido.