Re: ssh doesn't work.

[Richard Hector]

On 10/12/16 22:01, Joe wrote:
> On Sat, 10 Dec 2016 13:54:56 +0900
> EenyMeenyMinyMoa  wrote:
> 
> 
>> I see.
>> I thought the meaning of "bugger" as "wreck".
> 
> 
> Pretty much any rude word, together with 'all', means 'nothing' in an
> emphatic but not polite way, as in 'sod all' and  'f*** all'.
> 

I'd interpret or use it as "almost nothing", but otherwise yeah. There's
bugger all difference, but it might be significant sometimes :-)

Richard




signature.asc
Description: OpenPGP digital signature

Re: ssh doesn't work.

[Joe]

On Sat, 10 Dec 2016 13:54:56 +0900
EenyMeenyMinyMoa  wrote:


> I see.
> I thought the meaning of "bugger" as "wreck".


Pretty much any rude word, together with 'all', means 'nothing' in an
emphatic but not polite way, as in 'sod all' and  'f*** all'.

-- 
Joe

Re: ssh doesn't work.

[EenyMeenyMinyMoa]

2016-12-08 19:04 GMT+09:00 Lisi Reisz :
> On Thursday 08 December 2016 04:19:00 EenyMeenyMinyMoa wrote:
>> Hi,
>>
>> 2016-12-08 5:25 GMT+09:00 Brian :
>>> Random script kiddy attacks are of absolutely no consequence. Annoying
>>> perhaps, but no threat whatsoever. In terms of security, changing the
>>> port number for ssh does bugger all.
>>
>> What security risk can changing the port number for ssh cause?
>
> If it does bugger all, it isn't a security risk either.  "Does bugger all"
> means that it doesn't do anything whatsoever, so I take it to mean
(possibly
> erroneously) that: changing the port number does not create a security
risk,
> but neither does it improve security.  It just introduces unnecessary
further
> complication.

I see.
I thought the meaning of "bugger" as "wreck".
There are one word of which I couldn't get the meaning in the last email of
Henning. But I'll put it aside.

For safer security(at least I guess), I changed the permissions of
  authorized_keys
  id_rsa_for_test.pub
  known_hosts
into 600.
This time in the manner:
  one change, test, succeed, and then next...
I could also login by ssh without password.

Cheers,
EenyMeenyMinyMoa

Re: ssh doesn't work.

[Reco]

Hi.

On Thu, 8 Dec 2016 15:37:45 +
Darac Marjal  wrote:

> On Thu, Dec 08, 2016 at 01:18:38AM +0300, Reco wrote:
> >On Wed, 7 Dec 2016 15:54:46 -0500
> >Henning Follmann  wrote:
> >
> >> On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
> >> >  Hi.
> >> >
> >> > On Wed, 7 Dec 2016 21:14:51 +0200
> >> > Antti Talsta  wrote:
> >> >
> >> > > On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> >> > >
> >> > > > Changing the port at least decreases the number of brute force 
> >> > > > attacks
> >> > > > against you, which saves resources (bandwidth, CPU) that are 
> >> > > > otherwise
> >> > > > wasted by the attackers.
> >> > >
> >> > > How about fail2ban for that?
> >> >
> >> > How fail2ban can help against an army of bots trying one single
> >> > password per bot?
> >> >
> >> That actually works well. Usually it's multiple attempts from one ip.
> >> fail2ban catches exactly that. And then blacklists that ip.
> >
> >Probably it is so. It's been awhile since I ran publicly accessible
> >sshd on port 22 with password authentication enabled.
> >
> >Personally I prefer a bunch of simple iptables rules to fail2ban
> >though. After all, why bother running a userspace tool, if you can
> >force the kernel itself to do the job?
> 
> Could you share with the group what "simple iptables rules" you use? I 
> presume that iptables, by itself, can't replicate the idea of "block 
> after X failures in Y minutes", but presumably you're using some kind of 
> rate limiting, instead?

Sure. It's in archives somewhere already, but:

iptables -A INPUT -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW \
-m hashlimit --hashlimit-upto 1/hour --hashlimit-burst 8 \
--hashlimit-mode srcip --hashlimit-name ssh \
--hashlimit-htable-expire 65536 -m comment --comment "HTTPS Blocker" \
 -j ACCEPT

iptables -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN \
-m comment --comment "HTTPS Blocker" -j DROP

Back in the day I was not that lazy for building kernel modules I used
TARPIT instead of DROP.


PS From the previous discussion of this very topic I was pointed that
such iptables configuration is unsuitable for certain 'Modern Desktop
Environment'. Therefore this iptables configuration should be used on
'understand what I'm doing' basis.

Reco

Re: ssh doesn't work.

[Darac Marjal]

On Thu, Dec 08, 2016 at 01:18:38AM +0300, Reco wrote:

On Wed, 7 Dec 2016 15:54:46 -0500
Henning Follmann  wrote:


On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
>Hi.
>
> On Wed, 7 Dec 2016 21:14:51 +0200
> Antti Talsta  wrote:
>
> > On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> >
> > > Changing the port at least decreases the number of brute force attacks
> > > against you, which saves resources (bandwidth, CPU) that are otherwise
> > > wasted by the attackers.
> >
> > How about fail2ban for that?
>
> How fail2ban can help against an army of bots trying one single
> password per bot?
>
That actually works well. Usually it's multiple attempts from one ip.
fail2ban catches exactly that. And then blacklists that ip.


Probably it is so. It's been awhile since I ran publicly accessible
sshd on port 22 with password authentication enabled.

Personally I prefer a bunch of simple iptables rules to fail2ban
though. After all, why bother running a userspace tool, if you can
force the kernel itself to do the job?


Could you share with the group what "simple iptables rules" you use? I 
presume that iptables, by itself, can't replicate the idea of "block 
after X failures in Y minutes", but presumably you're using some kind of 
rate limiting, instead?




Reco



--
For more information, please reread.

Re: ssh doesn't work.

[Henning Follmann]

On Wed, Dec 07, 2016 at 11:35:36PM -0800, emetib wrote:
> > > Sorry, you have to stop this. Now!
> > 
> > I thought that to be a basic manner as the original questioner.
> > Why do you think isn't that good?
> > Everybody else, how do you think?
> 
> he's saying don't change 4 things at once.  
> 

I am going further than that. Don't change anything at all!
Not for a long time!
Based on this thread the OP is making everything too complicated by trying
to be clever. I bet his front door knob turns the other way to confuse
burglars and evrytime he comes home from the pub all pissed he goes: "Ahh
balls...".


-H 


-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: ssh doesn't work.

[Lisi Reisz]

