scp fails on one machine, one direction?

jamesqf · December 4, 2012, 6:18am

I’m having a rather odd problem using scp. I have 3 machines in my network: a, b, and c. I’m trying to set up passwordless login/transfer between them, so am scping the id_rsa.pub files around. I can copy files back & forth between a and b with no problems. On c, I can use scp to pull a file from either machine to c. On the other machines, when I try to scp the same file TO c, it simply hangs. I have no idea why this is happening. There’s obviously a connection, and a ping to or from c works.

Any ideas?

user · December 4, 2012, 6:48am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Are they all openSUSE? 12.2? Other distros or versions?

Can you SSH (not just scp) to them all from eachother?

I presume you’re using different keys for each machine, but is hat how
things are really being done?

Don’t use ‘scp’ to copy keys. On the machine where you create your key
use the agent to load it up (of course) and then use ssh-copy-id to copy
the key to the remote boxes like this:

ssh-copy-id youruser@boxA

You’ll be prompted for a password once and then you should be able to
login normally from then on as long as your client machine has the key
loaded:

ssh youruser@boxA

The reason to use this instead of ‘scp’ is that it doesn’t make
mistakes, does good things with permissions (which, when wrong, can
prevent key-based authentication), and doesn’t overwrite
previously-written keys (in case multiple users want to login as the
same remote user).

Worst case, post the output somewhere for the following command (filling
in your user and your box, of course):

ssh -vvv youruser@brokenBox

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQvY7EAAoJEF+XTK08PnB5dOgP/iouVhyGv2KBmTlpEdEOFhj3
WaQV7bJhzf/l0SHyJ3t8bvmpCcS3/XpsbNmGlJybEhxMKNV48VJI6WAjqnPnWGTM
tNM8LbckyRzyIBPKkdbxXhXPQMsyWQyYfvfwXx/xbOt7dDP8rXvvmjPjCeMIeGaT
9WUVdUVGTBLXsGaffpSDETueJvG/wcH27WR5xwfLCzJsHVX7J2HCSo/YB3pwTgBk
ktHa8T0eXBdyk7asw3wKItuWpUvvnLv19rjFrjtEjBy7Ca+5I8NV0FCtgXH9Fm4Y
1BCDpAQLruT8SAZU6FeGvOjnTi3aiUHoWnjDiM4gIC4ZT5+E8pY0r0cJLQZbq3j1
CzjU/KGNjS5/F6qWWTVB4a4NH+J1PKl1Br/fKnGJoDMtuynWXLetxLz/TXaeIMg5
STdlQOzicnTYY+TZZenFicB95Q1g+D3AcBGJmKSPP084Uk0y2Wr8o7BgwqTUt3/+
VXBAfVGHHtUeO8eefp+e5kHo/XKy30VDU877q0njcNTShKlxz1yhRiuW8lkbbBDA
PPAbLgH5gI6aYWS+uUBUR85+xub22+tIsoGdmy4LEXno63UOcHLXoHMoWjj1irMw
rt/TYYYIG/qfGqq/Yd7kS8Bs1jQAOJ2C6frSlA6Ns0bDnQDOOKKfnXNtnCw1Px9h
OyLRSpciWNwN8Kd4z+N/
=cYFx
-----END PGP SIGNATURE-----

jamesqf · December 4, 2012, 9:18pm

All openSUSE. a is 11.0, b is 12.2, c (badbox) is 12.1.

Can you SSH (not just scp) to them all from eachother?

No, I get the same behavior as with scp. That is, I can ssh from badbox to the others, but not from the others to badbox.

I presume you’re using different keys for each machine, but is hat how
things are really being done?

Yes, but the behavior existed before I created keys on badbox, or added other machine keys to its authorized_keys file.

Don’t use ‘scp’ to copy keys.

OK, but as above, not relevant as ssh/scp should just prompt for password if no key, and instead it hangs.

Worst case, post the output somewhere for the following command (filling
in your user and your box, of course):

ssh -vvv youruser@brokenBox

From a to badbox

OpenSSH_5.0p1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to (badbox) [192.168.10.102] port 22.

It then hangs (waiting for connection?) until I kill it with ctrl-C.

Thanks,
James

user · December 4, 2012, 9:59pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Oh, well that’s straight-forward. I’d bet this is entirely a networking
problem… for example, a netmask set incorrectly (though probably not
since you can SSH from badbox to others and that’s a two-way
connection), or a firewall, or SSH just not listening/running on badbox.
Personally, since you don’t get an outright failure, I’d bet on the
firewall on badbox blocking connections.

