Ssh client

hornetbzz · 06-25-2010, 06:44 AM

Hi to the community from a real noob

I falled in love with Linux's incredible power but facing "some" nobb's issues like this one :

Network ssh issue : :

Quote:

Machine A (subnet 2): can login ssh as client to machines B and C
Machine B (subnet 1): cannot login ssh as client to machines A and C
Machine C (subnet 1): can login ssh as client to machines A and B
OS : All machines are Nux installed (and Windows removed

).

So the point I can't resolve is how to set up machine B for being able to access as ssh client to machines A and C.

Error received from machine B trying to connect to machine C (same subnet) :

Code:

ssh -vvv admin@192.168.1.1
OpenSSH_5.1p1 Debian-5, 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 192.168.1.1 [192.168.1.1] port 22.
debug1: connect to address 192.168.1.1 port 22: Connection timed out
ssh: connect to host 192.168.1.1 port 22: Connection timed out

Process followed (According to this thread)

Including starting ssh user agent on machine B before trying to connect to machine C :

Code:

#\ ssh-agent /bin/sh
#\ ssh-add
Enter passphrase for /root/.ssh/id_rsa: 
Identity added: /root/.ssh/id_rsa (/root/.ssh/id_rsa)
Enter passphrase for /root/.ssh/id_dsa: 
Identity added: /root/.ssh/id_dsa (/root/.ssh/id_dsa)

Configuration
/etc/ssh/ssh_config (machine B)

Code:

Host *
Port 22
Protocol 2,1
PubkeyAuthentication yes
PreferredAuthentications hostbased,publickey,keyboard-interactive,password
PasswordAuthentication yes
ForwardX11 no
ServerAliveInterval 1800

Authorized_keys on machine C
MachineB: /root/.ssh/id_dsa.pub copied/paste (ctrl+Shift+C as scp is not working) to MachineC: .config/ssh/authorized_keys
As it has been done for machine A as well.

Checks, tests and assumptions :
- checked port 22 reception on machine C (tcpdump and netstat)
- purged and reinstalled openssh-client on machine B
- tried to restart the process incl key pair generation from scratch)
- trying to reconfigure ssh_config (as above).

I've done many so I'm lost now... Don't know what to do more. I guess the point is to understand the debug msg from ssh -vvv and adapt the ssh_config file but what shall I do exactly..?

kbp · 06-26-2010, 02:14 AM

Hmmm .. seems to be a lot more complicated than it needs to be, personally I'd just do it like this:

- check connectivity between all hosts
- enable and start sshd on all hosts
- run ssh-copy-id on each host to the other hosts

There shouldn't be any reason to muck about with /etc/ssh_config, it should work OOB ...

cheers

Dinithion · 06-26-2010, 03:21 AM

Some questions:

What distro are you using?
Are you able to ping the machines?
Are you able to ssh to localhost?

Andrew Benton · 06-26-2010, 06:12 AM

Quote:

Originally Posted by hornetbzz

debug1: connect to address 192.168.1.1 port 22: Connection timed out

Can you ping 192.168.1.1? It looks like a networking issue

hornetbzz · 06-26-2010, 07:37 AM

Thks for the answers.

I've checked the network connexions between machines A/B/C, which are ok at least from the ping prospective.

Distro are machine A (Ubuntu9.04), Machine B (Debian Lenny) and Machine C (Linux 2.6.24).

It's now working as I reinstalled from scratch ssh, openssh-client and opensssh-server on machine B (quite easy with a DEBIAN distro

).

Assumptions :
I don't know the reason why it was not working, I've only some assumptions in case it could be a clue for sbdy else:
Machine B was running a cronjob to backup some tarballs to machine C but I guess some code lines did corrupt the ssh daemon (due to very bad redirections),
Machine B cronjob was also trying to ssh login to machine C, which banned MachineB.

Solution applied :
Solution I followed (by memory of a love night with my network

):
- Restart sshd daemon on machines A and C
- then all actions on machine B :
- Purge and reinstall ssh, openssh-client and server
- check public key chmod (dir 600 and file 644)
- check/adapt ssh client configuration /etc/ssh/ssh_config,
- reload the new ssh configuration: /etc/init.d/ssh reload
- checked that ssh port is listening: netstat -na | grep :_port
- checked that ssh process has been started: ps -ef | grep ssh
- test ssh connexion to machines A and C: ssh -p port host
- generate a pair of dsa keys: ssh-keygen -t -dsa
- copy the public key to the ssh host machines A and C into autorized_keys
- start ssh-agent and test again ssh connection and remote copy scp

Now the point is the following (in fact this was the starting point of all the problems above...): I want to start a cronjob (scp/rsync) from machine B to machine C, but the shell is working "manually" but not as a crontask (it works but not the part with scp/rsync). Despite root is launching the cronjob and files are chmoded accordingly.

Problem summary :
a- connexion is working and effective but I get a debug msg on Machine B ssh client to connect machine C, when entering the passphrase (it works but) :

Quote:

debug3: Received SSH2_MSG_IGNORE

It looks like this is due to the client ssh_config on machine B again as I do not get this from machine A to the same machine C ssh server.

b- How to allow the cronjob to scp/rsync from machine B to machine C, as ssh-agent seems inoperant for this .. ?

Difficult ... !

Andrew Benton · 06-26-2010, 08:32 AM

Quote:

Originally Posted by hornetbzz

Now the point is the following (in fact this was the starting point of all the problems above...): I want to start a cronjob (scp/rsync) from machine B to machine C, but the shell is working "manually" but not as a crontask (it works but not the part with scp/rsync). Despite root is launching the cronjob and files are chmoded accordingly.

When you say the shell is working "manually" is that as root or a user? If it works as a user but not as root, perhaps you have (in /etc/ssh/sshd_config on C)

Code:

PermitRootLogin no

hornetbzz · 06-26-2010, 08:37 AM

Very last news :

point a: (debug3: Received SSH2_MSG_IGNORE ) is still a problem not solved. Help is welcome, thx in advance.
[EDIT1]: I found a very few informations about this "Error". The main one is that one :

Quote:

Actually OpenSSH already defends against this case: we detect when echo is turned off and send fake echo (SSH2_MSG_IGNORE) packets back in responses to keystrokes. This makes it more difficult for an attacker to tell when the user is actually typing in a password.

So it appears to me to be a kind of additional security when keyring the passphrase, which does not prevent from logging anyway, as I could experience it.

[EDIT2]: I got the point now: as I started several session as root on machine B from machine A, I guess this debug message appeared in order to prevent from potential hacking. Logged out and then back in, this warning msg disappeared.

point b: (starting scp/rsync as cronjob) looks like this problem is due to a ssh-agent limitation as described and solved in this thread so I would expect keychain to be a solution. I'll try that.
[EDIT3]: looks to work great for login, cronjob to be tested then...

hornetbzz · 06-26-2010, 08:38 AM

Thx Andy, I'll check this: machine C is a kind of special linux distro and accept only root for remote login.