On Thursday 08 December 2016 04:19:00 EenyMeenyMinyMoa wrote:
> Hi,
>
> 2016-12-08 5:25 GMT+09:00 Brian :
> > Random script kiddy attacks are of absolutely no consequence. Annoying
> > perhaps, but no threat whatsoever. In terms of security, changing the
> > port number for ssh does bugger all.
>
> What security risk can changing the port number for ssh cause?

If it does bugger all, it isn't a security risk either.  "Does bugger all" 
means that it doesn't do anything whatsoever, so I take it to mean (possibly 
erroneously) that: changing the port number does not create a security risk, 
but neither does it improve security.  It just introduces unnecessary further 
complication.

Not everyone agrees with Brian (I know far too little about it to have an 
opinion, but tend to listen to Brian) but I think that is what he is saying.

Lisi

Re: ssh doesn't work.

[emetib]

> > Sorry, you have to stop this. Now!
> 
> I thought that to be a basic manner as the original questioner.
> Why do you think isn't that good?
> Everybody else, how do you think?

he's saying don't change 4 things at once.  

change one, test
change another, test


that's how you trouble shoot.  then you know what steps you have to take to 
make things work the next time around.

Re: ssh doesn't work.

[EenyMeenyMinyMoa]

2016-12-08 1:07 GMT+09:00 Henning Follmann :
>> > Thank you for your reply, Andy.
>> >
> Please be so nice and trim your post to be meaningful and concise. Don't
> just slapp something on the top.

2016-12-08 3:23 GMT+09:00 Henning Follmann :
>> Thank you for the quick response, Henning.
>> >
> Sorry, you have to stop this. Now!

I thought that to be a basic manner as the original questioner.
Why do you think isn't that good?
Everybody else, how do you think?

Cheers,
EenyMeenyMinyMoa

Re: ssh doesn't work.

[EenyMeenyMinyMoa]

Hi,

2016-12-08 5:25 GMT+09:00 Brian :
> Random script kiddy attacks are of absolutely no consequence. Annoying
> perhaps, but no threat whatsoever. In terms of security, changing the
> port number for ssh does bugger all.

What security risk can changing the port number for ssh cause?

Cheers,
EenyMeenyMinyMoa

Re: ssh doesn't work.

[EenyMeenyMinyMoa]

Hi,

2016-12-08 2:52 GMT+09:00 Greg Wooledge :
> On Thu, Dec 08, 2016 at 02:37:09AM +0900, EenyMeenyMinyMoa wrote:
>> $ ls -ls /home/testac/.ssh
>> total 12
>> 4 -rwx-- 1 u1 u1 776 Dec  8 11:05 authorized_keys
>> 4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
>> 4 -rwx-- 1 u1 u1 444 Dec  6 20:46 known_hosts
>
> Which machine is that -- the client, or the server?
>

the server.

> Check those things on the server, and also check:
> ls -ld / /home /home/testac /home/testac/.ssh
>
> Also make sure that "u1" is the actual owner of /home/testac.
> The discrepancy between the username shown by ls -l and the name
> of the home directory does not inspire confidence.

I changed the owner of /home/testac and the files on the server. And after
operations obeying

2016-12-08 3:51 GMT+09:00 emetib :
> On Wednesday, December 7, 2016 at 11:40:04 AM UTC-6, EenyMeenyMinyMoa
wrote:
>>
>> $ ls -ls /home/testac/.ssh
>> total 12
>> 4 -rwx-- 1 u1 u1 776 Dec  8 11:05 authorized_keys
>> 4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
>> 4 -rwx-- 1 u1 u1 444 Dec  6 20:46 known_hosts
>>
> check the perms on ~/.ssh
> should be 700, dwrx--
>
> and your authorized_keys should be 644, -rw-r--r--

$ sudo ls -la /home/testac/.ssh/
total 20
drwx-- 2 testac testac 4096 Dec  8 07:57 .
drwxr-xr-x 4 testac testac 4096 Dec  8 07:49 ..
-rw-r--r-- 1 testac testac  776 Dec  8 11:05 authorized_keys
-rw-r--r-- 1 testac testac  388 Dec  6 11:57 id_rsa_for_test.pub
-rwx-- 1 testac testac  444 Dec  6 20:46 known_hosts

and tried.

$ ssh -p  testac@192.168.0.5

Then a dialog box prompting me to enter my private key appeared.
After entering it, I could login.
Already at this stage(PasswordAuthentication yes), the prompt
testac@192.168.0.5's password:
didn't appear.
Next I changed /etc/ssh/ssh_config on the server

PasswordAuthentication no

and after executing

$ sudo systemctl restart ssh

, then I could successfully login too.
Thank you everyone!

Cheers,
EenyMeenyMinyMoa

Re: ssh doesn't work.

[Reco]

On Wed, 7 Dec 2016 15:54:46 -0500
Henning Follmann  wrote:

> On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
> > Hi.
> > 
> > On Wed, 7 Dec 2016 21:14:51 +0200
> > Antti Talsta  wrote:
> > 
> > > On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> > > 
> > > > Changing the port at least decreases the number of brute force attacks
> > > > against you, which saves resources (bandwidth, CPU) that are otherwise
> > > > wasted by the attackers.
> > > 
> > > How about fail2ban for that?
> > 
> > How fail2ban can help against an army of bots trying one single
> > password per bot?
> > 
> That actually works well. Usually it's multiple attempts from one ip.
> fail2ban catches exactly that. And then blacklists that ip.

Probably it is so. It's been awhile since I ran publicly accessible
sshd on port 22 with password authentication enabled.

Personally I prefer a bunch of simple iptables rules to fail2ban
though. After all, why bother running a userspace tool, if you can
force the kernel itself to do the job?

Reco

Re: ssh doesn't work.

[Reco]

On Wed, 7 Dec 2016 22:46:16 +0200
Antti Talsta  wrote:

> On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
> 
> > How fail2ban can help against an army of bots trying one single
> > password per bot?
> 
> It doesn't.

My point exactly. Using sshd on non-standard port does, as bots are too
stupid to try anything other than tcp:22 on ipv4 for ssh brute-force.

Does not invalidate other virtues of using fail2ban though.

Reco

Re: ssh doesn't work.

[Antti Talsta]

On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:

> How fail2ban can help against an army of bots trying one single
> password per bot?

It doesn't.
 
-- 
Antti Talsta


signature.asc
Description: Digital signature

Re: ssh doesn't work.

[Henning Follmann]

On Wed, Dec 07, 2016 at 11:28:53PM +0300, Reco wrote:
>   Hi.
> 
> On Wed, 7 Dec 2016 21:14:51 +0200
> Antti Talsta  wrote:
> 
> > On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> > 
> > > Changing the port at least decreases the number of brute force attacks
> > > against you, which saves resources (bandwidth, CPU) that are otherwise
> > > wasted by the attackers.
> > 
> > How about fail2ban for that?
> 
> How fail2ban can help against an army of bots trying one single
> password per bot?
> 
That actually works well. Usually it's multiple attempts from one ip.
fail2ban catches exactly that. And then blacklists that ip.

