Okay, I've narrowed the problem down quite a bit. As previously reported, in CentOS 5.2 I get this:
$ cvs log Makefile poll: protocol failure in circuit setup cvs [log aborted]: end of file from server (consult above messages if any)
Turns out this is a problem with rsh:
$ rsh khan ls connect to address 10.24.15.48 port 544: Connection refused Trying krb4 rsh... connect to address 10.24.15.48 port 544: Connection refused trying normal rsh (/usr/bin/rsh) poll: protocol failure in circuit setup
Now, if I just reomtely login to khan (our cvs server), I get this:
[mrichter@sushi ~]$ khan connect to address 10.24.15.48 port 543: Connection refused Trying krb4 rlogin... connect to address 10.24.15.48 port 543: Connection refused trying normal rlogin (/usr/bin/rlogin) Last login: Fri Jul 4 18:19:01 from viper [mrichter@khan mrichter]$
Voila - I'm logged in.
Also, if I try an rsh from another machine (viper - FC1), I get this:
[mrichter@viper mrichter]$ rsh khan ls connect to address 10.24.15.48: Connection refused Trying krb4 rsh... connect to address 10.24.15.48: Connection refused trying normal rsh (/usr/bin/rsh) Desktop Documents Download Music Pictures Public Templates Videos bin lane608 rls_607 temp.xml
So, what is it about rsh from CentOS 5.2 such that the kerberos certification destroys its chances of success? Alternative question: what do I need to tweak to make this work?
Thanks.
mhr
PS: Google has lots of wrong answers on this, mostly really old and of no use at all.
On Mon, Jul 7, 2008 at 11:53 AM, MHR mhullrich@gmail.com wrote:
Okay, I've narrowed the problem down quite a bit. As previously reported, in CentOS 5.2 I get this:
$ cvs log Makefile poll: protocol failure in circuit setup cvs [log aborted]: end of file from server (consult above messages if any)
Turns out this is a problem with rsh:
$ rsh khan ls connect to address 10.24.15.48 port 544: Connection refused Trying krb4 rsh... connect to address 10.24.15.48 port 544: Connection refused trying normal rsh (/usr/bin/rsh) poll: protocol failure in circuit setup
Now, if I just reomtely login to khan (our cvs server), I get this:
[mrichter@sushi ~]$ khan connect to address 10.24.15.48 port 543: Connection refused Trying krb4 rlogin... connect to address 10.24.15.48 port 543: Connection refused trying normal rlogin (/usr/bin/rlogin) Last login: Fri Jul 4 18:19:01 from viper [mrichter@khan mrichter]$
Voila - I'm logged in.
Also, if I try an rsh from another machine (viper - FC1), I get this:
[mrichter@viper mrichter]$ rsh khan ls connect to address 10.24.15.48: Connection refused Trying krb4 rsh... connect to address 10.24.15.48: Connection refused trying normal rsh (/usr/bin/rsh) Desktop Documents Download Music Pictures Public Templates Videos bin lane608 rls_607 temp.xml
So, what is it about rsh from CentOS 5.2 such that the kerberos certification destroys its chances of success? Alternative question: what do I need to tweak to make this work?
Narrowed it down a bit further: I can rsh to khan directly with no command, but if I add a command, that's when the rsh fails:
[mrichter@sushi lane]$ khan connect to address 10.24.15.48 port 543: Connection refused Trying krb4 rlogin... connect to address 10.24.15.48 port 543: Connection refused trying normal rlogin (/usr/bin/rlogin) Last login: Mon Jul 7 11:59:59 from sushi [mrichter@khan mrichter]$ ls bin/ Documents/ lane608/ Pictures/ rls_607/ temp.xml Desktop/ Download/ Music@ Public/ Templates/ Videos/ [mrichter@khan mrichter]$ exit rlogin: connection closed. [mrichter@sushi lane]$ rsh khan ls connect to address 10.24.15.48 port 544: Connection refused Trying krb4 rsh... connect to address 10.24.15.48 port 544: Connection refused trying normal rsh (/usr/bin/rsh) poll: protocol failure in circuit setup [mrichter@sushi lane]$
Sushi is my CentOS 5.2 machine, khan is our CVS server running:
[mrichter@khan mrichter]$ lsb_release -a LSB Version: 1.3 Distributor ID: RedHatEnterpriseAS Description: Red Hat Enterprise Linux AS release 3 (Taroon Update 2) Release: 3 Codename: TaroonUpdate2
Any ideas?
mhr
On Mon, Jul 7, 2008 at 12:53 PM, MHR mhullrich@gmail.com wrote:
Okay, I've narrowed the problem down quite a bit. As previously reported, in CentOS 5.2 I get this:
Well whyis port 544 and 543 getting connection refused in the logs on the server? Are you using kerberos? Are the tickets you getting forwardable?
$ cvs log Makefile poll: protocol failure in circuit setup cvs [log aborted]: end of file from server (consult above messages if any)
Turns out this is a problem with rsh:
$ rsh khan ls connect to address 10.24.15.48 port 544: Connection refused Trying krb4 rsh... connect to address 10.24.15.48 port 544: Connection refused trying normal rsh (/usr/bin/rsh) poll: protocol failure in circuit setup
Now, if I just reomtely login to khan (our cvs server), I get this:
[mrichter@sushi ~]$ khan connect to address 10.24.15.48 port 543: Connection refused Trying krb4 rlogin... connect to address 10.24.15.48 port 543: Connection refused trying normal rlogin (/usr/bin/rlogin) Last login: Fri Jul 4 18:19:01 from viper [mrichter@khan mrichter]$
Voila - I'm logged in.
Also, if I try an rsh from another machine (viper - FC1), I get this:
[mrichter@viper mrichter]$ rsh khan ls connect to address 10.24.15.48: Connection refused Trying krb4 rsh... connect to address 10.24.15.48: Connection refused trying normal rsh (/usr/bin/rsh) Desktop Documents Download Music Pictures Public Templates Videos bin lane608 rls_607 temp.xml
So, what is it about rsh from CentOS 5.2 such that the kerberos certification destroys its chances of success? Alternative question: what do I need to tweak to make this work?
Thanks.
mhr
PS: Google has lots of wrong answers on this, mostly really old and of no use at all. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Mon, Jul 07, 2008 at 11:53:42AM -0700, MHR wrote:
$ rsh khan ls connect to address 10.24.15.48 port 544: Connection refused Trying krb4 rsh... connect to address 10.24.15.48 port 544: Connection refused trying normal rsh (/usr/bin/rsh) poll: protocol failure in circuit setup
This version of rsh is probably /usr/kerberos/bin/rsh (use "type rsh" or "which rsh" to verify). Try using /usr/bin/rsh instead.
(the krb5-workstation package sets this early on your PATH in /etc/profile.d/)
On Mon, Jul 7, 2008 at 12:13 PM, Stephen Harris lists@spuddy.org wrote:
On Mon, Jul 07, 2008 at 11:53:42AM -0700, MHR wrote:
This version of rsh is probably /usr/kerberos/bin/rsh (use "type rsh" or "which rsh" to verify). Try using /usr/bin/rsh instead.
(the krb5-workstation package sets this early on your PATH in /etc/profile.d/)
I wondered about that. So, per your suggestion, I modified the way my path gets set up, and here's what happened:
[mrichter@sushi lane]$ cvs diff Makefile poll: protocol failure in circuit setup cvs [diff aborted]: end of file from server (consult above messages if any)
[mrichter@sushi lane]$ rsh khan ls poll: protocol failure in circuit setup
[mrichter@sushi lane]$ which rsh ~/bin/rsh
[mrichter@sushi lane]$ ls -l ~/bin/rsh lrwxrwxrwx 1 mrichter RnD 12 Jul 7 13:14 /home/mrichter/bin/rsh -> /usr/bin/rsh*
FYI:
[mrichter@sushi ~]$ echo $PATH ::/home/mrichter/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/sbin:/usr/sbin:/usr/local/sbin:/other/mhr
[mrichter@sushi ~]$
Apparently, it is a problem with /usr/bin/rsh itself....
mhr
On Mon, Jul 07, 2008 at 01:45:25PM -0700, MHR wrote:
[mrichter@sushi lane]$ rsh khan ls poll: protocol failure in circuit setup
Are you sure there are no firewalls in place that could be blocking access? Note that "rsh machine" really calls "rlogin machine" and so talks on a different port (port 513) whereas "rsh machine command" uses port 514.
You should tcpdump the traffic while trying to do an rsh to see what is going on.
On Mon, 2008-07-07 at 16:59 -0400, Stephen Harris wrote:
On Mon, Jul 07, 2008 at 01:45:25PM -0700, MHR wrote:
[mrichter@sushi lane]$ rsh khan ls poll: protocol failure in circuit setup
Are you sure there are no firewalls in place that could be blocking access? Note that "rsh machine" really calls "rlogin machine" and so talks on a different port (port 513) whereas "rsh machine command" uses port 514.
You should tcpdump the traffic while trying to do an rsh to see what is going on.
I figure you've probably checked this already, but is rcpwrappers installed? If so, are hosts.deny and hosts.allow setup good? I suspect so - I think I saw you had some kind of successful connect earlier in the thread.
Have you run with the -d parameter?
HTH
On Mon, Jul 7, 2008 at 3:04 PM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
I figure you've probably checked this already, but is rcpwrappers installed?
No, not on either system (what is rcpwrappers?).
If so, are hosts.deny and hosts.allow setup good? I suspect so - I think I saw you had some kind of successful connect earlier in the thread.
They're fine. In fact, sushi is in khan's /etc/hosts file explicitly, and khan thinks it's on ocroads.com:
[mrichter@khan mrichter]$ hostname -f khan.ocroads.com
Have you run with the -d parameter?
Nothing new (actually, nothing at all).
?!?
mhr
On Mon, Jul 07, 2008 at 03:28:00PM -0700, MHR wrote:
On Mon, Jul 7, 2008 at 3:04 PM, William L. Maltby
If so, are hosts.deny and hosts.allow setup good? I suspect
They're fine. In fact, sushi is in khan's /etc/hosts file explicitly, and khan thinks it's on ocroads.com:
hosts.allow and hosts.deny are _different_ to /etc/hosts; they specify what machines are allowed to connect to what services. It's possible the remote server is denying access to the machine.
on 7-7-2008 3:28 PM MHR spake the following:
On Mon, Jul 7, 2008 at 3:04 PM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
I figure you've probably checked this already, but is rcpwrappers installed?
No, not on either system (what is rcpwrappers?).
tcpwrappers http://en.wikipedia.org/wiki/TCP_Wrapper
On Mon, 2008-07-07 at 15:28 -0700, MHR wrote:
On Mon, Jul 7, 2008 at 3:04 PM, William L. Maltby CentOS4Bill@triad.rr.com wrote:
I figure you've probably checked this already, but is rcpwrappers installed?
No, not on either system (what is rcpwrappers?).
A typoed tcpwrappers <*blush*>. I'm sorry for that.
If so, are hosts.deny and hosts.allow setup good? I suspect so - I think I saw you had some kind of successful connect earlier in the thread.
They're fine. In fact, sushi is in khan's /etc/hosts file explicitly, and khan thinks it's on ocroads.com:
That file is not related to tcpwrappers. The /etc/hosts.{allow,deny} are effective if tcpwrappers is in use.
# rpm -q tcp_wrappers tcp_wrappers-7.6-40.4.el5
IIRC, this is usually installed by default? It's almost become a mandatory for increased security.
But as I mentioned, I'm not sure this is needed or in use since you did have some kind of good connection.
JIC ----------------------------------------------------- # rpm -q --info tcp_wrappers <snip> Summary : A security tool which acts as a wrapper for TCP daemons. Description : The tcp_wrappers package provides small daemon programs which can monitor and filter incoming requests for systat, finger, FTP, telnet, rlogin, rsh, exec, tftp, talk and other network services.
Install the tcp_wrappers program if you need a security tool for filtering incoming network services requests. -----------------------------------------------------
Also, check out "man portmap" and "man rpcdebug". I don't know if they'll help.
Oh! IJR, do this thing after running makewhatis as root.
$ man -k rpc <snip useless stuff> portmap (8) - DARPA port to RPC program number mapper portmap (rpm) - A program which manages RPC connections. rpc (3) - library routines for remote procedure calls rpc (5) - rpc program number data base rpc.gssd [gssd] (8) - rpcsec_gss daemon rpc.idmapd [idmapd] (8) - NFSv4 ID <-> Name Mapper rpc.lockd [lockd] (8) - start kernel lockd process rpc.mountd [mountd] (8) - NFS mount daemon rpc.nfsd [nfsd] (8) - NFS server process rpc.rquotad [rquotad] (8) - remote quota server rpc.statd [statd] (8) - NSM status monitor rpc.svcgssd [svcgssd] (8) - server-side rpcsec_gss daemon rpcdebug (8) - set and clear NFS and RPC kernel debug flags rpcinfo (8) - report RPC information
I can't recall if your problem is one of those "worked on 5.1 but now..." problems. If so, maybe the prior had tcpwrappers setup and now you don't?
[mrichter@khan mrichter]$ hostname -f khan.ocroads.com
Have you run with the -d parameter?
Nothing new (actually, nothing at all).
?!?
mhr
<snip sig stuff>
BTW, IUC, there are several points at which connection can be refused. Service not running, firewall, tcpwrappers, ... that general purpose daemon that dispatches programs for remote requests like ftp, that I can't remember the name of ATM.
HTH
Update:
If I shut off the firewall on sushi (/etc/init.d/iptables stop), the rsh connections all work fine. I need to go research how to read the iptables output because right now it's greek to me - I can read the letters, but the words don't make sense.
(I'm an admitted newbie to networking details, but I seem to be getting an education in them willy nilly.... !)
Haven't gone the ssh route yet (this is all supposed to be on a secure internal network, so that shouldn't be needed, but I'll read up on it anyway 'cause it will come in handy sooner than I think - always does).
Thanks again....
mhr
On Mon, Jul 7, 2008 at 7:31 PM, MHR mhullrich@gmail.com wrote:
If I shut off the firewall on sushi (/etc/init.d/iptables stop), the rsh connections all work fine. I need to go research how to read the iptables output because right now it's greek to me - I can read the letters, but the words don't make sense.
To open those ports on the firewall, use "system-config-securitylevel-tui", then press the "Customize" button. On the list of ports add 513 and 514 to "Other ports". This should open the ports you need for rsh and rlogin (to the whole world!) in sushi. If you want a more customized firewall than this, you will either do it by hand or look at packages such as shorewall or others (I'm not familiar with them, so I wouldn't know which one to recommend).
Haven't gone the ssh route yet (this is all supposed to be on a secure internal network, so that shouldn't be needed
You should really consider moving to SSH, independently of needing encryption or not. If you really look at it, it requires less setup than rsh/rlogin does, and it's certainly easier to troubleshoot. And ssh-keygen or ssh-agent would solve your issue with typing your password repeatedly. If I were you, I would ditch rsh at once and start to look to SSH. You won't regret it.
HTH, Filipe
On Mon, Jul 7, 2008 at 1:59 PM, Stephen Harris lists@spuddy.org wrote:
On Mon, Jul 07, 2008 at 01:45:25PM -0700, MHR wrote:
Are you sure there are no firewalls in place that could be blocking access? Note that "rsh machine" really calls "rlogin machine" and so talks on a different port (port 513) whereas "rsh machine command" uses port 514.
You should tcpdump the traffic while trying to do an rsh to see what is going on.
That helps some - I got a lot of data (duh), but the key piece, I think, was this:
15:06:00.480483 IP sushi.ocroads.com.1023 > khan.sjhtca.com.shell: . ack 1 win 46 <nop,nop,timestamp 348358235 81958271> 15:06:00.480735 IP sushi.ocroads.com.1023 > khan.sjhtca.com.shell: P 1:6(5) ack 1 win 46 <nop,nop,timestamp 348358235 81958271> 15:06:00.480942 IP khan.sjhtca.com.shell > sushi.ocroads.com.1023: . ack 6 win 5792 <nop,nop,timestamp 81958271 348358235> 15:06:00.481938 IP khan.sjhtca.com.33409 > sushi.ocroads.com.auth: S 3105739037:3105739037(0) win 5840 <mss 1460,sackOK,timestamp 81958271 0,nop,wscale 0> 15:06:00.481969 IP sushi.ocroads.com > khan.sjhtca.com: ICMP host sushi.ocroads.com unreachable - admin prohibited, length 68 15:06:00.485455 IP khan.sjhtca.com.1023 > sushi.ocroads.com.1022: S 3115029742:3115029742(0) win 5840 <mss 1460,sackOK,timestamp 81958271 0,nop,wscale 0> 15:06:00.485527 IP sushi.ocroads.com > khan.sjhtca.com: ICMP host sushi.ocroads.com unreachable - admin prohibited, length 68
If I start from khan, I get this:
[mrichter@khan mrichter]$ rsh sushi ls sushi: No route to host [mrichter@khan mrichter]$ rsh sushi sushi: No route to host
What's strange (to me) about this is that I can ping and ssh to sushi from khan, and the resolv.conf on khan contains the line "search ocroads.com" which is where sushi is located (sushi = sushi.ocroads.com, khan = khan.sjhtca.com), so I'm not clear on what /else/ needs to be set for this to work.
???
Thanks to all so far....
mhr
On Mon, Jul 7, 2008 at 3:33 PM, Stephen Harris lists@spuddy.org wrote:
On Mon, Jul 07, 2008 at 03:21:04PM -0700, MHR wrote:
What's strange (to me) about this is that I can ping and ssh to sushi
*grin* switch to using ssh for your CVS connections then and bypass the whole issue. rsh is insecure, anyway!
Yeah, but there are problems with that approach. I routinely do mass cvs commands in loops, like showing all differences between my files and the repo files, and if there are a lot of them, I don't want to have to input my password 100+ times....
It works, BTW, but it's not a great solution.
Thanks.
mhr
MHR wrote:
Yeah, but there are problems with that approach. I routinely do mass cvs commands in loops, like showing all differences between my files and the repo files, and if there are a lot of them, I don't want to have to input my password 100+ times....
man ssh-keygen
On Mon, Jul 7, 2008 at 4:05 PM, John R Pierce pierce@hogranch.com wrote:
man ssh-keygen
Unfortunately, as with most man pages, this gives the technical details of how the command works, not so much how to use it in context.
However, this (http://rcsg-gsir.imsb-dsgi.nrc-cnrc.gc.ca/documents/internet/node31.html) is an excellent resource in addition - it explains the entire context of exactly what to do.
Thanks (it works).
mhr
On Mon, Jul 07, 2008 at 04:00:33PM -0700, MHR wrote:
On Mon, Jul 7, 2008 at 3:33 PM, Stephen Harris lists@spuddy.org wrote:
*grin* switch to using ssh for your CVS connections then and bypass the whole issue. rsh is insecure, anyway!
Yeah, but there are problems with that approach. I routinely do mass cvs commands in loops, like showing all differences between my files and the repo files, and if there are a lot of them, I don't want to have to input my password 100+ times....
Set it up to use public/private key authentication, use ssh-agent and you'll never need to enter your password except the once, to load it into the agent.
Or configure sshd to allow rhosts/shosts authentication (IgnoreRhosts no) on the remote server (bad idea, but no worse than rsh with rhosts files)
MHR wrote:
15:06:00.485527 IP sushi.ocroads.com > khan.sjhtca.com: ICMP host sushi.ocroads.com unreachable - admin prohibited, length 68
Is there a firewall on sushi? Run iptables -L -n on it, it seems like a firewall is blocking the connection.
If you don't have an explicit need for a firewall on sushi I'd suggest ensuring that iptables is not running /etc/init.d/iptables stop
And verify the default settings of the firewall just incase it leaves them in a reject state with the iptables -L -n command above, e.g.
# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
nate
On Mon, Jul 7, 2008 at 3:35 PM, nate centos@linuxpowered.net wrote:
Is there a firewall on sushi? Run iptables -L -n on it, it seems like a firewall is blocking the connection.
Yes:
[root@sushi mrichter]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy ACCEPT) target prot opt source destination RH-Firewall-1-INPUT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT) target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references) target prot opt source destination ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 255 ACCEPT esp -- 0.0.0.0/0 0.0.0.0/0 ACCEPT ah -- 0.0.0.0/0 0.0.0.0/0 ACCEPT udp -- 0.0.0.0/0 224.0.0.251 udp dpt:5353 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpt:631 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:631 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:23 REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited [root@sushi mrichter]#
If you don't have an explicit need for a firewall on sushi I'd suggest ensuring that iptables is not running /etc/init.d/iptables stop
I'll check on that....
And verify the default settings of the firewall just incase it leaves them in a reject state with the iptables -L -n command above, e.g.
# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination
I'm not entirely sure what all this means - pls see above. Is that what happened?
mhr
MHR wrote:
This is your problem:
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-host-prohibited
I'm not entirely sure what all this means - pls see above. Is that what happened?
If you don't need iptables then stop the service and disable it: chkconfig --level 2345 iptables off
Or you can add a rule to accept traffic for the particular port.
I don't know the specifics about adding rules to the built in firewall I've always ditched the distribution specific firewalls and built my own. I'm sure there are some docs out there somewhere though..
nate
-
Filipe Brandenburger -
John R Pierce -
MHR -
nate -
Scott Silva -
Stephen Harris -
Stephen John Smoogen -
William L. Maltby