7 added 8403 characters in body
source | link

Since some clarification questions were asked below, I think I can gather the relevant information below. Also, for completeness here: is the output that I get when I attempt to connect to the remote host from my laptop.

$ ssh -vv -p PPPPP user@xxx.yyy.zzz.www
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: /etc/ssh/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.yyy.zzz.www [xxx.yyy.zzz.www] port PPPPP.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u2
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to xxx.yyy.zzz.www:PPPPP as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:6eXFngBnUIqMlCL6WoR/miDXvVSQHjko8iPKScNMJpA
debug1: Host '[xxx.yyy.zzz.www]:PPPPP' is known and matches the ECDSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:29
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/user/.ssh/id_rsa (0x0),
debug2: key: /Users/user/.ssh/id_dsa (0x0),
debug2: key: /Users/user/.ssh/id_ecdsa (0x0),
debug2: key: /Users/user/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user/.ssh/id_rsa
debug1: Trying private key: /Users/user/.ssh/id_dsa
debug1: Trying private key: /Users/user/.ssh/id_ecdsa
debug1: Trying private key: /Users/user/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
user@xxx.yyy.zzz.www's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to xxx.yyy.zzz.www ([xxx.yyy.zzz.www]:PPPPP).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: ??? May ?? ??:??:?? 2016 from aaa.bbb.ccc.ddd
$ 
  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  5. Briefly the situation again so that we can avoid ambiguity.

    • In country A there is a raspberry pi 2 running jessie offering ssh.
    • In country B I have my lan with a laptop, a raspberry pi B running wheezy, a raspberry pi 2 running jessie, and a raspberry pi 3 also running jessie. These 4 computers are on the same lan (home) using the same router.
    • I can connect to the raspberry pi 2 in country A from my laptop as well as from raspberry pi B (which is running wheezy). I can not connect to the raspberry pi 2 in country A using either of the two remaining raspberries (the 2 and the 3 that I have, both of which are running jessie).
    • In my lan I can ssh from any computer to any other computer.
    • Actually, raspberry pi 2 in my lan (country B) is also offering an ssh service on precisely the same port as the raspberry pi 2 in country A does; I can connect to my home lan from my cell phone (of course without using the wifi).
  6.  

Since some clarification questions were asked below, I think I can gather the relevant information here:

  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  5. Briefly the situation again so that we can avoid ambiguity.

    • In country A there is a raspberry pi 2 running jessie offering ssh.
    • In country B I have my lan with a laptop, a raspberry pi B running wheezy, a raspberry pi 2 running jessie, and a raspberry pi 3 also running jessie. These 4 computers are on the same lan (home) using the same router.
    • I can connect to the raspberry pi 2 in country A from my laptop as well as from raspberry pi B (which is running wheezy). I can not connect to the raspberry pi 2 in country A using either of the two remaining raspberries (the 2 and the 3 that I have, both of which are running jessie).
    • In my lan I can ssh from any computer to any other computer.
    • Actually, raspberry pi 2 in my lan (country B) is also offering an ssh service on precisely the same port as the raspberry pi 2 in country A does; I can connect to my home lan from my cell phone (of course without using the wifi).
  6.  

Since some clarification questions were asked below, I think I can gather the relevant information below. Also, for completeness here is the output that I get when I attempt to connect to the remote host from my laptop.

$ ssh -vv -p PPPPP user@xxx.yyy.zzz.www
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 20: Applying options for *
debug1: /etc/ssh/ssh_config line 102: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.yyy.zzz.www [xxx.yyy.zzz.www] port PPPPP.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /Users/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Raspbian-5+deb8u2
debug1: match: OpenSSH_6.7p1 Raspbian-5+deb8u2 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to xxx.yyy.zzz.www:PPPPP as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-dss-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-ed25519,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm@openssh.com,hmac-ripemd160-etm@openssh.com,hmac-sha1-96-etm@openssh.com,hmac-md5-96-etm@openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:6eXFngBnUIqMlCL6WoR/miDXvVSQHjko8iPKScNMJpA
debug1: Host '[xxx.yyy.zzz.www]:PPPPP' is known and matches the ECDSA host key.
debug1: Found key in /Users/user/.ssh/known_hosts:29
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /Users/user/.ssh/id_rsa (0x0),
debug2: key: /Users/user/.ssh/id_dsa (0x0),
debug2: key: /Users/user/.ssh/id_ecdsa (0x0),
debug2: key: /Users/user/.ssh/id_ed25519 (0x0),
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/user/.ssh/id_rsa
debug1: Trying private key: /Users/user/.ssh/id_dsa
debug1: Trying private key: /Users/user/.ssh/id_ecdsa
debug1: Trying private key: /Users/user/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
user@xxx.yyy.zzz.www's password: 
debug2: we sent a password packet, wait for reply
debug1: Authentication succeeded (password).
Authenticated to xxx.yyy.zzz.www ([xxx.yyy.zzz.www]:PPPPP).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
debug2: channel 0: request env confirm 0
debug2: channel 0: request shell confirm 1
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: ??? May ?? ??:??:?? 2016 from aaa.bbb.ccc.ddd
$ 
  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  5. Briefly the situation again so that we can avoid ambiguity.

    • In country A there is a raspberry pi 2 running jessie offering ssh.
    • In country B I have my lan with a laptop, a raspberry pi B running wheezy, a raspberry pi 2 running jessie, and a raspberry pi 3 also running jessie. These 4 computers are on the same lan (home) using the same router.
    • I can connect to the raspberry pi 2 in country A from my laptop as well as from raspberry pi B (which is running wheezy). I can not connect to the raspberry pi 2 in country A using either of the two remaining raspberries (the 2 and the 3 that I have, both of which are running jessie).
    • In my lan I can ssh from any computer to any other computer.
    • Actually, raspberry pi 2 in my lan (country B) is also offering an ssh service on precisely the same port as the raspberry pi 2 in country A does; I can connect to my home lan from my cell phone (of course without using the wifi).