Prove me wrong by running the following on badbox:

Code:

netstat -planet | grep :22

sudo /usr/sbin/iptables-save | grep 22

sudo /usr/sbin/tcpdump -n -s 0 port 22
#perform SSH test here from ‘a’ or ‘b’

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQvmQvAAoJEF+XTK08PnB5WVIQAMS97x481/LPIjfjSPsMnxTm
/QnO5UCZ8zMZuobqJMh+/s43eCQhoRX12xessoyBjnlbJuS86Dbtqlkl8bra6jEI
JMszWzrN44/4IEfguaCXzvcsec26QvyZryI/jvWRl/ZX6ovqZuKYduXLGPELcY3f
OtHfi0I7A0VsCoY/XhlIFLJqngl9m8j6WFGoW/uHzZtZcA00raCbAef2clc6OIJk
nmR2SV3Geb50W6yVNLyozsh/UL0OoiNJbZB//63rXP2dvqasay6DgKbfZ1yqftgl
ufS9E/o1KKK8SP0fBjl16dyPTRuTc4BaP/e7CFZwyJ4BBPBKBhIJ5qrs0/gkT3OF
K1jDED+CuxzyqN/nnNrdpdR8d4tste4Y7IrHP6k4UeWy/mrShcGm25te5Kv2W7Ck
aXCzH/Ui6y4vHmE1wvFutKrcAsTRQzzaHuxpihmmLnrcJVA2VR+mCbOQu1LUxWOT
HhxTOKgF5wXnhJIblO/pfKjGhXLLM9c8niIdBSDAx4a72hfIU3EJG1MtS1Ztb7l8
yT/fpTYygXwkLg8LMiPHIL7QAt9I3M2PmSoRFBIbYtZzUhiY1GyyknD2Ne96MJ8G
5BofF2W/br8FctB/96NBJq4m3rEkQG7Lnva6NebHWY8bUjKmVCZx0pMhJgtrmLkx
WbjllTH4lDM7RwFklXqu
=iBJA
-----END PGP SIGNATURE-----

jamesqf · December 5, 2012, 7:04am

Sure, I suspect something of the sort myself. Problem is, I don’t know enough to know how to start tracking down what exactly is the problem, or how to fix it if I did find it.

I did find that badbox had a firewall running (no idea why - I doubt I would have set it up that way. but it is an older machine). Turned it off and rebooted, and now an ssh to badbox gives me a “Connection refused” message, instead of just hanging silently.

Prove wrong by running the following on badbox:


netstat -planet | grep 22
(no output)

/usr/sbin/iptables-save | grep 22
(no output)

/usr/sbin/tcpdump  -n -s 0 port 22
21:45:05.316422 IP 192.168.10.100.27475 > 192.168.10.102.22: Flags [S], seq 1354572527, win 5840, options [mss 1460,sackOK,TS val 2073308 ecr 0,nop,wscale 7], length 0
21:45:08.311280 IP 192.168.10.100.27475 > 192.168.10.102.22: Flags [S], seq 1354572527, win 5840, options [mss 1460,sackOK,TS val 2074058 ecr 0,nop,wscale 7], length 0
21:45:14.312349 IP 192.168.10.100.27475 > 192.168.10.102.22: Flags [S], seq 1354572527, win 5840, options [mss 1460,sackOK,TS val 2075558 ecr 0,nop,wscale 7], length 0
21:45:26.311390 IP 192.168.10.100.27475 > 192.168.10.102.22: Flags [S], seq 1354572527, win 5840, options [mss 1460,sackOK,TS val 2078558 ecr 0,nop,wscale 7], length 0
^C
4 packets captured
4 packets received by filter
0 packets drpped by kernel

[/QUOTE]

user · December 5, 2012, 8:42am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Sure, I suspect something of the sort myself. Problem is, I don’t
> know enough to know how to start tracking down what exactly is the
> problem, or how to fix it if I did find it.

K, I’ll help with that easily enough.

> I did find that badbox had a firewall running (no idea why - I doubt
> I

Because it was setup correctly. Firewalls prevent things you do not
intend; that yours is misconfigured doesn’t mean it is evil. Leave it
on and allow ‘Secure Shell’ access. How do you do that? Run the following:

sudo /sbin/yast firewall
Go to Allowed Services
Choose ‘Secure Shell’ from the drop-down and click ‘Add’ to add it to
the list of allowed services.
Next/Finish/Save/whatever

> would have set it up that way. but it is an older machine). Turned
> it off and rebooted, and now an ssh to badbox gives me a “Connection
> refused” message, instead of just hanging silently.