-H

-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: ssh doesn't work.

[Reco]

Hi.

On Wed, 7 Dec 2016 21:14:51 +0200
Antti Talsta  wrote:

> On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> 
> > Changing the port at least decreases the number of brute force attacks
> > against you, which saves resources (bandwidth, CPU) that are otherwise
> > wasted by the attackers.
> 
> How about fail2ban for that?

How fail2ban can help against an army of bots trying one single
password per bot?

Reco

Re: ssh doesn't work.

[Brian]

On Wed 07 Dec 2016 at 13:49:34 -0500, Greg Wooledge wrote:

> On Wed, Dec 07, 2016 at 01:23:23PM -0500, Henning Follmann wrote:
> > Also changing the port to a nonstandard port is not a safety measure. Not a
> > reasonable at least. Unless there is some sane reason (like the network
> > operator prevents using port 22) keep it!
> 
> I disagree with this.  Changing the port at least decreases the number
> of brute force attacks against you, which saves resources (bandwidth, CPU)
> that are otherwise wasted by the attackers.

I agree with this. Having ssh on a port other than 22 does decrease the
*visibility* of probes to port 22. A user would in all probabilty see
nothing and would have a warm, fuzzy feeling. Job done; nothing to see.

However, while it might save resources it does not make the ssh service
any safer. Henning Follmann is correct, it is not a safety measure. To
be a safety measure it would have to guard against something which is
inherently defective in ssh itself. There is no such known defect in
ssh which makes random password probing more likely to succeed than
non-random probing.

> I understand that you mean "it will not stop a dedicated professional
> attacker who really, really wants to get into your computer".  And that's
> true.  But it does help against the random script kiddies and attacks of
> opportunity.

Whatever you understand, Henning Follmann said nothing of the sort. You
have put words into his mouth and introduced buzzwords like "dedicated",
"professional" and "attacker". You give the impression that someone who
really wants to get into your computer via ssh can do so. 

That is not correct. There is no way *anyone* can get into your ssh
account protected by a good password. There is no hole in ssh; it does
not exist.

Random script kiddy attacks are of absolutely no consequence. Annoying
perhaps, but no threat whatsoever. In terms of security, changing the
port number for ssh does bugger all.

-- 
Brian.

Re: ssh doesn't work.

[Antti Talsta]

On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:

> Changing the port at least decreases the number of brute force attacks
> against you, which saves resources (bandwidth, CPU) that are otherwise
> wasted by the attackers.

How about fail2ban for that?

-- 
Antti Talsta


signature.asc
Description: Digital signature

Re: ssh doesn't work.

[Henning Follmann]

On Wed, Dec 07, 2016 at 01:49:34PM -0500, Greg Wooledge wrote:
> On Wed, Dec 07, 2016 at 01:23:23PM -0500, Henning Follmann wrote:
> > Also changing the port to a nonstandard port is not a safety measure. Not a
> > reasonable at least. Unless there is some sane reason (like the network
> > operator prevents using port 22) keep it!
> 
> I disagree with this.  Changing the port at least decreases the number
> of brute force attacks against you, which saves resources (bandwidth, CPU)
> that are otherwise wasted by the attackers.
> 
This is security by obscurity, which has some serious issues.
First it hides obvious issues. If you see high traffic on port  noone
in the NOC knows what that is. If it is on port 22 they know it's ssh.

Also have a sensible plan in place (and the documentation with it).
So if I have admins in the US and in Germany, I only let ip from that
origin connect to port 22.

And also IDS (e.g. fail2ban) help you cutting those waste cpu cycles down.

And the best part about this, any issue will be obvious. And  obscurity
is the enemy of security.


> I understand that you mean "it will not stop a dedicated professional
> attacker who really, really wants to get into your computer".  And that's
> true.  But it does help against the random script kiddies and attacks of
> opportunity.
> 

And to protect against the "professionals" allow only pk authentication
when the service is on any public network.

-H


-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: ssh doesn't work.

[emetib]

On Wednesday, December 7, 2016 at 11:40:04 AM UTC-6, EenyMeenyMinyMoa wrote:
> 
> $ ls -ls /home/testac/.ssh
> total 12
> 4 -rwx-- 1 u1 u1 776 Dec  8 11:05 authorized_keys
> 4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
> 4 -rwx-- 1 u1 u1 444 Dec  6 20:46 known_hosts
> 
check the perms on ~/.ssh
should be 700, dwrx--

and your authorized_keys should be 644, -rw-r--r--

and then try again

good luck 
em

Re: ssh doesn't work.

[Greg Wooledge]

On Wed, Dec 07, 2016 at 01:23:23PM -0500, Henning Follmann wrote:
> Also changing the port to a nonstandard port is not a safety measure. Not a
> reasonable at least. Unless there is some sane reason (like the network
> operator prevents using port 22) keep it!

I disagree with this.  Changing the port at least decreases the number
of brute force attacks against you, which saves resources (bandwidth, CPU)
that are otherwise wasted by the attackers.

I understand that you mean "it will not stop a dedicated professional
attacker who really, really wants to get into your computer".  And that's
true.  But it does help against the random script kiddies and attacks of
opportunity.

Re: ssh doesn't work.

[Henning Follmann]

On Thu, Dec 08, 2016 at 02:37:09AM +0900, EenyMeenyMinyMoa wrote:
> Thank you for the quick response, Henning.
> 
Sorry, you have to stop this. Now!
I think it is great that you want to learn how to use ssh. It is an
important skill for admins and users.
However you are approaching it the wrong way. Your set up is too
complicated and you poke around in  the dark.

Set up two machines. install ssh and the server on those machines.
Create identical named accounts on both.

Then connect. 
Then understand!
Only after you understand, make ONE! change at the time.
repeat.

Also changing the port to a nonstandard port is not a safety measure. Not a
reasonable at least. Unless there is some sane reason (like the network
operator prevents using port 22) keep it!

You made too many changes without even understanding what these changes do.
The likelihood that you end up with an insecure setup is high this way.





-H




-- 
Henning Follmann   | hfollm...@itcfollmann.com

Re: ssh doesn't work.

[Greg Wooledge]

On Thu, Dec 08, 2016 at 02:37:09AM +0900, EenyMeenyMinyMoa wrote:
> $ ls -ls /home/testac/.ssh
> total 12
> 4 -rwx-- 1 u1 u1 776 Dec  8 11:05 authorized_keys
> 4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
> 4 -rwx-- 1 u1 u1 444 Dec  6 20:46 known_hosts

Which machine is that -- the client, or the server?

Check those things on the server, and also check:
ls -ld / /home /home/testac /home/testac/.ssh

