Re: ssh
Francesco Pietra wrote: That's odd. I am able to get commands to work over SSH without a password. I copied the contents of ~/.ssh/id_rsa.pub on my work computer into ~/.ssh/authorized_keys on my home computer. Now I can SSH from my work computer to my home computer like this: ssh m...@myhomepc date And it logs into my home computer and then runs the date command. I did not have to do anything with the authorized_keys file on my work computer to make this happen. That's all appropriate. You only need to modify authorized_keys in both places if you want the symmetric relationship that either machine can log into the other. Correct. I mentioned that I did not have to alter the authorized_keys file on my work PC in response to the OP's statement: I know how to solve the issue, i.e. by cross appending the authorized_keys files, in order that each machine knows itself. But there must be a simpler way. I have no idea why you would need to do something like that. I have never had to "cross-append" anything in order to make this work. I just wanted to clarify for the OP that the keys only need to be shared in one direction to do this. He seems to indicate that the passwordless login works just fine unless he tries to run a command through the ssh command line. I don't know why that would make a difference. Big difference for me. As I said in my original post, certain computational parallelized codes (from major supercomputer centers, latest versions) do not work unless the two machines talking to one another also know themselves. Usually, the "two machines" are my desktop (let say deb32) and my parallel computer (let say deb64) talking to one another via a router.The only way I found (perhaps suggested by the author of the code, I don't remember) to login passwordless (my arrangement is also passfraseless) to the parallel computer - and vice versa - while requesting the date, is to take the deb32 keys from deb64 and append them to those of deb32 itself, and vice versa. I admit that most codes do not care about that, but it happens that I am using "at this very moment" a code that has such idiosyncrasy. When I said "there must be a simpler way", I meant to make that appending intrinsic in the configuration of ssh. Otherwise, I have to stay to ssh if I want (as I need) also to access supercomputers. I am surprised that others are able to login while running a command by simply sending "one-way" the keys. As I am no system expert, I assume that I am not setting up correctly ssh. regards francesco Francesco, If I understand you correctly, you are trying to ssh from your PC running 32-bit Lenny to a node in a parallel computing cluster running 64-bit Lenny. Is this correct? I'm not sure why a simple one-way shared key would not work if you are trying to run a command on the parallel computer from your PC. You shouldn't need two-way authentication unless the parallel computer needs to run something on your machine using the same tunnel. But I might be misunderstanding how you have things set up. - Dave P.S. I sent this reply back to the lists so this conversation wouldn't go completely off-list, in case someone else is interested too. -- Dave Parker Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ssh
Christopher Browne wrote: On Tue, Jan 20, 2009 at 11:06 AM, David A. Parker wrote: Is any 'send file' command to make so that two machines (an amd64 multisocket and a simple i386, both lenny) talk scp with one another through a router (attached to adsl) fully without asking the password? With 'fully' I mean that command: ssh target_machine_name date gives the date without asking a password. The mere sending id_rsa.pub to create the authorized_keys file only works (without asking the password) for command: ssh target_machine_name but if 'date' is also requested, the password is needed (at least in my hands). I know how to solve the issue, i.e. by cross appending the authorized_keys files, in order that each machine knows itself. But there must be a simpler way. That's odd. I am able to get commands to work over SSH without a password. I copied the contents of ~/.ssh/id_rsa.pub on my work computer into ~/.ssh/authorized_keys on my home computer. Now I can SSH from my work computer to my home computer like this: ssh m...@myhomepc date And it logs into my home computer and then runs the date command. I did not have to do anything with the authorized_keys file on my work computer to make this happen. That's all appropriate. You only need to modify authorized_keys in both places if you want the symmetric relationship that either machine can log into the other. Correct. I mentioned that I did not have to alter the authorized_keys file on my work PC in response to the OP's statement: >>> I know how to solve the issue, i.e. by cross appending the >>> authorized_keys files, in order that each machine knows itself. But >>> there must be a simpler way. I have no idea why you would need to do something like that. I have never had to "cross-append" anything in order to make this work. I just wanted to clarify for the OP that the keys only need to be shared in one direction to do this. He seems to indicate that the passwordless login works just fine unless he tries to run a command through the ssh command line. I don't know why that would make a difference. He also mentioned scp, and I think the better alternative would be to run sftp with a batch file. - Dave -- Dave Parker Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ssh
On Tue, Jan 20, 2009 at 11:06 AM, David A. Parker wrote: >> Is any 'send file' command to make so that two machines (an amd64 >> multisocket and a simple i386, both lenny) talk scp with one another >> through a router (attached to adsl) fully without asking the password? >> >> With 'fully' I mean that command: >> >> ssh target_machine_name date >> >> gives the date without asking a password. The mere sending id_rsa.pub >> to create the authorized_keys file only works (without asking the >> password) for command: >> >> ssh target_machine_name >> >> but if 'date' is also requested, the password is needed (at least in my >> hands). >> >> I know how to solve the issue, i.e. by cross appending the >> authorized_keys files, in order that each machine knows itself. But >> there must be a simpler way. >> > > That's odd. I am able to get commands to work over SSH without a password. > I copied the contents of ~/.ssh/id_rsa.pub on my work computer into > ~/.ssh/authorized_keys on my home computer. Now I can SSH from my work > computer to my home computer like this: > > ssh m...@myhomepc date > > And it logs into my home computer and then runs the date command. I did not > have to do anything with the authorized_keys file on my work computer to > make this happen. That's all appropriate. You only need to modify authorized_keys in both places if you want the symmetric relationship that either machine can log into the other. What's going on is that when you copy id_rsa.pub (or id_dsa.pub, or some other *.pub that might be specifically configured) from host A into ~/.ssh/authorized_keys on host B, then this authorizes connections from A to B. If you put that file into ~/.ssh/authorized_keys on host *A*, then that would enable connections from B to A. Copy the data twice, and you get two results. As for the original poster's question about "other mechanisms," it's certainly *possible* to come up with other ways to connect without using a password, but that seems likely to be somewhat risky, security-wise. The package openssh-client includes a utility called "ssh-copy-id" which provides a way to copy a key into ~/.ssh/authorized_keys a bit more easily. Typical usage would be: $ ssh-agent bash [this starts up an ssh agent, which ssh-copy-id needs in order to be able to know where to get a key to copy over...] $ ssh-add ~/.ssh/id_rsa [this tells the ssh agent about this key. This could require entering a password, depending on how the key was set up] $ ssh-copy-id some-u...@some-host Password: [You'll need to enter the password, the first time; ssh-copy-id then copies the public key into place...] After that, you'd be able to submit, without further password requests, or any further copying of ssh data... $ ssh some-u...@somehost date and get the expected result. -- http://linuxfinances.info/info/linuxdistributions.html Katharine Hepburn - "Death will be a great relief. No more interviews." -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ssh
Is any 'send file' command to make so that two machines (an amd64 multisocket and a simple i386, both lenny) talk scp with one another through a router (attached to adsl) fully without asking the password? With 'fully' I mean that command: ssh target_machine_name date gives the date without asking a password. The mere sending id_rsa.pub to create the authorized_keys file only works (without asking the password) for command: ssh target_machine_name but if 'date' is also requested, the password is needed (at least in my hands). I know how to solve the issue, i.e. by cross appending the authorized_keys files, in order that each machine knows itself. But there must be a simpler way. That's odd. I am able to get commands to work over SSH without a password. I copied the contents of ~/.ssh/id_rsa.pub on my work computer into ~/.ssh/authorized_keys on my home computer. Now I can SSH from my work computer to my home computer like this: ssh m...@myhomepc date And it logs into my home computer and then runs the date command. I did not have to do anything with the authorized_keys file on my work computer to make this happen. - Dave -- Dave Parker Utica College Integrated Information Technology Services (315) 792-3229 Registered Linux User #408177 -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ssh
Francesco Pietra writes: > ssh target_machine_name date > > gives the date without asking a password. The mere sending id_rsa.pub > to create the authorized_keys file only works (without asking the > password) for command: > > ssh target_machine_name In the case of the first command, are you running it interactively or non-interactively from, say, cron or a batch job system? If the latter is the case, you either must use passphrase-less SSH keys (insecure) or load an ssh-agent once interactively and cause all subsequent, non-interactive access to find and use that loaded agent. The keychain package might help here. OTOH, if you are indeed running the remote "date" command interactively then I have no clue Luck, -Brett. -- To UNSUBSCRIBE, email to debian-amd64-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ssh login delay
On Monday 03 October 2005 15:54, Lennart Sorensen wrote: > On Mon, Oct 03, 2005 at 12:51:56AM +0200, Gudjon I. Gudjonsson wrote: > >This is most probably not an amd64 related problem but could someone > > tell me where the delay time for the failed login in ssh is set in > > Debian. All the computers I have access to have delay but not my amd64 > > one. I have looked through the internet for 2 hours without success. > > Usually delay on connect/login is caused by not having working DNS/hosts > file to resolve the incoming IP. If DNS is working fine, it tends to be > able to quickly determine if it can or can not resolve the name of the > IP connecting. If DNS is not working, you will get a long delay while > it waits for name lookup timeout. > > Len Sorensen I don't think there is any DNS problem. ssh works perfectly on all the machines I have access to (or administrate) but one does not have any delay on password after a failed password. I would like to be able to control this parameter. Regards Gudjon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh login delay
On Mon, Oct 03, 2005 at 12:51:56AM +0200, Gudjon I. Gudjonsson wrote: >This is most probably not an amd64 related problem but could someone tell > me where the delay time for the failed login in ssh is set in Debian. All the > computers I have access to have delay but not my amd64 one. I have looked > through the internet for 2 hours without success. Usually delay on connect/login is caused by not having working DNS/hosts file to resolve the incoming IP. If DNS is working fine, it tends to be able to quickly determine if it can or can not resolve the name of the IP connecting. If DNS is not working, you will get a long delay while it waits for name lookup timeout. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh login delay
is it a pam auth issue? I don't see a pam module that controls that in my /etc/pam.d/ssh, but I'm not sure. jamie. On Mon, Oct 03, 2005 at 11:53:28AM +1000, Hamish Moffatt wrote: > On Mon, Oct 03, 2005 at 12:51:56AM +0200, Gudjon I. Gudjonsson wrote: > > Hi > >This is most probably not an amd64 related problem but could someone > > tell > > me where the delay time for the failed login in ssh is set in Debian. All > > the > > computers I have access to have delay but not my amd64 one. I have looked > > through the internet for 2 hours without success. > > Possibly /etc/login.defs. I'm not sure if that applies to ssh or not. > > Hamish > -- > Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh login delay
On Mon, Oct 03, 2005 at 12:51:56AM +0200, Gudjon I. Gudjonsson wrote: > Hi >This is most probably not an amd64 related problem but could someone tell > me where the delay time for the failed login in ssh is set in Debian. All the > computers I have access to have delay but not my amd64 one. I have looked > through the internet for 2 hours without success. Possibly /etc/login.defs. I'm not sure if that applies to ssh or not. Hamish -- Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh
On Tue, Jul 12, 2005 at 10:37:41AM +0200, Alexander Voss wrote: > Hjalmar the Destroyer wrote: > > > On Fri, Jul 08, 2005 at 12:56:35AM +0300, Modestas Vainius wrote: > >> 2005 m. Liepos 8 d., Penktadienis 00:52, Hjalmar the Destroyer ra??: > >> > OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 > >> > debug1: Reading configuration data /etc/ssh/ssh_config > >> > debug1: Connecting to computer2 [192.168.1.2] port 22. > >> > debug1: connect to address 192.168.1.2 port 22: Connection refused > >> > ssh: connect to host computer2 port 22: Connection refused > >> I guess, sshd (ssh server) is not enabled on computer2. try > >> > >> dpkg-reconfigure ssh > >> > >> and answer "Yes" to the question about the server. > >> > > Hey, > > I am still having some problems with ssh. I am running the ssh server. > > When I use nmap localhost on computer2 I get > > > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:11 > > CEST Interesting ports on localhost.localdomain (127.0.0.1): > > (The 1661 ports scanned but not shown below are in state: closed) > > PORT STATE SERVICE > > 22/tcp open ssh > > 25/tcp open smtp > > > > Nmap finished: 1 IP address (1 host up) scanned in 0.159 seconds > > > > When I run nmap from my server on computer2 I get the following > > > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:13 > > CEST All 1663 scanned ports on computer2 (192.168.1.2) are: closed > > > > Nmap finished: 1 IP address (1 host up) scanned in 0.429 seconds > > > > How can this be? Any help or tips would be greatly appreciated. > > > > > > Try "iptables -L -n". > What does it say?? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > I get the following FATAL: Module ip_tables not found. iptables v1.3.1: can't initialize iptables table filter': Table does not exist (do you need to insmod?) Perhaps iptables or your kernel needs to be upgraded. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh
Hjalmar the Destroyer wrote: > On Fri, Jul 08, 2005 at 12:56:35AM +0300, Modestas Vainius wrote: >> 2005 m. Liepos 8 d., Penktadienis 00:52, Hjalmar the Destroyer ra??: >> > OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 >> > debug1: Reading configuration data /etc/ssh/ssh_config >> > debug1: Connecting to computer2 [192.168.1.2] port 22. >> > debug1: connect to address 192.168.1.2 port 22: Connection refused >> > ssh: connect to host computer2 port 22: Connection refused >> I guess, sshd (ssh server) is not enabled on computer2. try >> >> dpkg-reconfigure ssh >> >> and answer "Yes" to the question about the server. >> > Hey, > I am still having some problems with ssh. I am running the ssh server. > When I use nmap localhost on computer2 I get > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:11 > CEST Interesting ports on localhost.localdomain (127.0.0.1): > (The 1661 ports scanned but not shown below are in state: closed) > PORT STATE SERVICE > 22/tcp open ssh > 25/tcp open smtp > > Nmap finished: 1 IP address (1 host up) scanned in 0.159 seconds > > When I run nmap from my server on computer2 I get the following > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:13 > CEST All 1663 scanned ports on computer2 (192.168.1.2) are: closed > > Nmap finished: 1 IP address (1 host up) scanned in 0.429 seconds > > How can this be? Any help or tips would be greatly appreciated. > > Try "iptables -L -n". What does it say?? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh
On Fri, Jul 08, 2005 at 12:31:04PM -0500, David Mohr wrote: > On 7/8/05, Hjalmar the Destroyer <[EMAIL PROTECTED]> wrote: > > I am still having some problems with ssh. I am running the ssh server. When > > I use nmap localhost on computer2 I get > > > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:11 > > CEST > > Interesting ports on localhost.localdomain (127.0.0.1 ): > > (The 1661 ports scanned but not shown below are in state: closed) > > PORT STATE SERVICE > > 22/tcp open ssh > > 25/tcp open smtp > > > > Nmap finished: 1 IP address (1 host up) scanned in 0.159 seconds > > > > When I run nmap from my server on computer2 I get the following > > > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:13 > > CEST > > All 1663 scanned ports on computer2 (192.168.1.2 ) are: closed > > > > Nmap finished: 1 IP address (1 host up) scanned in 0.429 seconds > > > > How can this be? Any help or tips would be greatly appreciated. > > Did you check with netstat to which addresses the smtp and ssh server > are actually bound? Do you have a firewall (ok, nmap should've noticed > that, but good to check anyways)? > > ~David > I do not have a firewall on computer2 and this is what I got after I ran netstat -n -a Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp0 0 127.0.0.1:250.0.0.0:* LISTEN tcp0 0 192.168.1.2:33535 192.168.1.1:22 ESTABLISHED udp0 0 127.0.0.1:123 0.0.0.0:* udp0 0 192.168.1.2:123 0.0.0.0:* udp0 0 0.0.0.0:123 0.0.0.0:* Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node Path unix 6 [ ] DGRAM2397 /dev/log unix 2 [ ACC ] STREAM LISTENING 2656 /tmp/.X11-unix/X0 unix 2 [ ACC ] STREAM LISTENING 2726 /tmp/ssh-VBEjMI1776/agent.1776 unix 2 [ ACC ] STREAM LISTENING 13908 /tmp/orbit-hjalmar/linc-1296-0-5b8fab5c39cd7 unix 2 [ ACC ] STREAM LISTENING 16182 /tmp/orbit-hjalmar/linc-13de-0-1fe7f0fbd2751 unix 2 [ ACC ] STREAM LISTENING 16193 /tmp/orbit-hjalmar/linc-13e0-0-44faee6dd6c75 unix 3 [ ] STREAM CONNECTED 23423/tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 23422 unix 4 [ ] STREAM CONNECTED 16458/tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 16457 unix 3 [ ] STREAM CONNECTED 16201 /tmp/orbit-hjalmar/linc-13de-0-1fe7f0fbd2751 1 unix 3 [ ] STREAM CONNECTED 16200 unix 3 [ ] STREAM CONNECTED 16199 /tmp/orbit-hjalmar/linc-13e0-0-44faee6dd6c7 5 unix 3 [ ] STREAM CONNECTED 16198 unix 3 [ ] STREAM CONNECTED 16185 /tmp/orbit-hjalmar/linc-13de-0-1fe7f0fbd275 1 unix 3 [ ] STREAM CONNECTED 16184 unix 3 [ ] STREAM CONNECTED 16181 /tmp/orbit-hjalmar/linc-1296-0-5b8fab5c39cd 7 unix 3 [ ] STREAM CONNECTED 16180 unix 3 [ ] STREAM CONNECTED 16175/tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 16174 unix 2 [ ] DGRAM13904 unix 3 [ ] STREAM CONNECTED 2750 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2749 unix 3 [ ] STREAM CONNECTED 2740 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2739 unix 3 [ ] STREAM CONNECTED 2729 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2728 unix 3 [ ] STREAM CONNECTED 2712 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTED 2658 unix 2 [ ] DGRAM2630 unix 2 [ ] DGRAM2500 unix 2 [ ] DGRAM2409 Clyde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh
On 7/8/05, Hjalmar the Destroyer <[EMAIL PROTECTED]> wrote: > I am still having some problems with ssh. I am running the ssh server. When > I use nmap localhost on computer2 I get > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:11 CEST > Interesting ports on localhost.localdomain (127.0.0.1 ): > (The 1661 ports scanned but not shown below are in state: closed) > PORT STATE SERVICE > 22/tcp open ssh > 25/tcp open smtp > > Nmap finished: 1 IP address (1 host up) scanned in 0.159 seconds > > When I run nmap from my server on computer2 I get the following > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:13 CEST > All 1663 scanned ports on computer2 (192.168.1.2 ) are: closed > > Nmap finished: 1 IP address (1 host up) scanned in 0.429 seconds > > How can this be? Any help or tips would be greatly appreciated. Did you check with netstat to which addresses the smtp and ssh server are actually bound? Do you have a firewall (ok, nmap should've noticed that, but good to check anyways)? ~David
Re: ssh
El vie, 08-07-2005 a las 19:17 +0200, Hjalmar the Destroyer escribió: > On Fri, Jul 08, 2005 at 12:56:35AM +0300, Modestas Vainius wrote: > > 2005 m. Liepos 8 d., Penktadienis 00:52, Hjalmar the Destroyer ra??: > > > OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 > > > debug1: Reading configuration data /etc/ssh/ssh_config > > > debug1: Connecting to computer2 [192.168.1.2] port 22. > > > debug1: connect to address 192.168.1.2 port 22: Connection refused > > > ssh: connect to host computer2 port 22: Connection refused > > I guess, sshd (ssh server) is not enabled on computer2. try > > > > dpkg-reconfigure ssh > > > > and answer "Yes" to the question about the server. > > > Hey, > I am still having some problems with ssh. I am running the ssh server. When > I use nmap localhost on computer2 I get > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:11 CEST > Interesting ports on localhost.localdomain (127.0.0.1): > (The 1661 ports scanned but not shown below are in state: closed) > PORT STATE SERVICE > 22/tcp open ssh > 25/tcp open smtp > > Nmap finished: 1 IP address (1 host up) scanned in 0.159 seconds > > When I run nmap from my server on computer2 I get the following > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:13 CEST > All 1663 scanned ports on computer2 (192.168.1.2) are: closed > > Nmap finished: 1 IP address (1 host up) scanned in 0.429 seconds > > How can this be? Any help or tips would be greatly appreciated. Disable the firewall, filter rules, etc. -- Javier Kohen <[EMAIL PROTECTED]> ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
Re: ssh
On Fri, Jul 08, 2005 at 12:56:35AM +0300, Modestas Vainius wrote: > 2005 m. Liepos 8 d., Penktadienis 00:52, Hjalmar the Destroyer ra??: > > OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 > > debug1: Reading configuration data /etc/ssh/ssh_config > > debug1: Connecting to computer2 [192.168.1.2] port 22. > > debug1: connect to address 192.168.1.2 port 22: Connection refused > > ssh: connect to host computer2 port 22: Connection refused > I guess, sshd (ssh server) is not enabled on computer2. try > > dpkg-reconfigure ssh > > and answer "Yes" to the question about the server. > Hey, I am still having some problems with ssh. I am running the ssh server. When I use nmap localhost on computer2 I get Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:11 CEST Interesting ports on localhost.localdomain (127.0.0.1): (The 1661 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp Nmap finished: 1 IP address (1 host up) scanned in 0.159 seconds When I run nmap from my server on computer2 I get the following Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-07-08 19:13 CEST All 1663 scanned ports on computer2 (192.168.1.2) are: closed Nmap finished: 1 IP address (1 host up) scanned in 0.429 seconds How can this be? Any help or tips would be greatly appreciated. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ssh
2005 m. Liepos 8 d., Penktadienis 00:52, Hjalmar the Destroyer rašė: > OpenSSH_3.8.1p1 Debian-8.sarge.4, OpenSSL 0.9.7e 25 Oct 2004 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: Connecting to computer2 [192.168.1.2] port 22. > debug1: connect to address 192.168.1.2 port 22: Connection refused > ssh: connect to host computer2 port 22: Connection refused I guess, sshd (ssh server) is not enabled on computer2. try dpkg-reconfigure ssh and answer "Yes" to the question about the server. pgpL0D6UrEeNF.pgp Description: PGP signature
Re: SSH package concerns...
Nathan Dragun wrote: > PasswordAuthentication is set to no by default, as enabling it causes > cleartext password authentication (obviously defeating the point of > encrypting it in the first place). No, it doesn't. It defaults to Off because Debian wants SSH to use PAM for system account authentication, and not do it itself. > And yes UsePAM = yes was set, for clarification. So I'd assume that > meant that PAM authentication was final? Nope, it's dependent on SSH configuration. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: SSH package concerns...
but sshd.conf contains the needed flags to limit the authentication methods doing man sshd_config saids something like : UsePAM = yes PasswordAuthentication = no might do the trick PasswordAuthentication is set to no by default, as enabling it causes cleartext password authentication (obviously defeating the point of encrypting it in the first place). And yes UsePAM = yes was set, for clarification. So I'd assume that meant that PAM authentication was final? Nathan Code is poetry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
This one time, at band camp, Ernest jw ter Kuile said: > On Tuesday 10 May 2005 17:46, Adam Skutt wrote: > > Pete Harlan wrote: > > > It would be nice if there were a way to have the pam module indicate, > > > "this failed, and that's final", as distinct from, "this failed so try > > > something else". > > > > There is. Mark the module "requisite", and a failure from it will stop > > the stack immediately. > > Only for pam. > > sshd is still free to try something else if pam returns a failure. > > but sshd.conf contains the needed flags to limit the authentication methods > > doing man sshd_config saids something like : > > UsePAM = yes > PasswordAuthentication = no > > might do the trick As well as PubkeyAuthentication ChallengeResponseAuthentication The various Kerberos options, and there used to be a Keyboard one, but I guess that's deprecated now. sshd supports quite a few auth mechanisms. If you want only one to be authoritative, you're going to have to actually disable the others. This is not a security flaw. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpQAcG4dIgYT.pgp Description: PGP signature
Re: SSH package concerns...
On Tuesday 10 May 2005 17:46, Adam Skutt wrote: > Pete Harlan wrote: > > It would be nice if there were a way to have the pam module indicate, > > "this failed, and that's final", as distinct from, "this failed so try > > something else". > > There is. Mark the module "requisite", and a failure from it will stop > the stack immediately. Only for pam. sshd is still free to try something else if pam returns a failure. but sshd.conf contains the needed flags to limit the authentication methods doing man sshd_config saids something like : UsePAM = yes PasswordAuthentication = no might do the trick > > Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
Pete Harlan wrote: > It would be nice if there were a way to have the pam module indicate, > "this failed, and that's final", as distinct from, "this failed so try > something else". There is. Mark the module "requisite", and a failure from it will stop the stack immediately. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
Pete Harlan wrote: > On Mon, May 09, 2005 at 10:16:24PM -0400, Adam Skutt wrote: > > He didn't say there wasn't another way to do it, he said there was a > security hole. Hence I said, don't use it. There is another way to do what he wants (more or less) that doesn't have this security hole assuming the real issue wasn't misconfiguration. Seeing as he wasn't apparently aware of the sshd configuration, I pointed it out to him, seeing as it does exactly what he wants. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
On Tue, May 10, 2005 at 11:19:15AM -0400, Lennart Sorensen wrote: > On Tue, May 10, 2005 at 10:09:59AM -0500, Pete Harlan wrote: > > On Mon, May 09, 2005 at 10:16:24PM -0400, Adam Skutt wrote: > > > Nathan Dragun wrote: > > > > While setting up PAM in conjunction with SSH I included the following > > > > line to deny access unless found in the following file: > > > > > > > > authrequiredpam_listfile.so sense=allow onerr=fail item=user > > > > file=/etc/sshloginusers > > > > > > > > Which works, sort of. > > > Don't use it. sshd(8) lets you deny and allow users via > > > /etc/ssh/sshd_config. > > > > > > Reading the daemon documentation before doing something like this is > > > always good idea. > > > > He didn't say there wasn't another way to do it, he said there was a > > security hole. > > I believe SSH supports multiple types of authentication. If pam fails, > it will use the next configured one. It's a feature of ssh. Thanks, that is helpful. > It isn't as if pam can disable ssh key logins either. Is that a > security hole? It would be nice if there were a way to have the pam module indicate, "this failed, and that's final", as distinct from, "this failed so try something else". > It still requires a valid account and password to login. True, but I imagine that if someone is using this feature then they have some accounts they trust less than others. There are various ways to go about restricting logins (including sshd's AllowUsers), but the pam method seemed reasonable to me. Particularly because with PAM you could use the same user list for any number of services, not just sshd. (And I don't understand why it would work intermittently, but that's getting far afield.) --Pete -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
On Tue, May 10, 2005 at 10:09:59AM -0500, Pete Harlan wrote: > On Mon, May 09, 2005 at 10:16:24PM -0400, Adam Skutt wrote: > > Nathan Dragun wrote: > > > While setting up PAM in conjunction with SSH I included the following > > > line to deny access unless found in the following file: > > > > > > authrequiredpam_listfile.so sense=allow onerr=fail item=user > > > file=/etc/sshloginusers > > > > > > Which works, sort of. > > Don't use it. sshd(8) lets you deny and allow users via > > /etc/ssh/sshd_config. > > > > Reading the daemon documentation before doing something like this is > > always good idea. > > He didn't say there wasn't another way to do it, he said there was a > security hole. I believe SSH supports multiple types of authentication. If pam fails, it will use the next configured one. It's a feature of ssh. It isn't as if pam can disable ssh key logins either. Is that a security hole? Misconfiguring sshd doesn't mean it is insecure. It still requires a valid account and password to login. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
On Mon, May 09, 2005 at 10:16:24PM -0400, Adam Skutt wrote: > Nathan Dragun wrote: > > While setting up PAM in conjunction with SSH I included the following > > line to deny access unless found in the following file: > > > > authrequiredpam_listfile.so sense=allow onerr=fail item=user > > file=/etc/sshloginusers > > > > Which works, sort of. > Don't use it. sshd(8) lets you deny and allow users via > /etc/ssh/sshd_config. > > Reading the daemon documentation before doing something like this is > always good idea. He didn't say there wasn't another way to do it, he said there was a security hole. --Pete -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
Nathan Dragun wrote: > While setting up PAM in conjunction with SSH I included the following > line to deny access unless found in the following file: > > authrequiredpam_listfile.so sense=allow onerr=fail item=user > file=/etc/sshloginusers > > Which works, sort of. Don't use it. sshd(8) lets you deny and allow users via /etc/ssh/sshd_config. Reading the daemon documentation before doing something like this is always good idea. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
This one time, at band camp, Nathan Dragun said: > While setting up PAM in conjunction with SSH I included the following > line to deny access unless found in the following file: > > authrequiredpam_listfile.so sense=allow onerr=fail item=user > file=/etc/sshloginusers > > Which works, sort of. > ...Lets say for examples sake the user "bob" is trying to get in, but is > not listed in this file. Ie: not authorized. If I try to connect via > the windows program PuTTY, the first attempt fails, naturally, but if I > re-type the password when prompted it will let me in!!! Not good. I > tested this several different ways and found that if I try and go from > linux box to linux box after about 4 attempts it will let me in. > > SSH package version: OpenSSH_3.8.1p1 Debian-8.sarge.4 > in conjunction with: OpenSSL 0.9.7e 25 Oct 2004 > > Now I was doing some research into this, figuring I configured something > wrong or what not early on when I first noticed this authentication > problem existed and noticed that there have been some huge changes from > the 3.8.1p1 release back in October 2004 (Ironically if I read that > right 4.0 was just released today). Changelog: > ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/ChangeLog > > But, why on earth is this package so out of date?? Insight into this > would be greatly appreciated. What you are experiencing sounds like a configuration problem to me. You presumably have multiple auth mechanisms listed besides UsePam, and eventually one succeeds, although the PAM one failed. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpRTwXLPWmrX.pgp Description: PGP signature
Re: ssh
Hello On 2005-04-27 DR GAVIN SEDDON wrote: > Is it possible to configure ssh to allow specific users to logon? See "AllowUsers" in the sshd manpage. And please try to choose a more appropriate mailing list the next time! :) bye, -christian- pgp5ra8C0xHvo.pgp Description: PGP signature
Re: ssh with konqueror (fish)
The fish problem seems to be a general KDE problem (bug 91107). The smb problem may be permissions related- it works if I launch konqueror using sudo... -Ted On Monday 15 November 2004 13:33, Theodore Kisner wrote: > I just did a dist-upgrade, and I also noticed that some of the kio-slaves > seem to be broken from konqueror (fish, smb). ftp does work... Hmmm, > maybe I'm missing something stupid... > > -Ted > > On Monday 15 November 2004 12:11, Sven Krahn wrote: > > Hi, > > > > I am trying to connect from my amd64 to an i386 Debian linux in > > Konqueror with 'fish://192.168.1.32' resulting in "An error occurred > > while loading fish://192.168.1.32: fish://192.168.1.32". Same result > > with any other destination. sshd is running on all machines. > > > > The other way (from i386 to amd64 machine) works perfectly. > > > > Are there any known issues with outgoing fish connections on amd64? Or > > am I missing something? > > > > Thanks for any feedback. > > > > -- > > Regards > > Sven
Re: ssh with konqueror (fish)
I just did a dist-upgrade, and I also noticed that some of the kio-slaves seem to be broken from konqueror (fish, smb). ftp does work... Hmmm, maybe I'm missing something stupid... -Ted On Monday 15 November 2004 12:11, Sven Krahn wrote: > Hi, > > I am trying to connect from my amd64 to an i386 Debian linux in > Konqueror with 'fish://192.168.1.32' resulting in "An error occurred > while loading fish://192.168.1.32: fish://192.168.1.32". Same result > with any other destination. sshd is running on all machines. > > The other way (from i386 to amd64 machine) works perfectly. > > Are there any known issues with outgoing fish connections on amd64? Or > am I missing something? > > Thanks for any feedback. > > -- > Regards > Sven