Better; this is also what you’ll get once you go back and re-enable your
firewall but provide an exception for SSH access.

This basically means that the firewall is not blocking but that nothing
is listening. Maybe think of things this way: the firewall is the door
to your house, and your SSH service is you inside. If the firewall is
blocking access (door is closed) then there is no way anybody can talk
to you; on the other hand, now your system has the firewall down (door
open… in fact, all doors open) but nobody is inside (SSH is not
listening for a connection) so it doesn’t matter who comes around since
they cannot talk to anybody inside. Start SSH as shown below:

sudo /etc/init.d/sshd start

Test and ensure things are as you like them. Now, this is just a
one-time thing. Enable it to auto-start with the system:

sudo /sbin/chkconfig sshd on

Reboot and see that things are still okay.

Oh, and if you’d like you can do all of this (starting SSH, enabling it
to auto-start) via Yast if you’d like, probably under ‘System’ or
something. Poke around if interested once you know things are working.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQvvrPAAoJEF+XTK08PnB5FJsQAJYgyt8/kmc3b8XwRcDFfJCo
ZRH0IgCsKgJO5qCXvCIkrS7gzGThiTlQP/pmiYOU/+xZrBYld1Z0ihYP26ZaFrq3
WGt6d4l7nrb3n6RXqac4IwLn/9oLY2qml/qW3/dJtAO3EIGWQpu4Ye9RuAxZCM40
EWdiPs+bGvXe3tmVlcH65R5wrxGYToDnAtLGoAWmF072VwnLEkGA9YX+FQgfvtZI
4MBm8xhawEu/g8PexUWdTVPg5d7idI5Le64+FE/bpOLJloihGmzIxMqN0bPSBpK2
orY7u0wE2byhgOscW1P2R5pSHzg6u/x7UAw1lQ8g+7dL7a1M8aHDHge/F3/WQlhq
vGo0kbzIxseofF2DIkgPIWaF2dczOD5XzYAjprXz1kE4F1HvlHxXcxUABK2FNSWZ
tCU43MvFMDxk2ev9a0j25CNEu079YUQ4I46JJ4McABgkHoxHxbZIaMB42LcTUFKi
nqwCVVe6K4Fk/N8tjwmNObm+euH0MWbPtpp/ud76FN8Cxjz0TIp858WhyHsDYvVa
wMF5eaaY812YETt8NOCp+9dXZQm8qRbkPHxbkN23iNWJLB6KEGn153MwsuhAjYXx
P8b5cxa4kK4N1HKEKLgzu/ZXqlTsYZFB/u5n2i9dU/VR+UXF0rBWa3kZmlVw9Phv
XaGiku3xSPQ9T6QVlpw/
=dduN
-----END PGP SIGNATURE-----

jamesqf · December 5, 2012, 9:00pm

But in my setup, firewalling should be taken care of at the router, so having individual firewalls on machines seems redundant. In addition, I do quite a bit of MPI development & testing, so I don’t want extra overhead. Essentially, any of my machines should be able to do anything on any other, but nothing from the outside world (except stuff that I initiate) should pass the cable modem/firewall.

This basically means that the firewall is not blocking but that nothing
is listening. Maybe think of things this way: the firewall is the door
to your house, and your SSH service is you inside. If the firewall is
blocking access (door is closed) then there is no way anybody can talk
to you; on the other hand, now your system has the firewall down (door
open… in fact, all doors open) but nobody is inside (SSH is not
listening for a connection) so it doesn’t matter who comes around since
they cannot talk to anybody inside. Start SSH as shown below:

That did it! I wonder why, though? I did check that sshd is running on badbox (way back before I posted this), and it was. And with the firewall off, there should have been nothing blocking the port. Oh, well, I guess it’s just another of life’s little mysteries

Thanks!

user · December 6, 2012, 12:03am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> But in my setup, firewalling should be taken care of at the router,
> so having individual firewalls on machines seems redundant. In
> addition, I do quite a bit of MPI development & testing, so I don’t
> want extra overhead. Essentially, any of my machines should be able
> to do anything on any other, but nothing from the outside world
> (except stuff that I initiate) should pass the cable modem/firewall.

