23
Cisco IOS SCP Verbindung wird geschlossen
Hallo zusammen!
Erst heute habe ich festgestellt, dass mir bei aktuellem Cisco IOS scp als Übertragungsmethode angeboten wird.
Das wollte ich heute nutzen, leider funktioniert es hier nicht.
SSH geht problemlos, bei SCP wird nach Eingabe des Kennwortes die Verbindung geschlossen.
Die Optionen werden benötigt, weil der SSH-Server halt kein ecdsa und sha512 kann (IOS ist aktuell!).
Hat wer eine Idee, woran das liegen kann?
Gruß
Marco
Erst heute habe ich festgestellt, dass mir bei aktuellem Cisco IOS scp als Übertragungsmethode angeboten wird.
Das wollte ich heute nutzen, leider funktioniert es hier nicht.
SSH geht problemlos, bei SCP wird nach Eingabe des Kennwortes die Verbindung geschlossen.
scp -v -o HostKeyAlgorithms=ssh-rsa -o KexAlgorithms=diffie-hellman-group14-sha1 xxx@[xxxx1::1]:config.text ./(xxx@xxxx::1) Password:
Authenticated to xxxxx using "keyboard-interactive".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: Sending environment.
debug1: channel 0: setting env LANG = "de_DE.UTF-8"
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to xxxx::1 closed by remote host.
Transferred: sent 1568, received 1960 bytes, in 0.3 seconds
Bytes per second: sent 6245.0, received 7806.3
debug1: Exit status 0
scp: Connection closedip ssh version 2
ip scp server enable
line vty 0 4
access-class cisco-zugriff-v4 in
ipv6 access-class cisco-zugriff in
login authentication local_auth
length 0
transport input telnet sshC886VA-W-E-K9
Cisco IOS Software, C800 Software (C800-UNIVERSALK9-M), Version 15.9(3)M7, RELEASE SOFTWARE (fc2)
ROM: System Bootstrap, Version 15.1(4r)M, RELEASE SOFTWARE (fc1)
System image file is "flash:c800-universalk9-mz.SPA.159-3.M7.bin" Hat wer eine Idee, woran das liegen kann?
Gruß
Marco
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 8069935988
Url: https://administrator.de/contentid/8069935988
Ausgedruckt am: 21.11.2024 um 14:11 Uhr
23 Kommentare
Neuester Kommentar
Hast du es testweise mal andersrum versucht?
copy scp:/ /<username@Host>/config.txt flash:
Du kannst den kex Algorithmus auch in die /home/user/.ssh Datei fest mit der IP des Cisco eintragen, dann musst du es nicht immer mit eintippen. (Siehe hier)
Das “./„ am Ende ist ein Fehler das kannst du weglassen.
https://www.cisco.com/c/en/us/support/docs/security-vpn/secure-shell-ssh ...
copy scp:/ /<username@Host>/config.txt flash:
Du kannst den kex Algorithmus auch in die /home/user/.ssh Datei fest mit der IP des Cisco eintragen, dann musst du es nicht immer mit eintippen. (Siehe hier)
Das “./„ am Ende ist ein Fehler das kannst du weglassen.
https://www.cisco.com/c/en/us/support/docs/security-vpn/secure-shell-ssh ...
Umgekehrt (Router zu PC) geht es (ich musste natürlich im SSH-Server den Altkram aktivieren).
./ muss bei openssh unter Debian dran, das bedeutet, dass es in den Ordner soll, in dem ssh ausgeführt wird. Lasse ich das weg, meckert der.
Könnte es daran liegen, dass der per SSH dann erstmal im unprivilegierten Modus ist und nicht auf das Flash zugreifen darf?
Das enable-Passwort ist gesetzt.
./ muss bei openssh unter Debian dran, das bedeutet, dass es in den Ordner soll, in dem ssh ausgeführt wird. Lasse ich das weg, meckert der.
Könnte es daran liegen, dass der per SSH dann erstmal im unprivilegierten Modus ist und nicht auf das Flash zugreifen darf?
Das enable-Passwort ist gesetzt.
Hast du mal den SSH Debugger laufen lassen auf dem Cisco?
Da ist nichts für mich auffällig.
debug ip scp bringt keine Ausgabe (ich habe mal testweise debug ip ssh weggelassen).
debug ip scp bringt keine Ausgabe (ich habe mal testweise debug ip ssh weggelassen).
Aug 8 13:04:54.297: SSH2 0: authentication successful for admin1
Aug 8 13:04:54.321: SSH2 0: ssh_receive: 80 bytes received
Aug 8 13:04:54.321: SSH2 0: input: total packet length of 48 bytes
Aug 8 13:04:54.321: SSH2 0: partial packet length(block size)16 bytes,needed 32 bytes,
maclen 32
Aug 8 13:04:54.321: SSH2 0: MAC compared for #7 :ok
Aug 8 13:04:54.321: SSH2 0: input: padlength 19 bytes
Aug 8 13:04:54.321: SSH2 0: channel open request
Aug 8 13:04:54.321: SSH2 0: send:packet of length 32 (length also includes padlen of 10)
Aug 8 13:04:54.321: SSH2 0: computed MAC for sequence no.#7 type 91
Aug 8 13:04:54.345: SSH2 0: ssh_receive: 160 bytes received
Aug 8 13:04:54.345: SSH2 0: input: total packet length of 48 bytes
Aug 8 13:04:54.345: SSH2 0: partial packet length(block size)16 bytes,needed 32 bytes,
maclen 32
Aug 8 13:04:54.345: SSH2 0: MAC compared for #8 :ok
Aug 8 13:04:54.345: SSH2 0: input: padlength 7 bytes
Aug 8 13:04:54.345: SSH2 0: env request
Aug 8 13:04:54.345: SSH2 0: input: total packet length of 48 bytes
Aug 8 13:04:54.345: SSH2 0: partial packet length(block size)16 bytes,needed 32 bytes,
maclen 32
Aug 8 13:04:54.345: SSH2 0: MAC compared for #9 :ok
Aug 8 13:04:54.345: SSH2 0: input: padlength 16 bytes
Aug 8 13:04:54.345: SSH2 0: send:packet of length 16 (length also includes padlen of 6)
Aug 8 13:04:54.345: SSH2 0: computed MAC for sequence no.#8 type 99
Aug 8 13:04:54.345: SSH2 0: subsystem request
Aug 8 13:04:54.345: SSH2 0: subsystem message received
Aug 8 13:04:54.349: SSH2 0: searching for subsystem sftp for vty
Aug 8 13:04:54.449: SSH2 0: send:packet of length 48 (length also includes padlen of 18)
Aug 8 13:04:54.449: SSH2 0: computed MAC for sequence no.#9 type 98
Aug 8 13:04:54.449: SSH2 0: send:packet of length 16 (length also includes padlen of 6)
Aug 8 13:04:54.449: SSH2 0: computed MAC for sequence no.#10 type 96
Aug 8 13:04:54.449: SSH2 0: send:packet of length 16 (length also includes padlen of 6)
Aug 8 13:04:54.449: SSH2 0: computed MAC for sequence no.#11 type 97
Aug 8 13:04:54.449: SSH0: Session terminated normally
Hi Marco!
So alles einmal auf einem 880er und 1100er mit aktueller IOS Firmware getestet.
Der Testrouter hat die IP 192.168.200.1 und ist so auch in der/etc/hosts hinterlegt.
Damit man nicht immer umständlich die "-o Kexalgorithm..." Ausnahme händisch angeben muss, ist eine entsprechende config Datei unter/home/user eingerichtet:
⚠️ Wenn du hier mit sudo su arbeitest (root Privilegien) muss diese config Datei natürlich auch im Verzeichnis /root/.ssh existieren!!
SSH Zugang wurde damit vorab wasserdicht getestet:
Rennt! 👍😉
Soweit so gut... Nun die SCP Kür mit einer kleinen, lokalen test.conf Text Datei auf dem Debian Server die nur "hostname Cisco" als Inhalt hat.
Check auf dem Router:
Andersrum funktioniert es ebenso problemlos:
(Getestet auf aktuellem RaspberryPi OS und Debian Bookworm)
Works as designed!! 😉 👍
So alles einmal auf einem 880er und 1100er mit aktueller IOS Firmware getestet.
Der Testrouter hat die IP 192.168.200.1 und ist so auch in der/etc/hosts hinterlegt.
root@server:/home/user# cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 server
192.168.200.1 ciscolab Damit man nicht immer umständlich die "-o Kexalgorithm..." Ausnahme händisch angeben muss, ist eine entsprechende config Datei unter/home/user eingerichtet:
Host 192.168.200.1
KexAlgorithms +diffie-hellman-group14-sha1
User admin
Host cisco880
KexAlgorithms +diffie-hellman-group14-sha1
User admin SSH Zugang wurde damit vorab wasserdicht getestet:
root@server:/home/user# ssh cisco880
Password:
You are connected to line 10 at router cisco880-router
cisco880-router# Soweit so gut... Nun die SCP Kür mit einer kleinen, lokalen test.conf Text Datei auf dem Debian Server die nur "hostname Cisco" als Inhalt hat.
root@server:/home/user# scp test.conf admin@ciscolab:test.conf
Password:
test.conf 100% 33 0.3KB/s 00:00
Connection to ciscolab closed by remote host. Check auf dem Router:
cisco880-router#show flash:
-#- --length-- -----date/time------ path
1 97434576 Mar 29 2023 20:42:28 +02:00 c800-universalk9-mz.SPA.159-3.M7.bin
2 16093 Jul 14 2023 14:32:48 +02:00 labcfg-Jul-14-2023-14-32-48-CEST-0
3 33 Aug 21 2023 14:41:12 +02:00 test.conf
158797824 bytes available (97710080 bytes used)
cisco880-router#
cisco880-router#more flash:test.conf
hostname Cisco
cisco880-router# Andersrum funktioniert es ebenso problemlos:
cisco880-router#copy flash:test.conf scp:
Address or name of remote host []? 192.168.200.33
Destination username [admin]? user
Destination filename [test.conf]? test2.conf
Writing test2.conf
Password:
Sink: C0644 33 test2.conf
!
33 bytes copied in 6.724 secs (5 bytes/sec)
cisco880-router#
root@server:/home/user# ls -la
total 122948
drwxr-xr-x 26 user user 4096 Aug 21 15:06 .
drwxr-xr-x 2 user user 4096 Aug 21 14:21 .ssh
-rw-r--r-- 1 user user 33 Aug 21 15:06 test2.conf
-rw-r--r-- 1 root root 33 Aug 21 13:59 test.conf Works as designed!! 😉 👍
Ist ein enable-Passwort gesetzt?
Welche IOS-Version?
EDIT: Ist ja oben sichtbar, die habe ich auch.
Welche IOS-Version?
EDIT: Ist ja oben sichtbar, die habe ich auch.
Ist ein enable-Passwort gesetzt?
Hier ein Konfig Auszug:no service pad
service tcp-keepalives-in
service tcp-keepalives-out
service timestamps debug datetime localtime
service timestamps log datetime localtime show-timezone year
service password-encryption
!
hostname cisco880-router
security authentication failure rate 3 log
enable secret 9 $9$k4LQSVxHJQ1Vdo$wT12345asdrew
!
aaa new-model
!
aaa authentication login default local
aaa authentication login CONSOLE local
aaa authentication ppp L2TP_AUTH local
aaa authorization console
aaa authorization exec default local
aaa authorization exec CONSOLE local
!
clock timezone CET 1 0
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
!
no ip source-route
no ip gratuitous-arps
!
ip dhcp pool server
host 192.168.200.33 255.255.255.0
client-identifier 0100.20b6.5a92.07
!
ip domain name lab.home.arpa
ip host server.lab.home.arpa 192.168.200.33
!
login block-for 120 attempts 3 within 15
login delay 3
login quiet-mode access-class 23
login on-failure log
login on-success log
!
username admin privilege 15 secret 9 $9$LjSbvAGt123
username user privilege 3 secret 9 $9$VhUUqOJ26123
username l2tpuser privilege 0 password 7 1401qa2ws3ed
!
ip ssh time-out 60
ip ssh authentication-retries 2
ip ssh source-interface Vlan1
ip ssh version 2
ip ssh client algorithm kex diffie-hellman-group14-sha1
ip scp server enable
!
banner exec #
You are connected to line $(line) at router $(hostname)
#
!
line vty 0 4
access-class 23 in
length 0
transport input ssh Welche IOS-Version?
Siehe show flash: Output aus dem o.a. Post (File #1). 
Irgendwelchen neuen Erkentnisse?!
Ansonsten nicht vergessen deinen Thread als erledigt zu schliessen.
Ansonsten nicht vergessen deinen Thread als erledigt zu schliessen.
Leider nicht.
Ich werde aber mal einen 886va (ohne C) testen, wenn ich Zeit dazu habe.
Ich werde aber mal einen 886va (ohne C) testen, wenn ich Zeit dazu habe.
Wenn du die gleiche IOS Version hast wäre es sehr verwunderlich das es nicht geht. Das IOS kann man dann per se sicher ausschliessen in Bezug auf Bugs.
Da ist dann vermutlich doch irgendwo noch ein kleiner Konfig Kinken sei es auf Server oder Cisco Seite vorhanden?! Es bleibt also spannend...
Da ist dann vermutlich doch irgendwo noch ein kleiner Konfig Kinken sei es auf Server oder Cisco Seite vorhanden?! Es bleibt also spannend...
Was machen die SCP Forschungen??
Was mir noch einfiel zu der Thematik...
Kann es sein das du einen zu schwachen SSH Key definiert hast?? Das kann dann auch zu einem globalen SSH Fehler führen wenn du üblicherwiese SSHv2 nutzt. Im Default erzeugt der Cisco nur 512 Bit Keys was für SSHv2 nicht ausreicht. (Min. 768 Bit)
Ggf. also mit crypto key zerosize deinen alten Key löschen und mit crypto key generate rsa einen Neuen angeben mit 1024 oder 2048 Bit.
Du kannst das auch gleich in ein Kommando legen mit crypto key generate rsa modulus 1024
Was mir noch einfiel zu der Thematik...
Kann es sein das du einen zu schwachen SSH Key definiert hast?? Das kann dann auch zu einem globalen SSH Fehler führen wenn du üblicherwiese SSHv2 nutzt. Im Default erzeugt der Cisco nur 512 Bit Keys was für SSHv2 nicht ausreicht. (Min. 768 Bit)
Ggf. also mit crypto key zerosize deinen alten Key löschen und mit crypto key generate rsa einen Neuen angeben mit 1024 oder 2048 Bit.
Du kannst das auch gleich in ein Kommando legen mit crypto key generate rsa modulus 1024
Irgendwas Neues zu der Thematik. Hier rennt es immer noch fehlerlos! 😉
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Ich habe nun mit einem 886VA 15.7(3)M9 getestet, komplett frische Konfiguration, auf dem kann ich experimentieren.
Natürlich den Key (4096 Bit und 2024 Bit getestet) erstellt und dazu hostname/domain-name auf fiktive Werte gesetzt.
SSH- Login klappt per IPv4 und IPv6 (link-local), man ist dann direkt im privilegierten Modus.
scp fragt das PW ab, dann wird die Verbindung geschlossen.
aaa new-model
aaa authorization console
aaa authorization exec default local
username admin privilege 15 secret 5 xyz
ip ssh version 2SSH- Login klappt per IPv4 und IPv6 (link-local), man ist dann direkt im privilegierten Modus.
scp fragt das PW ab, dann wird die Verbindung geschlossen.
*Feb 6 07:41:42.095: SSH2 0: authentication successful for admin
*Feb 6 07:41:42.095: SSH2 : channel open request
*Feb 6 07:41:42.095: SSH2 0: env request
*Feb 6 07:41:42.099: SSH2 0: subsystem request
*Feb 6 07:41:42.099: SSH2 0: subsystem message received
*Feb 6 07:41:42.099: SSH2 0: searching for subsystem sftp for vty
*Feb 6 07:41:42.199: SSH0: Session terminated normallyAuthenticated to 10.0.0.1 ([10.0.0.1]:22) using "keyboard-interactive".
debug1: channel 0: new session [client-session] (inactive timeout: 0)
debug1: Entering interactive session.
debug1: pledge: filesystem
debug1: Sending environment.
debug1: channel 0: setting env LANG = "de_DE.UTF-8"
debug1: Sending subsystem: sftp
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: free: client-session, nchannels 1
Connection to 10.0.0.1 closed by remote host.
Transferred: sent 1880, received 2240 bytes, in 0.1 seconds
Bytes per second: sent 17334.3, received 20653.7
debug1: Exit status 0
scp: Connection closedscp fragt das PW ab, dann wird die Verbindung geschlossen.
Klappt es oder klappt es nicht? Das Feedback war jetzt etwas nichtssagend zum Status.Kopierst du etwas zum Cisco Flash oder vom Cisco Flash auf einen Server?
Ist das ein Linux? WinSCP? Bei Linux KexAlgorythms angepasst usw.? Welches Debug Kommando?
Ich kopiere zum Cisco.
Es ist unter Debian Sid openssh-client 1:9.6p1-3.
Im flash: liegt danach nix.
Es ist unter Debian Sid openssh-client 1:9.6p1-3.
Im flash: liegt danach nix.
scp -v -o kexAlgorithms=diffie-hellman-group-exchange-sha1 -o HostKeyAlgorithms=ssh-rsa test admin@10.0.0.1:test
Du hast (leider) Recht. Das ist auf einem 880er auch mit der 15.9.3M7 reproduzierbar. 
Auch eine Abänderung des Kommandos
scp test.txt admin@192.168.1.1:flash:/test.txt
Zeigt das gleiche Verhalten. Das Kommando wird ausgeführt, keine Fehlermeldung auf beiden Seiten aber die Datei landet nicht im Flash.
Interessanterweise wenn man den Kopiervorgang andersrum initiiert klappt es fehlerlos.
Auch das Schreiben von Dateien auf dem Flash zum Server klappt problemlos.
Ob das Verhalten ggf. mit einem EC generierten Key anders ist müsste man nochmal testen. Verwendet wurde ein RSA mit "crypto key generate rsa modulus 2048".
Der Test von oben lief auf einem 926 und auch 1100er mit anderem IOS Release und da klappt es fehlerlos.
cisco881#sh ver
Cisco IOS Software, C800 Software (C800-UNIVERSALK9-M), Version 15.9(3)M7, RELEASE SOFTWAREscp test.txt admin@192.168.1.1:flash:/test.txt
Zeigt das gleiche Verhalten. Das Kommando wird ausgeführt, keine Fehlermeldung auf beiden Seiten aber die Datei landet nicht im Flash.
Interessanterweise wenn man den Kopiervorgang andersrum initiiert klappt es fehlerlos.
cisco880#copy scp: flash:
Address or name of remote host []? 192.168.1.151
Source username [cisco880]? admin
Source filename []? test.txt
Destination filename [test.txt]?
Password:
scp: debug1: fd 3 clearing O_NONBLOCK
Sending file modes: C0644 18 test.txt
! scp: debug1: fd 1 clearing O_NONBLOCK
18 bytes copied in 6.584 secs (3 bytes/sec) Ob das Verhalten ggf. mit einem EC generierten Key anders ist müsste man nochmal testen. Verwendet wurde ein RSA mit "crypto key generate rsa modulus 2048".
Der Test von oben lief auf einem 926 und auch 1100er mit anderem IOS Release und da klappt es fehlerlos.
ssh ließ sich mit ec bei mir nicht aktivieren, obwohl man einen Key generieren kann.
Dafür spricht ebenfalls, dass der als Hostkey zwingend ssh-rsa will.
Dafür spricht ebenfalls, dass der als Hostkey zwingend ssh-rsa will.
Die Thematik lässt einem ja keine Ruhe und wurde mal wieder durch einen aktuellen Thread getriggert.
Man muss nur mal die AAA Doku lesen und schon ist das "Problem" gefixt! 😉
Es ist ein AAA Kommando für den externen SCP Kopiervorgang AUF das flash: Device des Ciscos erforderlich:
aaa authorization exec default local
Gibt auch ein YouTube Filmchen dazu.
In allen Setups sieht das AAA Setting jetzt so aus:
Bei den o.a. Tests mit dem 926 und dem 1100 war das konfiguriert, fehlte aber bei einem entsprechenden, identischen Test mit dem 880er und 896er was dann natürlich prompt das unterschiedliche Verhalten auslöste. 🤦♂️
Der entsprechende Filecheck auf dem Cisco Router zeigt dann:
⚠️ Wichtig ist das man zwingend die Kex Algorithmen im SSH auf dem Linux im User bezogenen .ssh Verzeichnis anpasst um SHA1-Group14 zu supporten!
Das gilt ebenso für die andere Richtung wenn man etwas VOM Cisco auf den SSH Server kopiert mit SCP. Die entsprechenden ToDos dafür stehen im Cisco Tutorial.
Fazit: Works as designed! 😉👍 (Wenn man es denn mal richtig macht... )
Man muss nur mal die AAA Doku lesen und schon ist das "Problem" gefixt! 😉
Es ist ein AAA Kommando für den externen SCP Kopiervorgang AUF das flash: Device des Ciscos erforderlich:
aaa authorization exec default local
Gibt auch ein YouTube Filmchen dazu.
In allen Setups sieht das AAA Setting jetzt so aus:
aaa authentication login default local
aaa authorization exec default local
aaa authorization network default local user@debiansrv:~# scp test.txt admin@10.99.99.1:flash:test.txt
Password:
test.txt 100% 19 0.2KB/s 00:00
Connection to 10.99.99.1 closed by remote host. Der entsprechende Filecheck auf dem Cisco Router zeigt dann:
cisco896#sh flash:
-#- --length-- -----date/time------ path
1 97206388 Mar 13 2024 15:29:24 +01:00 c800-universalk9-mz.SPA.158-3.M9.bin
2 660 Mar 11 2024 15:19:16 +01:00 vlan.dat
3 19 Mar 16 2024 12:50:32 +01:00 test.txt
152449024 bytes available (104058880 bytes used) ⚠️ Wichtig ist das man zwingend die Kex Algorithmen im SSH auf dem Linux im User bezogenen .ssh Verzeichnis anpasst um SHA1-Group14 zu supporten!
Das gilt ebenso für die andere Richtung wenn man etwas VOM Cisco auf den SSH Server kopiert mit SCP. Die entsprechenden ToDos dafür stehen im Cisco Tutorial.
Fazit: Works as designed! 😉👍 (Wenn man es denn mal richtig macht...
)
Auf dem Produktivrouter C886va (15.9(3)M7)
Die Option war bei mir bereits aktiv - geht weiterhin nicht.
router(config)#do sh run | i aaa
aaa new-model
aaa authentication login default local
aaa authorization console
aaa authorization exec default local
aaa authorization network default local
aaa session-id common
router(config)#
OK, hatte vergessen zu ergänzen das ich die Version 15.8.3M9 geflasht und gebootet hatte damit das zum zweiten getesteten 896er identisch ist wo es sofort klappte. Dessen 15.9er Train hat aktuell einen IPsec VPN Bug.
Zumindestens mit der Version klappt es auch beim 880er.
https://software.cisco.com/download/home/283775714/type/280805680/releas ...
Ansonsten schnell auf einen 896er Gig Router wechseln den es derzeit preiswert in der Bucht gibt!! 😉
Zumindestens mit der Version klappt es auch beim 880er.
https://software.cisco.com/download/home/283775714/type/280805680/releas ...
Ansonsten schnell auf einen 896er Gig Router wechseln den es derzeit preiswert in der Bucht gibt!! 😉
Finale Lösung gefunden!! 😉 👍
Wenn man einmal mit den richtigen Schlüsselbegriffen sucht, gibt es auch eine entsprechende TechNote von Cisco zu dieser Thematik:
https://www.cisco.com/c/en/us/support/docs/troubleshooting/220371-scp-fr ...
Der "-O" Parameter im Kommando nutzt mit scp das legacy SCP Protokoll für den Datei Transfer anstatt das SFTP Protokolls!
Entscheidender Hinweis war debug1: Sending subsystem: sftp wenn man das scp Kommando einmal im Verbose Mode mit -vv laufen lässt.
Der Parameter -O brachte dann den Durchbruch. 👍
Damit klappt es nun auch beim 880er bzw. allen Cisco Geräten mit dem 15.9er Image absolut fehlerfrei. Ein Downgrade bleibt dir also erspart.
Das Flash Device muss man auch nicht explizit angeben, denn der Cisco kopiert es immer per Default dahin so das ein schlichtes scp -O test.txt admin@10.99.99.1:test.txt dafür reicht.
Cisco Tutorial ist entsprechend upgedated!
Case closed...
Wenn man einmal mit den richtigen Schlüsselbegriffen sucht, gibt es auch eine entsprechende TechNote von Cisco zu dieser Thematik:
https://www.cisco.com/c/en/us/support/docs/troubleshooting/220371-scp-fr ...
Der "-O" Parameter im Kommando nutzt mit scp das legacy SCP Protokoll für den Datei Transfer anstatt das SFTP Protokolls!
Entscheidender Hinweis war debug1: Sending subsystem: sftp wenn man das scp Kommando einmal im Verbose Mode mit -vv laufen lässt.
Der Parameter -O brachte dann den Durchbruch. 👍
Damit klappt es nun auch beim 880er bzw. allen Cisco Geräten mit dem 15.9er Image absolut fehlerfrei. Ein Downgrade bleibt dir also erspart.
Das Flash Device muss man auch nicht explizit angeben, denn der Cisco kopiert es immer per Default dahin so das ein schlichtes scp -O test.txt admin@10.99.99.1:test.txt dafür reicht.
Cisco Tutorial ist entsprechend upgedated!
Case closed...
1
scp -O funktioniert bei mir.
Aus der Manpage vom openssh-client.
Bedeutet das, dass der gar kein SFTP (sondern nur SCP) kann oder dass die Implementierung hier nur fehlerhaft ist?
EDIT: Da laut deren Notiz in IOS XE kein SFTP verfügbar ist, wird es das vermutlich in niedrigeren Versionen auch nicht sein.
Fragt sich nur, warum das dann bei dir in anderen Konstellationen funktioniert hat. Welche SSH-Clients in welchen Versionen waren da in Benutzung?
Aus der Manpage vom openssh-client.
-O Verwendet das veraltete SCP-Protokoll statt des SFTP-Protokolls
zur Dateiübertragung. Für Server, die SFTP nicht implementie‐
ren, zur Rückwärtskompatibilität für bestimmte Dateinamen-
Platzhalter-Muster und zum Expandieren von Pfaden mit dem Prä‐
fix ‘~’ für ältere SFTP-Server kann das Erzwingen des SCP-Pro‐
tokolls notwendig sein.Bedeutet das, dass der gar kein SFTP (sondern nur SCP) kann oder dass die Implementierung hier nur fehlerhaft ist?
EDIT: Da laut deren Notiz in IOS XE kein SFTP verfügbar ist, wird es das vermutlich in niedrigeren Versionen auch nicht sein.
Fragt sich nur, warum das dann bei dir in anderen Konstellationen funktioniert hat. Welche SSH-Clients in welchen Versionen waren da in Benutzung?
Nach der "Background Information" zu urteilen ist das so das kein SFTP supportet ist, weil aktuellere SCP Clients wohl SFTP verwenden statt SCP legacy.
Interessant war das es einige Male bei bestimmten Endgeräten mit Debian Bullseye und Buster geklappt hatte, daher die Erfolgs "Ausreißer" oben. Warum ist mir aber schleierhaft. Mit Windows und Linux Subsystem hatte ich nicht getestet. K.A. ob Winblows SCP nativ an Bord hat. Wenn aber nutzt es ja auch OpenSSH.
Mit Bookworm ging gar nichts mehr, nicht einmal auf ein aktuelles IOS-XE. Außer natürlich man nutzt auch hier den -O Parameter. 😉
Die verwendete Version war:
OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023
Alle Infos zum Thema SSH und SCP sind im Cisco Tutorial im Kapitel SSH Zugang nochmal aktualisiert zusammengefasst.
Interessant war das es einige Male bei bestimmten Endgeräten mit Debian Bullseye und Buster geklappt hatte, daher die Erfolgs "Ausreißer" oben. Warum ist mir aber schleierhaft. Mit Windows und Linux Subsystem hatte ich nicht getestet. K.A. ob Winblows SCP nativ an Bord hat. Wenn aber nutzt es ja auch OpenSSH.
Mit Bookworm ging gar nichts mehr, nicht einmal auf ein aktuelles IOS-XE. Außer natürlich man nutzt auch hier den -O Parameter. 😉
Die verwendete Version war:
OpenSSH_9.2p1 Debian-2+deb12u2, OpenSSL 3.0.11 19 Sep 2023
Alle Infos zum Thema SSH und SCP sind im Cisco Tutorial im Kapitel SSH Zugang nochmal aktualisiert zusammengefasst.
