1
3
I got a raspberry pi 4, I enabled SSH, and I want to connect to it via SFTP from windows (also tried from android phone and same issue). In the gif the top window is connected using SSH and i run a tail on the logs file.
In the second window I run sftp and try to login with an incorrect password the first time, and I enter the correct one on the second try. The console just remains hanging. Gif is here
tail auth.log -f
Jan 8 19:42:28 raspberrypi sshd[10184]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.2.165 user=pi
Jan 8 19:42:30 raspberrypi sshd[10184]: Failed password for pi from 192.168.2.165 port 62685 ssh2
Jan 8 19:42:33 raspberrypi sshd[10184]: Accepted password for pi from 192.168.2.165 port 62685 ssh2
Jan 8 19:42:33 raspberrypi sshd[10184]: pam_unix(sshd:session): session opened for user pi by (uid=0)
Jan 8 19:42:33 raspberrypi systemd-logind[407]: New session c100 of user pi.
Jan 8 19:42:33 raspberrypi sftp-server[10217]: session opened for local user pi from [192.168.2.165]
Jan 8 19:42:38 raspberrypi sshd[10215]: Received disconnect from 192.168.2.165 port 62685:11: disconnected by user
Jan 8 19:42:38 raspberrypi sshd[10215]: Disconnected from user pi 192.168.2.165 port 62685
Jan 8 19:42:38 raspberrypi sftp-server[10217]: session closed for local user pi from [192.168.2.165]
Jan 8 19:42:38 raspberrypi sshd[10184]: pam_unix(sshd:session): session closed for user pi
Jan 8 19:42:38 raspberrypi systemd-logind[407]: Session c100 logged out. Waiting for processes to exit.
Jan 8 19:42:38 raspberrypi systemd-logind[407]: Removed session c100.
It appears that the connection is successful but something gets stuck along the way.
Running SFTP command from inside raspberry pi seems to work. But connecting with sftp to localhost is not really useful :)
pi@raspberrypi:/etc/ssh $ sftp pi@localhost
pi@localhost's password:
Connected to pi@localhost.
sftp> exit
pi@raspberrypi:/etc/ssh $
Running sftp -vvv pi@192.168.2.196
will give the folloing output
....
pi@192.168.2.196's password:
debug3: send packet: type 50
debug2: we sent a password packet, wait for reply
debug3: receive packet: type 52
debug1: Authentication succeeded (password).
Authenticated to 192.168.2.196 ([192.168.2.196]:22).
debug2: fd 4 setting O_NONBLOCK
debug2: fd 5 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug3: send packet: type 90
debug1: Requesting no-more-sessions@openssh.com
debug3: send packet: type 80
debug1: Entering interactive session.
debug1: pledge: network
debug3: receive packet: type 80
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug3: receive packet: type 91
debug2: channel_input_open_confirmation: channel 0: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug1: Sending subsystem: sftp
debug2: channel 0: request subsystem confirm 1
debug3: send packet: type 98
debug2: channel_input_open_confirmation: channel 0: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
GETS STUCK HERE
Update
It appears to be either a network problem or a driver problem. I connected the Raspberry Pi to the 2.4Ghz instead of the 5Ghz (PC remained on 5ghz) and IT WORKED.
I also took a tcpdump -i wlan0 port 22 -n -Q inout
when it's working and when it is not, you can see it below (removed timestamps for easy diffs).
WORKING:
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 1494555936:1494556020, ack 4046582101, win 512, length 84
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [.], ack 84, win 272, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 1:29, ack 84, win 272, length 28
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 84:196, ack 29, win 512, length 112
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [.], ack 196, win 272, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 29:529, ack 196, win 272, length 500
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [.], ack 529, win 510, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 529:573, ack 196, win 272, length 44
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 196:248, ack 573, win 510, length 52
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [.], ack 248, win 272, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 248:292, ack 645, win 510, length 44
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 645:833, ack 292, win 272, length 188
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 292:336, ack 833, win 509, length 44
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 336:380, ack 833, win 509, length 44
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [.], ack 380, win 272, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 833:909, ack 380, win 272, length 76
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [.], ack 909, win 509, length 0
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 380:416, ack 909, win 509, length 36
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 909:1033, ack 416, win 272, length 124
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 416:452, ack 1033, win 508, length 36
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 452:512, ack 1033, win 508, length 60
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [.], ack 512, win 272, length 0
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [R.], seq 512, ack 1033, win 0, length 0
NOT WORKING:
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 565297912:565297996, ack 2156825212, win 512, length 84
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [.], ack 84, win 272, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 1:29, ack 84, win 272, length 28
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 84:196, ack 29, win 512, length 112
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [.], ack 196, win 272, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 29:529, ack 196, win 272, length 500
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [.], ack 529, win 510, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 529:573, ack 196, win 272, length 44
IP 192.168.2.244.64793 > 192.168.2.196.22: Flags [P.], seq 196:248, ack 573, win 510, length 52
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [.], ack 248, win 272, length 0
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
IP 192.168.2.196.22 > 192.168.2.244.64793: Flags [P.], seq 573:645, ack 248, win 272, length 72
More details:
- OS: Raspbian 10 buster (latest, just updated it)
After the authentication the sftp command starts the sftp server on the server side. I would assume that something goes wrong when starting the sftp server. Check the ssh logs on the server side. – Robert – 2020-01-08T19:29:45.947
Please do note post animated gifs. Instead post the console output in your question and format as code. – DavidPostill – 2020-01-08T19:31:12.483
@DavidPostill removed gif, but kept it as a link, it's relevant to show the corelation between the second window I think. – dburner – 2020-01-08T19:46:37.210
1It's good you posted the output of
sftp -v
where it fails. For comparisonsftp
that succeeds should also be posted with-v
. Or maybe even-vv
for both. – Kamil Maciorowski – 2020-01-08T21:36:51.027@KamilMaciorowski oh didn't knew you could do that, updated with
sftp -vvv
– dburner – 2020-01-09T00:33:25.513@Robert, well the only logs I could find is the
/var/log/auth.log
but check the update I posted a tcpdump. – dburner – 2020-01-09T17:29:31.100