The principle of Defense in Depth should apply and lead to the
conclusion that firewalls only appear redundant when the inside is
viewed as secure. Do you know it is? Are you sure I’m not watching
your packets? Are you sure none of your employees have ulterior motives
causing them to try things that you may only attribute to crackers
(malicious hackers) outside your network? Are you sure somebody isn’t
accessing your network via an innocent end user who ran the wrong
program and gave them access?

Now in your home environment where nothing matters (does “nothing”
matter in your home environment?) and you’re the only user (are you?
are you sure?) and you never make mistakes (do you NEVER make mistakes?)
perhaps an all-open network is reasonable… perhaps. On the other
hand, when you go live in a real environment are you ready to lock
things down properly when you haven’t been doing so and practicing with
that setup (understanding connections, traffic requirements, firewalls
and services fully) in your test bed?

> That did it! I wonder why, though? I did check that sshd is
> running on badbox (way back before I posted this), and it was. And
> with the firewall off, there should have been nothing blocking the
> port. Oh, well, I guess it’s just another of life’s little mysteries
>

How this usually works:

Things aren’t working. Oh, no sshd process so I’ll start it. Yea, sshd
is running, but still nothing works. Maybe I’ll reboot. Okay, now
things don’t work… but here’s the firewall so I’ll turn that off.
Still things don’t work (sshd stopped when the system rebooted).
Starting sshd again… all works now.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQv9KmAAoJEF+XTK08PnB5CT0P/Aq3TzfZ/iJENow7AauBOeX3
scuWPTnZmeqXlndgdt1MzJSgJ/vYFiK+eWjdPGBAKypEPaS9WQ44kbBqnxJvWBzx
iAt6Ln7qrlU8pqlBkWC69ve9YcRpmxDWVVk5qrPFZm6xM5t4G0qdRTrfLpEzNJS6
BWNuli34WrKBJf2MNY4UNVhMYi9yjLDmmxDR66DfRlNhX1YJVNhOHik9EFPv9225
laNaL1pCPsYZLrRNiReZPELvLq4ZN5j5B8/U0Th0hbSkk/Nqdc9oJCZxV2bXkiIa
MnlvC76HX/4Oz7htrIP2qZ6UOf0ZNqVIqIp9pkZw18Azp6dJCgC7TzlTKGOubfg4
kxNLL5vBadNqA1BSFWs/gAaZvpEPdCSfAzLh4qFGgcAEYk1AEeaU7J5B9UhF26Z2
qryNlqCBBBbyAIZvoD/8ssYneU6JyiA5xm9hMck4VXufpsz6m7qbbmHq+K0Labky
momDsQYEul93Njnw+8LHt8EPHu1DBeM1A7nRLm10hH0ITrHwfSOK42CcY9JW0rFH
XRk057CcnbavasI4Yil7a583FG9vN9ZeUN6Lvr9+5B3evwU9DQMF+yq6E38IOwqw
BpdaNMwzWEdzzC4ge/gJG0u2bgyDkgZpelM8Sv7Gzqatr/XfAXXA6hDojN43kC7M
FVKQmfH51V8exeBWyaE6
=0rgI
-----END PGP SIGNATURE-----

robin_listas · December 7, 2012, 3:03am

On 2012-12-06 00:03, ab wrote:
>> But in my setup, firewalling should be taken care of at the
>> router, so having individual firewalls on machines seems
>> redundant. In addition, I do quite a bit of MPI development &
>> testing, so I don’t want extra overhead. Essentially, any of my
>> machines should be able to do anything on any other, but nothing
>> from the outside world (except stuff that I initiate) should pass
>> the cable modem/firewall.
>
> The principle of Defense in Depth should apply and lead to the
> conclusion that firewalls only appear redundant when the inside is
> viewed as secure. Do you know it is? Are you sure I’m not
> watching

Yesterday I suddenly noticed that my wifi network was down. I had a
bad feeling. I tried to log into my router, and it allowed me with the
default, factory, password. My router had reset on its own to factory
defaults, which means that it has a published login/pass pair that
everybody knows, it is documented. It even has admin ports opened to
the ISP and perhaps others. Firewall is disabled in that state, only
protection is NAT. This lasted 3 days, I think.

I did not reset my router, and there is nobody else.

So routers can silently fail and leave your machines exposed.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