6 added 940 characters in body
source | link
  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  5. Briefly the situation again so that we can avoid ambiguity.

    • In country A there is a raspberry pi 2 running jessie offering ssh.
    • In country B I have my lan with a laptop, a raspberry pi B running wheezy, a raspberry pi 2 running jessie, and a raspberry pi 3 also running jessie. These 4 computers are on the same lan (home) using the same router.
    • I can connect to the raspberry pi 2 in country A from my laptop as well as from raspberry pi B (which is running wheezy). I can not connect to the raspberry pi 2 in country A using either of the two remaining raspberries (the 2 and the 3 that I have, both of which are running jessie). 
    • In my lan I can ssh from any computer to any other computer.  
    • Actually, raspberry pi 2 in my lan (country B) is also offering an ssh service on precisely the same port as the raspberry pi 2 in country A does; I can connect to my home lan from my cell phone (of course without using the wifi).
     
  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  5. Briefly the situation again so that we can avoid ambiguity.

    • In country A there is a raspberry pi 2 running jessie offering ssh.
    • In country B I have my lan with a laptop, a raspberry pi B running wheezy, a raspberry pi 2 running jessie, and a raspberry pi 3 also running jessie. These 4 computers are on the same lan (home) using the same router.
    • I can connect to the raspberry pi 2 in country A from my laptop as well as from raspberry pi B (which is running wheezy). I can not connect to the raspberry pi 2 in country A using either of the two remaining raspberries (the 2 and the 3 that I have, both of which are running jessie). In my lan I can ssh from any computer to any other computer.  
    • Actually, raspberry pi 2 in my lan (country B) is also offering an ssh service on precisely the same port as the raspberry pi 2 in country A does; I can connect to my home lan from my cell phone (of course without using the wifi).
  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  5. Briefly the situation again so that we can avoid ambiguity.

    • In country A there is a raspberry pi 2 running jessie offering ssh.
    • In country B I have my lan with a laptop, a raspberry pi B running wheezy, a raspberry pi 2 running jessie, and a raspberry pi 3 also running jessie. These 4 computers are on the same lan (home) using the same router.
    • I can connect to the raspberry pi 2 in country A from my laptop as well as from raspberry pi B (which is running wheezy). I can not connect to the raspberry pi 2 in country A using either of the two remaining raspberries (the 2 and the 3 that I have, both of which are running jessie). 
    • In my lan I can ssh from any computer to any other computer.
    • Actually, raspberry pi 2 in my lan (country B) is also offering an ssh service on precisely the same port as the raspberry pi 2 in country A does; I can connect to my home lan from my cell phone (of course without using the wifi).
     
5 added 940 characters in body
source | link
  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  5. Briefly the situation again so that we can avoid ambiguity.

    • In country A there is a raspberry pi 2 running jessie offering ssh.
    • In country B I have my lan with a laptop, a raspberry pi B running wheezy, a raspberry pi 2 running jessie, and a raspberry pi 3 also running jessie. These 4 computers are on the same lan (home) using the same router.
    • I can connect to the raspberry pi 2 in country A from my laptop as well as from raspberry pi B (which is running wheezy). I can not connect to the raspberry pi 2 in country A using either of the two remaining raspberries (the 2 and the 3 that I have, both of which are running jessie). In my lan I can ssh from any computer to any other computer.
    • Actually, raspberry pi 2 in my lan (country B) is also offering an ssh service on precisely the same port as the raspberry pi 2 in country A does; I can connect to my home lan from my cell phone (of course without using the wifi).
  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  1. All four machines described above are on the same lan. So, it can not be the case that the ISP is blocking the connection as for 2 out of 4 machines ssh works, but it does not work for the other 2.

  2. I have write permissions on all of my SD cards. In fact all of the raspberries at home have a different job to do and need to support write operations.

  3. I do not have a different router to check if something with the router is wrong. As a comment, in the lan however, I can connect with ssh from raspberry 3 to the other raspberry 2 that I have and which in theory is running the same software as the remote raspberry pi 2 that I am trying to connect to.

  4. The remote pi to which I can not connect to is in a different country and it is not easy to change ports there. The port that I am using to connect to the remote pi 2 can not be blocked by my router because I can connect from my laptop as well as from a raspberry pi B (running wheezy). All the raspberries in my lan are connected to my router using these cables: amazon.com/Cable-Matters-160021-Snagless-Ethernet/dp/B00E5I7VJG . My laptop is connected wirelessly.

  5. Briefly the situation again so that we can avoid ambiguity.

    • In country A there is a raspberry pi 2 running jessie offering ssh.
    • In country B I have my lan with a laptop, a raspberry pi B running wheezy, a raspberry pi 2 running jessie, and a raspberry pi 3 also running jessie. These 4 computers are on the same lan (home) using the same router.
    • I can connect to the raspberry pi 2 in country A from my laptop as well as from raspberry pi B (which is running wheezy). I can not connect to the raspberry pi 2 in country A using either of the two remaining raspberries (the 2 and the 3 that I have, both of which are running jessie). In my lan I can ssh from any computer to any other computer.
    • Actually, raspberry pi 2 in my lan (country B) is also offering an ssh service on precisely the same port as the raspberry pi 2 in country A does; I can connect to my home lan from my cell phone (of course without using the wifi).
4 added 471 characters in body
source | link
3 Added more information based on question asked in the comments.
source | link
2 edited tags
| link
1
source | link