Also make sure that "u1" is the actual owner of /home/testac.
The discrepancy between the username shown by ls -l and the name
of the home directory does not inspire confidence.

Re: ssh doesn't work.

[EenyMeenyMinyMoa]

Thank you for the quick response, Henning.

2016-12-08 1:07 GMT+09:00 Henning Follmann :
> Please revert to your original configs. Key login works be default and
> requires no change.

By reverting to my original configs :
PasswordAuthentication yes
I was able to ssh.

$ ssh -p  testac@192.168.0.5
testac@192.168.0.5's password:
Last login: Thu Dec  8 10:56:31 2016 from 192.168.0.3

>
> first generate a key:
> ssh-keygen
>
> By default it creats both id_rsa and id_rsa.pub in your ~/.ssh directory.
> id_rsa contains the private key and it should remain on the client machine
> in your ~/.ssh directory.

I already did as the debug output in my last email showed.

> Transfer the id_rsa.pub to the server you want to logon to.there append it
> to
> cat id_rsa.pub >> /.ssh/authorized_keys
>

Sorry. I forgot writing about having done this.

> debug1: Authentications that can continue: publickey,keyboard-interactive
> debug1: Trying private key: /home/emmm/.ssh/id_rsa
> debug1: Trying private key: /home/emmm/.ssh/id_dsa
> debug1: Trying private key: /home/emmm/.ssh/id_ecdsa
> debug1: Trying private key: /home/emmm/.ssh/id_ed25519
> debug1: Next authentication method: keyboard-interactive

I'm now going to comprehend the debugging output.
On the client ssh tried to use my private key, but failed?

> now you should be able to ssh into that server with pk authorization.
>
> If that works you can go on and disable the password authorization by
> setting on the server sshd config
>
> PasswordAuthentication no

By changing only this line of sshd config, the result is

$ ssh -p  testac@192.168.0.5
Permission denied (publickey,keyboard-interactive).
$ ssh -p 9801 -l testac -i ~/.ssh/id_rsa_for_test 192.168.0.5
Permission denied (publickey,keyboard-interactive).

I'll try further and am consulting
http://unix.stackexchange.com/questions/36540/why-am-i-still-getting-a-password-prompt-with-ssh-with-public-key-authentication
and so on.

$ ls -ls /home/testac/.ssh
total 12
4 -rwx-- 1 u1 u1 776 Dec  8 11:05 authorized_keys
4 -rw-r--r-- 1 u1 u1 388 Dec  6 11:57 id_rsa_test.pub
4 -rwx-- 1 u1 u1 444 Dec  6 20:46 known_hosts

Cheers,
EenyMeenyMinyMoa

Re: ssh doesn't work.

[Henning Follmann]

On Thu, Dec 08, 2016 at 12:27:53AM +0900, EenyMeenyMinyMoa wrote:
> Thank you for your reply, Andy.
> 
Please be so nice and trim your post to be meaningful and concise. Don't
just slapp something on the top.


> ufw was enabled on the server machine.
> Because I don't have enough knoledge about iptables, I did
> $ sudo ufw allow proto tcp from 192.168.0.3 to any port 
> on the server machine.
> Then I successfully connected from the client machine by ssh.
> 
> And next I want to do ssh with authentication key instead of password.
> I've been struggling for hours.
> I rewrited /etc/ssh/sshd_config.
> On the client machine,
> 
> PasswordAuthentication no
> AuthorizedKeysFile%h/.ssh/authorized_keys
> UsePAM no
> 
> On the server machine,
> 
> PasswordAuthentication no
> AuthorizedKeysFile%h/.ssh/authorized_keys
> UsePAM no
> 
> Then I tried, but
> Password:
> still appeared.
> 


Please revert to your original configs. Key login works be default and
requires no change.

first generate a key:
ssh-keygen

By default it creats both id_rsa and id_rsa.pub in your ~/.ssh directory.
id_rsa contains the private key and it should remain on the client machine
in your ~/.ssh directory.
Transfer the id_rsa.pub to the server you want to logon to.there append it
to 
cat id_rsa.pub >> /.ssh/authorized_keys

now you should be able to ssh into that server with pk authorization.

If that works you can go on and disable the password authorization by
setting on the server sshd config

PasswordAuthentication no

-H

Re: ssh doesn't work.

[EenyMeenyMinyMoa]

Thank you for your reply, Andy.

ufw was enabled on the server machine.
Because I don't have enough knoledge about iptables, I did
$ sudo ufw allow proto tcp from 192.168.0.3 to any port 
on the server machine.
Then I successfully connected from the client machine by ssh.

And next I want to do ssh with authentication key instead of password.
I've been struggling for hours.
I rewrited /etc/ssh/sshd_config.
On the client machine,

PasswordAuthentication no
AuthorizedKeysFile%h/.ssh/authorized_keys
UsePAM no

On the server machine,

PasswordAuthentication no
AuthorizedKeysFile%h/.ssh/authorized_keys
UsePAM no

Then I tried, but
Password:
still appeared.

$ ssh -v -p  testac@192.168.0.5
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.5 [192.168.0.5] port .
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5+deb8u3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1
Debian-5+deb8u3
debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x0400
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr umac-64-...@openssh.com none
debug1: kex: client->server aes128-ctr umac-64-...@openssh.com none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ECDSA
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
debug1: Host '[192.168.0.5]:' is known and matches the ECDSA host key.
debug1: Found key in /home/emmm/.ssh/known_hosts:1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: emmm@jessie
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/emmm/.ssh/id_rsa
debug1: Trying private key: /home/emmm/.ssh/id_dsa
debug1: Trying private key: /home/emmm/.ssh/id_ecdsa
debug1: Trying private key: /home/emmm/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.0.5 ([192.168.0.5]:).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = ja_JP.UTF-8
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: Thu Dec  8 08:28:43 2016 from 192.168.0.3
testac@jessie2:~$

I rewrited /etc/ssh/sshd_config on the server again 'cause my key is 2048
bit.

ServerKeyBits 2048

Then tried again.

$ ssh -v -p  testac@192.168.0.5
OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.5 [192.168.0.5] port .
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/emmm/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file 

Re: ssh doesn't work.

[Andy Smith]

Hi,

On Tue, Dec 06, 2016 at 01:33:07PM +0900, EenyMeenyMinyMoa wrote:
> But when I execute either of these commands
> $ ssh -p  testac@192.168.0.5
> $ ssh -p  -l testac -i ~/.ssh/id_rsa_test 192.168.0.5
> , the terminal doesn't resopnd for minutes and finally gives this message.
> ssh: connect to host 192.168.0.5 port : Connection timed out

The settings you've shown seem correct but the above output implies
a lack of connectivity. Have you checked there is no firewall
preventing port  TCP communication?

To list rules:

# iptables -nL 

If that comes up empty, some basic connectivity checks (ping
192.168.0.5 from client) may be useful.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

"I'd be happy to buy all variations of sex to ensure I got what I wanted."
 — Gary Coates (talking about cabling)

ssh doesn't work.

[EenyMeenyMinyMoa]

Hi.
I'm using jessie and trying to connect from one jessie machine to another
jessie machine by ssh.
I succeeded the following commands at the server machine.
$ ssh -p  testac@localhost
$ ssh -p  -l testac -i ~/.ssh/id_rsa_test localhost

But when I execute either of these commands
$ ssh -p  testac@192.168.0.5
$ ssh -p  -l testac -i ~/.ssh/id_rsa_test 192.168.0.5
, the terminal doesn't resopnd for minutes and finally gives this message.
ssh: connect to host 192.168.0.5 port : Connection timed out

How can I connect?

On the client machine,

$ sudo ifconfig
eth2  Link encap:Ethernet  HWaddr --:--:--:--:--:--
  inet addr:192.168.0.3  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: :::::/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:278828 errors:0 dropped:0 overruns:0 frame:0
  TX packets:210030 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:316479195 (301.8 MiB)  TX bytes:22264869 (21.2 MiB)
loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:65536  Metric:1
  RX packets:4694 errors:0 dropped:0 overruns:0 frame:0
  TX packets:4694 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:414354 (404.6 KiB)  TX bytes:414354 (404.6 KiB)

$ sudo arp-scan -I eth2 -l
Interface: eth2, datalink type: EN10MB (Ethernet)
Starting arp-scan 1.8.1 with 256 hosts (
http://www.nta-monitor.com/tools/arp-scan/)
192.168.0.1--:--:--:--:--:--I-O DATA DEVICE, INC.
192.168.0.5--:--:--:--:--:--FOXCONN
2 packets received by filter, 0 packets dropped by kernel
Ending arp-scan 1.8.1: 256 hosts scanned in 1.383 seconds (185.10
hosts/sec). 2 responded

$ tail -5 /etc/ssh/ssh_config
#   RekeyLimit 1G 1h
SendEnv LANG LC_*
HashKnownHosts yes
GSSAPIAuthentication yes
GSSAPIDelegateCredentials no

$ cat /etc/ssh/sshd_config
# Package generated configuration file
# See the sshd_config(5) manpage for details
# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes
# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024
# Logging
SyslogFacility AUTH
LogLevel INFO
# Authentication:
LoginGraceTime 120
PermitRootLogin no
StrictModes yes
RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile%h/.ssh/authorized_keys
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for
RhostsRSAAuthentication
#IgnoreUserKnownHosts yes
# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no
#MaxStartups 10:30:60
#Banner /etc/issue.net
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes


On the server machine,

$ sudo ifconfig
eth1  Link encap:Ethernet  HWaddr --:--:--:--:--:--
  inet addr:192.168.0.5  Bcast:192.168.0.255  Mask:255.255.255.0
  inet6 addr: :::::/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:31176 errors:0 dropped:0 overruns:0 frame:0
  TX packets:20889 errors:0 

Re: SSH doesn't work with RSA keys

[Jon Dowland]

On Wed, Jan 03, 2007 at 10:27:36PM -0300, Alejandro wrote:
 1) What are the lines I should setup in
 /etc/ssh/sshd_config from the server side  Just
 *AuthorizedKeysFile %h/.ssh/authorized_keys* or what else
 ???

You shouldn't need to put anything. The sshd server in
Debian will assume a default value of
%h/.ssh/authorized_keys for AuthorizedKeysFile if it is
not defined.


-- 
Jon Dowland


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: SSH doesn't work with RSA keys

[Sebastian Helms]

Hi,

* on Jan 03, 2007, Alejandro wrote:
 On Wed, Jan 03, 2007 at 05:50:40PM -0300, Alejandro wrote:
   
 People, I have generated the key pair RSA from my root linux's user and
 then I copy my RSA public key to /root/.ssh/authorized_keys from the
 linux ssh server. After that I edit the sshd_config file and put permit
 rootlogin no and the correct path to the authorized_keys file. But when
 I execute from the client ssh [EMAIL PROTECTED] it doesn't enter and the
 password banner is showed. Here I put my debugs from ssh client and
 server and my sshd_config file from the serverI REALLY THANKS YOUR
 COMMENTS !!!

Am I missing something - ?

You put permit_rootlogin no and try ssh [EMAIL PROTECTED] - how should
that work?

Regards,

Sebastian

-- 
Every man dies.
Not every man really lives.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: SSH doesn't work with RSA keys

[Sebastian Helms]

Hi again,

* on Jan 04, 2007, I wrote:
 * on Jan 03, 2007, Alejandro wrote:
  On Wed, Jan 03, 2007 at 05:50:40PM -0300, Alejandro wrote:

  People, I have generated the key pair RSA from my root linux's user and
  then I copy my RSA public key to /root/.ssh/authorized_keys from the
  linux ssh server. After that I edit the sshd_config file and put permit
  rootlogin no and the correct path to the authorized_keys file. But when
  I execute from the client ssh [EMAIL PROTECTED] it doesn't enter and the
  password banner is showed. Here I put my debugs from ssh client and
  server and my sshd_config file from the serverI REALLY THANKS YOUR
  COMMENTS !!!
 
 Am I missing something - ?
 
 You put permit_rootlogin no and try ssh [EMAIL PROTECTED] - how should
 that work?

Sorry, I might have been a bit abbreviated ;)

If you disable root logins by configuring your sshd, every
authentication method must fail.

So, ssh may even correctly supply the correct public key, which sshd
can find in authorized_keys(2?). But as root is not allowed to login
via ssh, it fails nonetheless.

ssh has no way of knowing why the key failed, so it falls back to
the next auth method - keyboard_interactive or password.

If you try, ssh should not accept your valid root password but fail
again.

Have you tried with permit_rootlogin yes?

Regards,

Sebastian

-- 
Every man dies.
Not every man really lives.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: SSH doesn't work with RSA keys

[michael]

On Wed, 03 Jan 2007 17:50:40 -0300, Alejandro wrote
 People, I have generated the key pair RSA from my root linux's user and
 then I copy my RSA public key to /root/.ssh/authorized_keys from the
 linux ssh server. After that I edit the sshd_config file and put permit
 rootlogin no and the correct path to the authorized_keys file. But when
 I execute from the client ssh [EMAIL PROTECTED] it doesn't enter and the
 password banner is showed. Here I put my debugs from ssh client and
 server and my sshd_config file from the serverI REALLY THANKS 
 YOUR COMMENTS !!!

