Как подключаться к старому ssh с Debian 10?

Question

[Талян]

У нас в конторе много свичей, которые работают по ssh1.
На компах со старым дебианом подключение вызывает вопросов.
Но у меня то Debian 10. Там ssh v2.

При подключении к хосту:

user@home:~$ ssh -vvvv 192.168.6.155
OpenSSH_7.9p1 Debian-10, OpenSSL 1.1.1c  28 May 2019
debug1: Reading configuration data /home/user/.ssh/config
debug1: /home/user/.ssh/config line 1: Applying options for *
debug3: kex names ok: [diffie-hellman-group1-sha1]
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 18: Applying options for 192.168.6.155
debug1: /etc/ssh/ssh_config line 20: Deprecated option "cipher"
debug1: /etc/ssh/ssh_config line 22: Applying options for *
debug3: kex names ok: [diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group-exchange-sha256]
debug2: resolve_canonicalize: hostname 192.168.6.155 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.6.155 [192.168.6.155] port 22.
debug1: Connection established.
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type -1
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: identity file /home/user/.ssh/id_xmss type -1
debug1: identity file /home/user/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10
debug1: Remote protocol version 2.0, remote software version DLINK Corp. SSH server ver 1.00.000
debug1: no match: DLINK Corp. SSH server ver 1.00.000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 192.168.6.155:22 as 'user'
debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts"
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[e-mail],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,diffie-hellman-group1-sha1,ext-info-c
debug2: host key algorithms: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc
debug2: MACs ctos: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],[e-mail],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[e-mail],zlib
debug2: compression stoc: none,[e-mail],zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-dss,ssh-rsa
debug2: ciphers ctos: 3des-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,aes256-cbc,aes192-cbc,aes128-cbc,arcfour,cast128-cbc
debug2: ciphers stoc: 3des-cbc,blowfish-cbc,twofish-cbc,twofish256-cbc,twofish192-cbc,twofish128-cbc,aes256-cbc,aes192-cbc,aes128-cbc,arcfour,cast128-cbc
debug2: MACs ctos: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: MACs stoc: hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96
debug2: compression ctos: none
debug2: compression stoc: none
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug1: kex: client->server cipher: aes128-cbc MAC: hmac-sha1 compression: none
debug3: send packet: type 34
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<7680<8192) sent
debug3: receive packet: type 31
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 974/2048
debug3: send packet: type 32
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug3: receive packet: type 33
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
ssh_dispatch_run_fatal: Connection to 192.168.6.155 port 22: Invalid key length

Длина ключа ему не нравится. Видите ли.
Не, ну я могу конечно поставить ssh1 и им подключаться, но это же неправильно.

Этот invalid key length меня уже достал. Я вообще чтобы время экономить подключаюсь к компу суппорта со старым дебианом, а оттуда уже под своим логином ломлюсь на свичи. Но это бред.

Гуглил этот вопрос, но не особо помогает.
Судя по логам, косяк тут:

debug2: KEX algorithms: diffie-hellman-group1-sha1,diffie-hellman-group-exchange-sha256
debug2: host key algorithms: ssh-dss,ssh-rsa

Но блин, если я добавлю строку KexAlgorithms ssh-rsa,ssh-dss в конфиг ssh, то он потом на меня ругается, что нет такого алгоритма.

Comments

[jcmvbkbc]

У нас в конторе много свичей, которые работают по ssh1.

Ты точно свой лог читал?
debug1: Remote protocol version 2.0,

[Талян]

jcmvbkbc, там следующая строка

debug1: no match: DLINK Corp. SSH server ver 1.00.000

Я уже и запутался тогда.
А чего он от меня хочет то? Вы знаете?

[jcmvbkbc]

там следующая строка

Талян, это версия ПО SSH-сервера, не версия протокола.

А чего он от меня хочет то?

непонятно. Подозреваю, что какую-нибудь хорошую комбинацию -oKexAlgorithms=... -oHostKeyAlgorithms=.... Я бы начал методом тыка с

-oKexAlgorithms=diffie-hellman-group1-sha1 -oHostKeyAlgorithms=ssh-dss

.

Answer 1

[graf_Alibert]

Хоть вопрос и старый, но для меня он актуален. Перерыв кучу форумов и статей нашел такое решение:
без установки старой версии openssh нужно добавить в конфиг следующие строчки:
#sudo nano /etc/ssh/ssh_config

Host 172.16.113.12
        PubkeyAcceptedKeyTypes +ssh-dss
        HostKeyAlgorithms=+ssh-dss
        KexAlgorithms diffie-hellman-group1-sha1
        Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc

Comments

[ThreeDHead]

Спасибо тебе мил человек, мне не хватало этой строчки: PubkeyAcceptedKeyTypes ...

Answer 2

[Руслан]

Поставьте openssh

Comments

[Талян]

поставил openssh-client1

[Руслан]

настройте его https://www.youtube.com/watch?v=zaP-NL9bR00

[Талян]

Руслан, чего мне его настраивать если он изкоробки работает как мне надо. openssh-client1 именно коннектится к ssh1

Answer 3

[Владимир Бобылев]

Если я правильно вас понимаю, у вас имеется влан управления в котором каждый коммутатор торчит интерфейсом с ip и на который вы как раз и стучитесь. В этом влане никого чужого нет. Стало быть и перехват пароля не так уж и опасен. Может проще на них использовать telnet?

Comments

[Талян]

Всё так и есть. Но есть оджно большое НО. Коммутаторов около 700 =)

Не вариант гору нести к магомеду. Вариант только магомеду идти к горе. Телнет везде отключен. Да и начальник не позволит использовать телнет вместо ssh.