Nie można włączyć SSH do wirtualnej maszyny wirtualnej

Lokalna maszyna Vagrant zainstalowana pod adresem IP 10.0.0.23z nazwą hosta lamp-vm.

Za pomocą vagrant sshpolecenia mogę się dobrze połączyć i zrobić wszystko, czego potrzebuję.

To powoduje błąd

$ ssh vagrant @ lamp-vm -v -v

debug1: podłącz do adresu 10.0.0.23 port 22: Przekroczono limit czasu połączenia
ssh: połącz z portem lamp-vm hosta 22: Przekroczono limit czasu połączenia

Mój /etc/hostsplik zawiera 10.0.0.23 lamp-vm.

Wygląda mój plik .ssh / config

Host lamp-vm
Użytkownik vagrant
IdentityFile ~ / .ssh / vagrant

Próbowałem również polecenia ssh z i bez -i /path/to/.sh/identity_file.

Jak połączyć się z moją Wirtualną maszyną wirtualną za pomocą SSH?

Też napotkałem ten problem i to była moja ostatnia konfiguracja, która pozwoliła mi ssh na moją maszynę Vagrant z dowolnego miejsca na mojej maszynie hosta.

Vagrantfile:

...
# Setting up private_network to have virtual host
config.vm.network :private_network, ip: "192.168.33.10"

# Enable ssh forward agent
config.ssh.forward_agent = true
...

ssh do maszyny:

ssh vagrant@192.168.33.10

Zostaniesz poproszony o podanie hasła (domyślnie jest błędne):

vagrant@192.168.33.28's password:

I bum, jesteś w środku!

PS * Możesz używać scp również w dowolnym miejscu na swoim hoście:

scp /path/to/src/file vagrant@192.168.33.10:/path/to/destination/file

Jest stary, ale ponieważ nie ma odpowiedzi, podam jedną. Komenda:

vagrant ssh

Jest odpowiednikiem

ssh vagrant@localhost -p 2222 -i .vagrant/machines/default/virtualbox/private_key

Jest to zachowanie domyślne, jeśli odpowiednio zmieniłeś coś, zmieniając polecenie. Przede wszystkim Vagrant stworzy włóczęgę użytkownika na twojej gościce, a ty użyjesz tego użytkownika do ssh. Jak powiedzieli poprzedni ludzie, domyślnie przekieruje ruch z portu 2222 na hoście do portu 22 na twoim gościu (domyślnie kiedy używasz włóczęgi, widzisz ten komunikat). I wreszcie Vagrant tworzy klucze do sesji ssh, więc nie musisz, więc musisz podać klucz publiczny jako argument podczas połączenia przez ssh.

To zachowanie jest zgodne z projektem.

Vagrant używa trybu NAT VirtualBox, co oznacza korzystanie z przekierowania portów.

Nie można SSH bezpośrednio na maszynę wirtualną w trybie NAT.

Użycie „vagrant ssh” oznacza, że ​​włóczęga dokona przekierowania portu, więc nie musisz się o to martwić. Myślę, że domyślnie połączy się on z hostem lokalnym na porcie 2222, ale spróbuje również rozwiązać wszelkie kolizje numerów portów.

Jeśli potrzebujesz SSH bezpośrednio na maszynę wirtualną, przełącz maszynę wirtualną w tryb sieciowy typu host lub most.

Dodałbym to jako komentarz, ale obecnie nie mam wystarczającej liczby przedstawicieli, aby to zrobić. Napisałem tutaj instrukcje dotyczące ustawiania maszyny wirtualnej do trybu pomostowego tutaj:

/ubuntu/116861/setting-up-a-network-between-a-host-and-guest-virtual-machine/116909#116909

Mam nadzieję, że uznasz to za przydatne!

Windows / Vagrant / Ubuntu

To działało dla mnie i możesz szybko dowiedzieć się, czy to zadziała, uruchamiając to na kliencie ssh.

ssh vagrant@127.0.0.1 -p 2222 -v

-V przełączy go w tryb gadatliwy i wyświetli informacje o debugowaniu ...

$ ssh vagrant@127.0.0.1 -p 2222 -v
OpenSSH_7.1p1, OpenSSL 1.0.2e 3 grudnia 2015
debug1: Podłączanie do portu
22.0.0.1 [127.0.0.1] 2222. debug1: Połączenie nawiązane.
debug1: plik tożsamości /home/Jamie/.ssh/id_rsa typ 1
debug1: key_load_public: nie ma takiego pliku lub katalogu
debug1: plik tożsamości /home/Jamie/.ssh/id_rsa-cert typ -1
debug1: key_load_public: brak takiego pliku lub
debugowanie katalogu 1: plik tożsamości / dom / Jamie /.ssh/id_dsa typ -1
debugowanie 1 : ładunek_kluczowy: brak takiego pliku lub katalog
debugowanie 1: plik tożsamości / dom / Jamie /.ssh/id_dsa-cert typ -1
debugowanie 1 : ładunek_publiczny: brak
debugowanie pliku lub katalogu 1: plik tożsamości /home/Jamie/.ssh/id_ecdsa typ -1
debug1: key_load_public: brak takiego pliku lub katalogu
debug1: plik tożsamości / dom / Jamie /.ssh/id_ecdsa-cert typ -1
debug1: klucz_ obciążenia_publiczny: brak takiego pliku lub katalogu
debug1: plik tożsamości / dom / Jamie /.ssh/id_ed25519 -1
debug1: key_load_public: brak takiego pliku lub katalogu
debugowanie 1: plik tożsamości / home /
Jamie/.ssh/id_ed25519 -cert typ -1 debug1: włączenie trybu zgodności dla protokołu 2.0
debugowanie 1: ciąg wersji lokalnej SSH-2.0-OpenSSH_7.1
debugowanie 1 : Protokół zdalny w wersji 2.0, zdalna wersja oprogramowania OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.6
debugowanie1: dopasowanie: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.6 pat OpenSSH_6.6.1 * zgodny
0x04000000 debugowanie 1: Uwierzytelnianie do wersji 127.0.0.1:2222 jako „błędnej „
debug1: SSH2_MSG_KEXINIT wysłany
Połączenie zamknięte przez 127.0.0.1

Więc ... SSH2_MSG_KEXINIT oznacza, że ​​klucze są wymieniane. To się wkrótce nie udaje ...

W takim przypadku usunąłem klucze i ponownie wygenerowałem je, robiąc to na maszynie wirtualnej. ( http://ask.xmodulo.com/sshd-error-could-not-load-host-key.html )

$ ls -al / etc / ssh / ssh key
$ sudo rm -r / etc / ssh / ssh key
$ sudo dpkg-rekonfiguracja openssh-server

Gdy moje klucze zostały zregenerowane, byłem w stanie SSH do mojej Vagrant Box.

Zniszczona maszyna wirtualna
Ponownie załadowano maszynę wirtualną
Wszystko działało

Nie jestem pewien, dlaczego, ale oczywiście coś nie ładowało się poprawnie przy pierwszym udostępnianiu.

Sprawdź ten komentarz: https://github.com/mitchellh/vagrant/issues/1936#issuecomment-21139674

Zasadniczo, nawet gdy używasz sieci prywatnej, włóczęga nadal używa ssh na 127.0.0.1. Wypróbuj to polecenie ssh @ 127.0.0.1 zamiast prywatnego adresu IP / hosta.