user · December 7, 2012, 4:50am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sure, though every router I’ve seen, without exception, does not allow
administration via its public interface by dafault. Sure, you can
enable it, but that’s never the default. Since yours is apparently not
that way, what brand is it so that I can avoid that?

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJQwWeFAAoJEF+XTK08PnB5SHUP/3fDneNytt3+NFIHgRAojgBN
/zc1dSkw7UY8zTgUtXzVigOOUfKX0VzZIdkhMk3+2K9VM4WCarGvgAIkDjED5Tlw
ZqrcSZQ7+wLQi4pUDIbE8NO6GLN2g1qbE2h1fDDKIWeF0DH/1pgs0EHAvUWRtYyl
hB4TS3zml8K48f0/Sjfui918nV9ZrBn8VOBBLae0oD8M+db7XdLE1Bh59GyhLqPj
KH6CnLkRvT9MNhzMmnWmUCltiljlkqIYdG8C8JDke8kPaRcKT1+jV6hAv40xn6vE
S1GbJq9nHBJkd3fFNJapfV8xkMHs1OsMmDXiwiUZsEfmcFkVZekq6z217JHyEZop
vByCLi9A15ccYWy5EOCqfZLLPXJMYCHteltXJ/5xnwUSJ5aHIxk1j/0oCI9yV0RY
X/56mP2TiH3otAOVBkOhsZhU7TUCHobl7/vmticn+Aq8k1LFyFCm03f+detHjiNO
JW+vT/fBOErYFxk5eAq1lhhvq+lxLx+1akMHyO7uRrHzSZAwcOmm94VGtpg5y6gH
OaRrF4dKfLGfPmcO/x+4XyTC3vfL+q57GocOwrrZoWaPiv/jys8dp6pexTccvRO1
wARy0kv+LyJmryhHT7D9GbTwevtdPMVu/RaxMri4USMvH123FPJ4z5vrKBMP+pPm
90uJS1RI2jWonJ8jGW/l
=K+EF
-----END PGP SIGNATURE-----

robin_listas · December 7, 2012, 3:23pm

On 2012-12-07 04:50, ab wrote:
> Sure, though every router I’ve seen, without exception, does not
> allow administration via its public interface by dafault. Sure,
> you can enable it, but that’s never the default. Since yours is
> apparently not that way, what brand is it so that I can avoid
> that?

It is an ISP provided router. It is a Comtrend CT536+ with customized
defaults for Telefonica (Spain), it is not a general purpose router. I
think that most people have routers provided by their ISP.

I don’t have the default config available, but I do remember that some
incoming IP ranges belonging to my ISP data centers could enter my
router and change things. I do not know if they ever have done that,
but I disable that entry. I’ll have to check it again to see if I
forgot entries.

These addresses have access:



Access Control -- IP Address

The IP Address Access Control mode, if enabled, permits access to
local management services from IP addresses contained in the Access
Control List. If the Access Control mode is disabled, the system will
not validate IP addresses for incoming packets. The services are the
system applications listed in the Service Control List

Enabled.

IP Address      Subnet Mask      Interface 	Remove
172.20.25.0     255.255.255.0    wan
172.20.45.0     255.255.255.0    wan
193.152.37.192  255.255.255.240  wan
0.0.0.0         0.0.0.0          lan
80.58.63.128    255.255.255.128  wan

But all ports are closed from outside except ping:


Services 	LAN 	WAN
FTP       Enable      Enable
HTTP      Enable      Enable
ICMP      Enable      Enable
SNMP      Enable      Enable
SSH       Enable      Enable
TELNET    Enable      Enable
TFTP      Enable      Enable

I’m going to disable those public IP (193… and 80…). Done.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

robin_listas · December 7, 2012, 8:38pm

On 2012-12-07 15:23, Carlos E. R. wrote:
> On 2012-12-07 04:50, ab wrote:
>> Sure, though every router I’ve seen, without exception, does not
>> allow administration via its public interface by dafault. Sure,
>> you can enable it, but that’s never the default. Since yours is
>> apparently not that way, what brand is it so that I can avoid
>> that?
>
> It is an ISP provided router. It is a Comtrend CT536+ with customized
> defaults for Telefonica (Spain), it is not a general purpose router. I
> think that most people have routers provided by their ISP.

Looking again at the configuration file I see something that is not
available via the http configuration interface: there are two hidden
passwords for a user called “support” and another called “user”. What is
not defined is their login names.

If these two login work remotely, that could be it.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)