Try changing permitrootlogin to say without-password.
This will block ssh root logins, but allow it only if your
using keys with it. (doesn't matter if keys have password or not)

Permissions and ownership of your .ssh folder matter too.
If it gets changed to something other than the default set when
its first created, then it will break the key based ssh login.
You can simply delete it, and attempt an ssh connection to somewhere
so it re-creates it with proper permissions.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

SSH doesn't work with RSA keys

[Alejandro]

People, I have generated the key pair RSA from my root linux's user and
then I copy my RSA public key to /root/.ssh/authorized_keys from the
linux ssh server. After that I edit the sshd_config file and put permit
rootlogin no and the correct path to the authorized_keys file. But when
I execute from the client ssh [EMAIL PROTECTED] it doesn't enter and the
password banner is showed. Here I put my debugs from ssh client and
server and my sshd_config file from the serverI REALLY THANKS YOUR
COMMENTS !!!

SERVER
--
racka:~/.ssh# /usr/sbin/sshd -d
debug1: sshd version OpenSSH_4.3p2 Debian-8
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
debug1: Bind to port 22 on 10.1.1.7.
Server listening on 10.1.1.7 port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 4 out 4 newsock 4 pipe -1 sock 7
debug1: inetd sockets after dupping: 3, 3
Connection from 10.1.1.2 port 36173
debug1: Client protocol version 2.0; client software version
OpenSSH_3.8.1p1 Debian-8.sarge.6
debug1: match: OpenSSH_3.8.1p1 Debian-8.sarge.6 pat OpenSSH_3.*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.3p2 Debian-8
debug1: permanently_set_uid: 101/65534
debug1: list_hostkey_types: ssh-rsa,ssh-dss
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: client-server aes128-cbc hmac-md5 none
debug1: kex: server-client aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: KEX done
debug1: userauth-request for user root service ssh-connection method none
debug1: attempt 0 failures 0
debug1: PAM: initializing for root
debug1: PAM: setting PAM_RHOST to 10.1.1.2
debug1: PAM: setting PAM_TTY to ssh
Failed none for root from 10.1.1.2 port 36173 ssh2
Failed none for root from 10.1.1.2 port 36173 ssh2
debug1: userauth-request for user root service ssh-connection method
publickey
debug1: attempt 1 failures 1
debug1: test whether pkalg/pkblob are acceptable
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
buffer_get_ret: trying to get more bytes 129 than in buffer 34
buffer_get_string_ret: buffer_get failed
buffer_get_bignum2_ret: invalid bignum
key_from_blob: can't read rsa key
key_read: key_from_blob
B3NzaC1yc2EBIwAAAIEAwlWGOvzpqyPFb24q6JtOs/sq7UTl/hK3fo9JNaT6bk3k
 failed
buffer_get_ret: trying to get more bytes 129 than in buffer 34
buffer_get_string_ret: buffer_get failed
buffer_get_bignum2_ret: invalid bignum
key_from_blob: can't read rsa key
key_read: key_from_blob
B3NzaC1yc2EBIwAAAIEAwlWGOvzpqyPFb24q6JtOs/sq7UTl/hK3fo9JNaT6bk3k
 failed
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys
buffer_get_ret: trying to get more bytes 129 than in buffer 34
buffer_get_string_ret: buffer_get failed
buffer_get_bignum2_ret: invalid bignum
key_from_blob: can't read rsa key
key_read: key_from_blob
B3NzaC1yc2EBIwAAAIEAwlWGOvzpqyPFb24q6JtOs/sq7UTl/hK3fo9JNaT6bk3k
 failed
buffer_get_ret: trying to get more bytes 129 than in buffer 34
buffer_get_string_ret: buffer_get failed
buffer_get_bignum2_ret: invalid bignum
key_from_blob: can't read rsa key
key_read: key_from_blob
B3NzaC1yc2EBIwAAAIEAwlWGOvzpqyPFb24q6JtOs/sq7UTl/hK3fo9JNaT6bk3k
 failed
debug1: restore_uid: 0/0
Failed publickey for root from 10.1.1.2 port 36173 ssh2

CLIENTE
---
ana:~/.ssh# ssh -vv [EMAIL PROTECTED]
OpenSSH_3.8.1p1 Debian-8.sarge.6, OpenSSL 0.9.7e 25 Oct 2004
debug1: Reading configuration data /etc/ssh/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 10.1.1.7 [10.1.1.7] port 22.
debug1: Connection established.
debug1: identity file /root/.ssh/identity type -1
debug2: key_type_from_name: unknown key type '-BEGIN'
debug2: key_type_from_name: unknown key type '-END'
debug1: identity file /root/.ssh/id_rsa type 1
debug1: identity file /root/.ssh/id_dsa type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_4.3p2 Debian-8
debug1: match: OpenSSH_4.3p2 Debian-8 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_3.8.1p1 Debian-8.sarge.6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit:
diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,[EMAIL
 PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr
debug2: kex_parse_kexinit:

Re: SSH doesn't work with RSA keys

[Jochen Schulz]

Alejandro:

 People, I have generated the key pair RSA from my root linux's user and
 then I copy my RSA public key to /root/.ssh/authorized_keys from the
 linux ssh server.

Good.

 After that I edit the sshd_config file and put permit
 rootlogin no

Erm, to permit means to allow. You just locked out root (via ssh).
Don't do that if you want to allow root to login via ssh.

 and the correct path to the authorized_keys file. But when
 I execute from the client ssh [EMAIL PROTECTED] it doesn't enter and the
 password banner is showed.

That's what ssh does for every user that is not allowed to login at all
(if password login is enabled. Otherwise it will ask for a public key
and neglect it).

J.
-- 
There is no justice in road accidents.
[Agree]   [Disagree]
 http://www.slowlydownward.com/NODATA/data_enter2.html


signature.asc
Description: Digital signature

Re: SSH doesn't work with RSA keys

[Andrew M.A. Cater]

On Wed, Jan 03, 2007 at 05:50:40PM -0300, Alejandro wrote:
 People, I have generated the key pair RSA from my root linux's user and
 then I copy my RSA public key to /root/.ssh/authorized_keys from the
 linux ssh server. After that I edit the sshd_config file and put permit
 rootlogin no and the correct path to the authorized_keys file. But when
 I execute from the client ssh [EMAIL PROTECTED] it doesn't enter and the
 password banner is showed. Here I put my debugs from ssh client and
 server and my sshd_config file from the serverI REALLY THANKS YOUR
 COMMENTS !!!
 

Example:

Try setting up a normal user first - check whether that works.
Example commands are indented in what follows. Comments are mostly
in []

As user pele change to your home directory on the first machine 
(here called cerca) then

ssh-keygen -t rsa -b 2048

[Follow the prompts: don't use a passphrase. This should generate 
a pair of keys id_rsa and id_rsa.pub

cd /home/pele/.ssh

touch authorized_keys

chmod 0600 authorized_keys

Follow the same procedure on the other machine (here called lejos).

On machine cerca:

cd /home/pele/.ssh

scp lejos:/home/pele/.ssh/id_dsa.pub ./id_dsa.pubLEJOS

[This copies the file you need from the other machine and names it so 
you can tell where it comes from. At this point, you may need to use 
passwords]

scp ./id_dsa.pub lejos:/home/pele/.ssh/id_dsa.pubCERCA

[Copying the public RSA key from the machine you are on to the distant 
machine]

cat id_dsa.pubLEJOS  authorized_keys

[Copy the public RSA key from the distant machine and 
append it to the authorized_keys file on your local machine]

[Now copy the key into the appropriate place on the distant machine and 
append it to the authorized_keys file there. ]

ssh lejos

cd /home/pele/.ssh

cat id_dsa.pubCERCA  authorized_keys

[Check that an ssh connection works in both directions:
[On cerca]

ssh lejos

[On lejos]

ssh cerca

should both work immediately.

Now do the same with keys for root, if you want to. If you only want one 
user to have effective root privilege - append the id_dsa.pub for root 
on the machine to the end of his /.ssh/authorized_keys file

Hope this helps,

Andy


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: SSH doesn't work with RSA keys

[Douglas Tutty]

On Wed, Jan 03, 2007 at 10:02:30PM +, Andrew M.A. Cater wrote:
 On Wed, Jan 03, 2007 at 05:50:40PM -0300, Alejandro wrote:
  People, I have generated the key pair RSA from my root linux's user and
  then I copy my RSA public key to /root/.ssh/authorized_keys from the
  linux ssh server. After that I edit the sshd_config file and put permit
  rootlogin no and the correct path to the authorized_keys file. But when
  I execute from the client ssh [EMAIL PROTECTED] it doesn't enter and the
  password banner is showed. Here I put my debugs from ssh client and
  server and my sshd_config file from the serverI REALLY THANKS YOUR
  COMMENTS !!!
  
 
There's also a good short section in the debian-reference about this,
also using ssh to append your key from this machine to the other
machine.

Myself, once I get it working without passwords, I disable password
login in the config.

Doug.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: SSH doesn't work with RSA keys

[Alejandro]

Andrew M.A. Cater wrote:

On Wed, Jan 03, 2007 at 05:50:40PM -0300, Alejandro wrote:
  

People, I have generated the key pair RSA from my root linux's user and
then I copy my RSA public key to /root/.ssh/authorized_keys from the
linux ssh server. After that I edit the sshd_config file and put permit
rootlogin no and the correct path to the authorized_keys file. But when
I execute from the client ssh [EMAIL PROTECTED] it doesn't enter and the
password banner is showed. Here I put my debugs from ssh client and
server and my sshd_config file from the serverI REALLY THANKS YOUR
COMMENTS !!!




Example:

Try setting up a normal user first - check whether that works.
Example commands are indented in what follows. Comments are mostly
in []

As user pele change to your home directory on the first machine 
(here called cerca) then


ssh-keygen -t rsa -b 2048

[Follow the prompts: don't use a passphrase. This should generate 
a pair of keys id_rsa and id_rsa.pub


cd /home/pele/.ssh

touch authorized_keys

chmod 0600 authorized_keys

Follow the same procedure on the other machine (here called lejos).

On machine cerca:

cd /home/pele/.ssh

scp lejos:/home/pele/.ssh/id_dsa.pub ./id_dsa.pubLEJOS

[This copies the file you need from the other machine and names it so 
you can tell where it comes from. At this point, you may need to use 
passwords]


scp ./id_dsa.pub lejos:/home/pele/.ssh/id_dsa.pubCERCA

[Copying the public RSA key from the machine you are on to the distant 
machine]


cat id_dsa.pubLEJOS  authorized_keys

[Copy the public RSA key from the distant machine and 
append it to the authorized_keys file on your local machine]


[Now copy the key into the appropriate place on the distant machine and 
append it to the authorized_keys file there. ]


ssh lejos

cd /home/pele/.ssh

cat id_dsa.pubCERCA  authorized_keys

[Check that an ssh connection works in both directions:
[On cerca]

ssh lejos

[On lejos]

ssh cerca

should both work immediately.

Now do the same with keys for root, if you want to. If you only want one 
user to have effective root privilege - append the id_dsa.pub for root 
on the machine to the end of his /.ssh/authorized_keys file


Hope this helps,

Andy


  
Andy, your example is very helpul to me...tomorow I'll follow your 
steps. But let me ask these two last questions:


1) What are the lines I should setup in /etc/ssh/sshd_config from the 
server side  Just *AuthorizedKeysFile %h/.ssh/authorized_keys* or 
what else ???


2) Some people say if I use SSH version 2, I have to use an 
*authorized_keys2* file instead of an *authorized_keys* file...is it OK

???

Thanks a lot and greetings,

alejandro.-


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: SSH doesn't work with RSA keys

[Roberto C. Sanchez]

On Wed, Jan 03, 2007 at 10:27:36PM -0300, Alejandro wrote:
 
 2) Some people say if I use SSH version 2, I have to use an 
 *authorized_keys2* file instead of an *authorized_keys* file...is it OK
 ???
 
This is only true for the ssh.com proprietary ssh server.  The openssh
server does not require this, but I think it might look there just for
the sake of compatibility.

Regards,

-Roberto

-- 
Roberto C. Sanchez
http://people.connexer.com/~roberto
http://www.connexer.com


signature.asc
Description: Digital signature

Re: X-forwarding with ssh doesn't work

[Tim Dijkstra]

For people who care: I figured it out.

It  seems that since I upgraded to testing lo (loopback interface) isn't 
broadup at boottime. I don't understand why by the way. I have a line 
saying 'auto lo' in my /etc/network/interfaces.


Further more I had to make a line 'ALL : 127.0.0.1' in my 
etc/hosts.allow to make it work. Otherwise the TCP-wraper woudn't allow 
the connection.



Tim

Re: X-forwarding with ssh doesn't work

[Tim Dijkstra]

nate wrote:


Tim Dijkstra said:



debug1: Requesting pty.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting shell.
debug1: Entering interactive session.

Is that enough? Does anybody with X-forw working correctly gets the
same  output?




pretty much. how bout when you start an X app?

sample output from one of my servers:
[EMAIL PROTECTED]:~$ xbrup
debug1: Received X11 open request.
debug1: fd 4 setting O_NONBLOCK
debug1: fd 4 IS O_NONBLOCK
debug1: channel 0: new [X11 connection from my.server.name port 3106]
(here i see the X app load on my local system)



I get no output at all. Think that's not good.

I can't say much about your probs... my own are worse I think.

Tim

Re: X-forwarding with ssh doesn't work

[Jeff]

Tim Dijkstra, 2001-Nov-16 23:52 +0100:
 nate wrote:
 
 Tim Dijkstra said:
 
 
 debug1: Requesting pty.
 debug1: Requesting X11 forwarding with authentication spoofing.
 debug1: Requesting shell.
 debug1: Entering interactive session.
 
 Is that enough? Does anybody with X-forw working correctly gets the
 same  output?
 
 
 
 pretty much. how bout when you start an X app?
 
 sample output from one of my servers:
 [EMAIL PROTECTED]:~$ xbrup
 debug1: Received X11 open request.
 debug1: fd 4 setting O_NONBLOCK
 debug1: fd 4 IS O_NONBLOCK
 debug1: channel 0: new [X11 connection from my.server.name port 3106]
 (here i see the X app load on my local system)
 
 
 I get no output at all. Think that's not good.
 
 I can't say much about your probs... my own are worse I think.
 
 Tim

I use ssh X-forwarding without a problem.  Here's what I do:

Scenario #1:
Laptop running potato/SSH Version OpenSSH-1.2.3, protocol
version 1.5.

Server running potato/SSH Version OpenSSH-1.2.3, protocol
version 1.5.

From Laptop:
$ ssh -n -X Server xchat

This brings up 'xchat' running from Server onto Laptop

Scenario #2:
Same Laptop

Server running woody/OpenSSH_2.9p2, SSH protocols 1.5/2.0,
OpenSSL 0x0090602f

From Laptop:
$ ssh -n -X -l user Server gkrellm -f

This brings up 'gkrellm' running from Server onto Laptop

Works like a charm...jc

-- 
Jeff CoppockSystems Engineer
Diggin' Debian  Admin and User

X-forwarding with ssh doesn't work

[Tim Dijkstra]

Hi,

I posted something about this problem a while ago, but I'am still stuck. 
The problem is that X-forwarding stopt working when I upgraded from 
potato to testing. I tried downgrading ssh and the x-server, but didn't 
help. I now even tried ssh-nonfree, still nothing.


OK, what is supposed to happen when I fire an X-app? Is there supposed 
to be some X-server proces running (because I do not see any), or is ssh 
just setting up some 'virtual' server? Is all data going over the same 
connection or is ssh supposed to make a new one specialy for X?


If I fire up an X-app, it just sits there in TOP, being happy, doing 
nothing. They don't complaing about non-existing displays, so something 
must be out there, but I just do not get a GUI on my desktop.


By the way I don't get any errors. When start with ssh -v, I get lots of 
harmless output which ends with:


debug1: RSA authentication accepted by server.
debug1: Requesting pty.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting shell.
debug1: Entering interactive session.

Is that enough? Does anybody with X-forw working correctly gets the same 
output?


Maybe some ideas where to look?

Mijn dank zal groot zijn!

Tim

Re: X-forwarding with ssh doesn't work

[nate]

Tim Dijkstra said:

 debug1: Requesting pty.
 debug1: Requesting X11 forwarding with authentication spoofing.
 debug1: Requesting shell.
 debug1: Entering interactive session.

 Is that enough? Does anybody with X-forw working correctly gets the
 same  output?


pretty much. how bout when you start an X app?

sample output from one of my servers:
[EMAIL PROTECTED]:~$ xbrup
debug1: Received X11 open request.
debug1: fd 4 setting O_NONBLOCK
debug1: fd 4 IS O_NONBLOCK
debug1: channel 0: new [X11 connection from my.server.name port 3106]
(here i see the X app load on my local system)


it doesn't always work. heres another attempt at forwarding
X over SSH:
nis-wa% netscape
debug1: client_input_channel_open: ctype x11 rchan 2 win 4096 max 2048
debug1: client_request_x11: request from 192.168.50.17 50121
debug1: fd 7 setting O_NONBLOCK
debug1: fd 7 IS O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
debug1: X11 client supplied no authorization data.
debug1: X11 auth rejected 1 i1/o16
debug1: channel 1: read failed
debug1: channel 1: input open - drain
debug1: channel 1: close_read
debug1: channel 1: write failed
debug1: channel 1: output open - closed
debug1: channel 1: close_write
debug1: X11 closed 1 i2/o128
debug1: client_input_channel_open: ctype x11 rchan 3 win 4096 max 2048
debug1: client_request_x11: request from 192.168.50.17 50122
debug1: fd 8 setting O_NONBLOCK
debug1: fd 8 IS O_NONBLOCK
debug1: channel 2: new [x11]
debug1: confirm x11
debug1: channel 1: ibuf empty
debug1: channel 1: input drain - closed
debug1: channel 1: send eof
debug1: channel 1: send close
debug1: channel 1: rcvd eof
debug1: X11 client supplied no authorization data.
debug1: X11 auth rejected 2 i1/o16
debug1: channel 2: read failed
debug1: channel 2: input open - drain
debug1: channel 2: close_read
debug1: channel 2: write failed
debug1: channel 2: output open - closed
debug1: channel 2: close_write
debug1: X11 closed 2 i2/o128
Xlib: client uses different protocol version (11) than server (0)!
Error: Can't open display: 192.168.50.17:10.0
debug1: channel 1: rcvd close
debug1: channel 1: is dead
debug1: channel_free: channel 1: status: The following connections are
open:  #0 client-session (t4 r0 i1/0 o16/0 fd 4/5)
  #1 x11 (t4 r2 i8/0 o128/0 fd 7/7)
  #2 x11 (t4 r3 i2/0 o128/0 fd 8/8)

debug1: channel 2: ibuf empty
debug1: channel 2: input drain - closed
debug1: channel 2: send eof
debug1: channel 2: send close
debug1: channel 2: rcvd eof
Xlib: client uses different protocol version (11) than server (0)!
Error: Can't open display: 192.168.50.17:10.0
debug1: channel 2: rcvd close
debug1: channel 2: is dead
debug1: channel_free: channel 2: status: The following connections are
open:  #0 client-session (t4 r0 i1/0 o16/8 fd 4/5)
  #2 x11 (t4 r3 i8/0 o128/0 fd 8/8)


i don't know how to fix the above problem. ive also
got other errors from time to time. it depends on
the version of SSH, the OS and suprisingly enough
the app. heres a sucessful X forward on the same
host as the one above(with the errror)

nis-wa% xclock
debug1: client_input_channel_open: ctype x11 rchan 2 win 4096 max 2048
debug1: client_request_x11: request from 192.168.50.17 50148
debug1: fd 7 setting O_NONBLOCK
debug1: fd 7 IS O_NONBLOCK
debug1: channel 1: new [x11]
debug1: confirm x11
(and the clock shows on my screen)

nothing changed, i didnt even logout, just typed xlcock
and off i go..

ive been at a loss as to why that is for quite some time.

nate