Re: Bluetooth/SSH issue

2024-06-16 Thread Jeffrey Walton 
On Sun, Jun 16, 2024 at 10:33 PM George at Clug  wrote:
>
> Rayan,
>
> On Monday, 17-06-2024 at 09:18 Ryan Nowakowski wrote:
> > On Sun, Jun 16, 2024 at 02:30:32PM -0600, Charles Curley wrote:
> > > On one of my machines, I have some interesting interference. Bluetooth
> > > works just fine, and so does networking. Bluetooth is normally disabled.
> > > However, when I have Bluetooth turned on (and after I turn it off), SSH
> > > is *slow*.
> > > Is there some sort of cross-talk issue?
> >
> > Sometimes Bluetooth and Wi-Fi share the same radio.  Are you running ssh 
> > over Wi-Fi?  Try running ssh over Ethernet while using Bluetooth.  Is ssh 
> > still slow?
>
> What do you mean by "Bluetooth and Wi-Fi share the same radio" ?
>
> In the early days of Windows 8 Tablet and laptop devices, I noticed that the 
> bluetooth mouse would move jerkily while a large download was happening over 
> Wi-Fi. Many people had this issue, and it was so annoying it lead me to tell 
> people not to use bluetooth mice.
>
> You comment might explain why this problem existed, though I am still not 
> sure what "share the same radio" actually means?

Both Wifi and Bluetooth use the globally unlicensed Industrial,
Scientific and Medical (ISM) 2.4 GHz short-range radio frequency band.

You can buy combo chips for the application. See, for example,
Qualcomm's QCA9377,
.

Jeff

Re: Bluetooth/SSH issue

2024-06-16 Thread eben 

On 6/16/24 19:27, George at Clug wrote:

Rayan,

On Monday, 17-06-2024 at 09:18 Ryan Nowakowski wrote:

On Sun, Jun 16, 2024 at 02:30:32PM -0600, Charles Curley wrote:

On one of my machines, I have some interesting interference. Bluetooth
works just fine, and so does networking. Bluetooth is normally disabled.
However, when I have Bluetooth turned on (and after I turn it off), SSH
is *slow*.
Is there some sort of cross-talk issue?


Sometimes Bluetooth and Wi-Fi share the same radio.  Are you running ssh over 
Wi-Fi?  Try running ssh over Ethernet while using Bluetooth.  Is ssh still slow?


What do you mean by "Bluetooth and Wi-Fi share the same radio" ?


There is some circuitry in the computer (the radio) that does both BT and
wifi (at least 2.4GHz wifi) in some cases, probably by toggling from one to
the other.  They share the same frequency, or are close enough that the same
electronics works.

--
O freddled gruntbuggly
Thy micturations are to me
As plurdled gabbleblotchits on a lurgid bee.  -- P. V. Jeltz

Re: Bluetooth/SSH issue

2024-06-16 Thread George at Clug 
Rayan,

On Monday, 17-06-2024 at 09:18 Ryan Nowakowski wrote:
> On Sun, Jun 16, 2024 at 02:30:32PM -0600, Charles Curley wrote:
> > On one of my machines, I have some interesting interference. Bluetooth
> > works just fine, and so does networking. Bluetooth is normally disabled.
> > However, when I have Bluetooth turned on (and after I turn it off), SSH
> > is *slow*.
> > Is there some sort of cross-talk issue?
> 
> Sometimes Bluetooth and Wi-Fi share the same radio.  Are you running ssh over 
> Wi-Fi?  Try running ssh over Ethernet while using Bluetooth.  Is ssh still 
> slow?

What do you mean by "Bluetooth and Wi-Fi share the same radio" ?

In the early days of Windows 8 Tablet and laptop devices, I noticed that the 
bluetooth mouse would move jerkily while a large download was happening over 
Wi-Fi. Many people had this issue, and it was so annoying it lead me to tell 
people not to use bluetooth mice.

You comment might explain why this problem existed, though I am still not sure 
what "share the same radio" actually means?

Thanks for your comment,

George.


> 
>

Re: Bluetooth/SSH issue

2024-06-16 Thread Ryan Nowakowski 
On Sun, Jun 16, 2024 at 02:30:32PM -0600, Charles Curley wrote:
> On one of my machines, I have some interesting interference. Bluetooth
> works just fine, and so does networking. Bluetooth is normally disabled.
> However, when I have Bluetooth turned on (and after I turn it off), SSH
> is *slow*.
> Is there some sort of cross-talk issue?

Sometimes Bluetooth and Wi-Fi share the same radio.  Are you running ssh over 
Wi-Fi?  Try running ssh over Ethernet while using Bluetooth.  Is ssh still slow?

Bluetooth/SSH issue

2024-06-16 Thread Charles Curley 
On one of my machines, I have some interesting interference. Bluetooth
works just fine, and so does networking. Bluetooth is normally disabled.
However, when I have Bluetooth turned on (and after I turn it off), SSH
is *slow*.

I gather that the network controller is also the Bluetooth controller:

root@tiassa:~# lspci -vs 2:0.0
02:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac 
PCIe Wireless Network Adapter
Subsystem: Realtek Semiconductor Co., Ltd. RTL8821CE 802.11ac PCIe 
Wireless Network Adapter
Flags: bus master, fast devsel, latency 0, IRQ 132, IOMMU group 10
I/O ports at 4000 [size=256]
Memory at 8050 (64-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 3
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [70] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [148] Device Serial Number 00-e0-4c-ff-fe-c8-21-01
Capabilities: [158] Latency Tolerance Reporting
Capabilities: [160] L1 PM Substates
Capabilities: [170] Precision Time Measurement
Capabilities: [17c] Vendor Specific Information: ID=0003 Rev=1 Len=054 

Kernel driver in use: rtw_8821ce
Kernel modules: rtw88_8821ce

root@tiassa:~# uname -a
Linux tiassa 6.6.13+bpo-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.13-1~bpo12+1 
(2024-02-15) x86_64 GNU/Linux
root@tiassa:~#

https://www.realtek.com/Product/Index?id=587

Is there some sort of cross-talk issue?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

Re: SSH issue?

2016-02-20 Thread Roman 
Hi,

You should enable kernel dump logs. auth log is worst place for searching
the cause of crashing.



2016-02-18 23:13 GMT+02:00 Chris :

> Dear All,
>
> after the following entry
>
> Feb 18 17:48:05 jupiter sshd[30204]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.88.177.93
> user=root
>
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
>
> my Jessie Server was down.
>
> Has anyone seen this? Went it accidentally down? Is this already an libc
> exploit?
>
> - Chris
>
>


-- 
Best regards,
Roman.

Re: SSH issue?

2016-02-18 Thread Reco 
On Thu, Feb 18, 2016 at 10:13:48PM +0100, Chris wrote:
> Dear All,
> 
> after the following entry
> 
> Feb 18 17:48:05 jupiter sshd[30204]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.88.177.93 
> user=root
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
> 
> my Jessie Server was down.
> 
> Has anyone seen this?

If you meant "failed ssh connections from CHINANET-GD IPs" - then yes.
Iptables works wonders for those - it's not that I plan visiting China
anytime soon :)
But if you meant "strange line of escape sequences in /var/log/auth.log"
- then no.


> Went it accidentally down?

Surely you know that auth.log is not the best place to search causes
of host reboots. I'd start with /var/log/kern.log. Maybe
/var/log/messages.


> Is this already an libc exploit?

Hardly. Recently patched CVE-2015-7547 (glibc getaddrinfo) could be used
for arbitrary code execution, but it would require crafted DNS records.
Of course, problematic DNS records could be served from whatever DNS
this host uses, but for me reverse DNS lookup for 125.88.177.93 ends
with NXDOMAIN.

Reco

Re: SSH issue?

2016-02-18 Thread Don Armstrong 
On Thu, 18 Feb 2016, Chris wrote:
> after the following entry
> 
> Feb 18 17:48:05 jupiter sshd[30204]: pam_unix(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=125.88.177.93 
> user=root
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
> 
> my Jessie Server was down.
> 
> Has anyone seen this? Went it accidentally down? Is this already an
> libc exploit?

This just looks like the serial terminal line got screwed up (probably
due to the restart/failure) some time after that line was printed.

-- 
Don Armstrong  http://www.donarmstrong.com

First you take a drink,
then the drink takes a drink,
then the drink takes you.
 -- F. Scott Fitzgerald

Re: ssh issue

2012-11-12 Thread Rainer Dorsch 
Hi Claudius,

Am Sunday 11 November 2012 schrieb Claudius Hubig:
 Hello Rainer,
 
 [ Removed useless crap from quote, cf.
 20122039.14270...@bokomoko.de for original ]
 
 Rainer Dorsch m...@bokomoko.de wrote:
  Am Sunday 11 November 2012 schrieb Selim T. Erdogan:
   Rainer Dorsch, 11.11.2012:
bokomoko:~# ls -l ~rd/.ssh/authorized_keys
~gpxrecorder/.ssh/authorized_hosts
/home/gpxrecorder/.ssh/authorized_hosts
 
 ^
 
/home/rd/.ssh/authorized_keys
 

 
  The miracle (for me) is that the
  configuration for both accounts seems to be absolutely identicalit
  certainly is not, but where is the difference hidden?
 
 It is not. authorized_keys != authorized_hosts, as Selim pointed out.
 Rename ~gpxrecorder/.ssh/authorized_hosts to
 ~gpxrecorder/.ssh/authorized_keys and try again.

Now I realize it, many many thanks for stressing that again. That issue drove 
me almost crazy

Rainer

-- 
Rainer Dorsch
http://bokomoko.de/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201211122243.44219...@bokomoko.de

Re: ssh issue

2012-11-12 Thread Kushal Kumaran 
Rainer Dorsch m...@bokomoko.de writes:

 Hi Claudius,

 Am Sunday 11 November 2012 schrieb Claudius Hubig:
 Hello Rainer,
 
 [ Removed useless crap from quote, cf.
 20122039.14270...@bokomoko.de for original ]
 
 Rainer Dorsch m...@bokomoko.de wrote:
  Am Sunday 11 November 2012 schrieb Selim T. Erdogan:
   Rainer Dorsch, 11.11.2012:
bokomoko:~# ls -l ~rd/.ssh/authorized_keys
~gpxrecorder/.ssh/authorized_hosts
/home/gpxrecorder/.ssh/authorized_hosts
 
 ^
 
/home/rd/.ssh/authorized_keys
 

 
  The miracle (for me) is that the
  configuration for both accounts seems to be absolutely identicalit
  certainly is not, but where is the difference hidden?
 
 It is not. authorized_keys != authorized_hosts, as Selim pointed out.
 Rename ~gpxrecorder/.ssh/authorized_hosts to
 ~gpxrecorder/.ssh/authorized_keys and try again.

 Now I realize it, many many thanks for stressing that again. That issue drove 
 me almost crazy


There's a ssh-copy-id script in the openssh-client package that you can
use to avoid mistakes like these.

-- 
regards,
kushal


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/87obj2kt09.fsf@nitrogen.i-did-not-set--mail-host-address--so-tickle-me

ssh issue

2012-11-11 Thread Rainer Dorsch 
Hello,

I have on a Debian squeeze server an issue, that I can only login as user rd, 
not as user gpxrecorder, although there seems to be no difference in the 
accounts:

bokomoko:~# diff ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts
bokomoko:~# ls -l ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts
-rw-r--r-- 1 gpxrecorder gpxrecorder 222 Nov 11 19:33 
/home/gpxrecorder/.ssh/authorized_hosts
-rw-r--r-- 1 rd  rd  222 Dec 30  2006 
/home/rd/.ssh/authorized_keys
bokomoko:~# ls -ld ~rd/.ssh ~gpxrecorder/.ssh
drwx-- 2 gpxrecorder gpxrecorder 4096 Nov 11 19:33 /home/gpxrecorder/.ssh
drwx-- 2 rd  rd  4096 Dec 25  2008 /home/rd/.ssh
bokomoko:~# ls -ld ~rd ~gpxrecorder
drwxr-x--x  5 gpxrecorder gpxrecorder 4096 Nov 11 19:33 /home/gpxrecorder
drwxr-x--x 52 rd  rd  4096 Nov 10 15:32 /home/rd
bokomoko:~# 

For gpxrecorder

debug1: Server accepts key: pkalg ssh-rsa blen 149

does not show up.

Any hint why the two accounts might behave differently are very welcome.

Many thanks,
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20122039.14270...@bokomoko.de

Re: ssh issue

2012-11-11 Thread staticsafe 
On 11/11/2012 14:39, Rainer Dorsch wrote:
 Hello,
 
 I have on a Debian squeeze server an issue, that I can only login as user rd, 
 not as user gpxrecorder, although there seems to be no difference in the 
 accounts:
 
 bokomoko:~# diff ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts
 bokomoko:~# ls -l ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts
 -rw-r--r-- 1 gpxrecorder gpxrecorder 222 Nov 11 19:33 
 /home/gpxrecorder/.ssh/authorized_hosts
 -rw-r--r-- 1 rd  rd  222 Dec 30  2006 
 /home/rd/.ssh/authorized_keys
 bokomoko:~# ls -ld ~rd/.ssh ~gpxrecorder/.ssh
 drwx-- 2 gpxrecorder gpxrecorder 4096 Nov 11 19:33 /home/gpxrecorder/.ssh
 drwx-- 2 rd  rd  4096 Dec 25  2008 /home/rd/.ssh
 bokomoko:~# ls -ld ~rd ~gpxrecorder
 drwxr-x--x  5 gpxrecorder gpxrecorder 4096 Nov 11 19:33 /home/gpxrecorder
 drwxr-x--x 52 rd  rd  4096 Nov 10 15:32 /home/rd
 bokomoko:~# 
 
 For gpxrecorder
 
 debug1: Server accepts key: pkalg ssh-rsa blen 149
 
 does not show up.
 
 Any hint why the two accounts might behave differently are very welcome.
 
 Many thanks,
 Rainer
 

Can you try doing `ssh -vvv gpxrecorder@hostname` and pastie the output?
Also check for any errors on the squeeze server's /var/log/auth.log.
-- 
staticsafe
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post - http://goo.gl/YrmAb


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a00c14.3070...@staticsafe.ca

Re: ssh issue

2012-11-11 Thread Selim T. Erdogan 
Rainer Dorsch, 11.11.2012:
 Hello,
 
 I have on a Debian squeeze server an issue, that I can only login as user rd, 
 not as user gpxrecorder, although there seems to be no difference in the 
 accounts:
 
 bokomoko:~# diff ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts
 bokomoko:~# ls -l ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts
 -rw-r--r-- 1 gpxrecorder gpxrecorder 222 Nov 11 19:33 
 /home/gpxrecorder/.ssh/authorized_hosts
 -rw-r--r-- 1 rd  rd  222 Dec 30  2006 
 /home/rd/.ssh/authorized_keys

How come you're diffing authorized_keys for rd and authorized_hosts for 
gpxrecorder?  Are the contents of those supposed to be the same?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012205205.ga...@cs.utexas.edu

Re: ssh issue

2012-11-11 Thread David Christensen 

On 11/11/12 11:39, Rainer Dorsch wrote:

I have on a Debian squeeze server an issue, that I can only login as user rd,
not as user gpxrecorder, although there seems to be no difference in the
accounts:
bokomoko:~# diff ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts


Have you generated SSH keys for the gpxrecorder account?


HTH,

David


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/50a00f9b.1020...@holgerdanske.com

Re: ssh issue

2012-11-11 Thread Rainer Dorsch 
Am Sunday 11 November 2012 schrieb staticsafe:
 On 11/11/2012 14:39, Rainer Dorsch wrote:
  Hello,
  
  I have on a Debian squeeze server an issue, that I can only login as user
  rd, not as user gpxrecorder, although there seems to be no difference in
  the accounts:
  
  bokomoko:~# diff ~rd/.ssh/authorized_keys
  ~gpxrecorder/.ssh/authorized_hosts bokomoko:~# ls -l
  ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts -rw-r--r-- 1
  gpxrecorder gpxrecorder 222 Nov 11 19:33
  /home/gpxrecorder/.ssh/authorized_hosts
  -rw-r--r-- 1 rd  rd  222 Dec 30  2006
  /home/rd/.ssh/authorized_keys
  bokomoko:~# ls -ld ~rd/.ssh ~gpxrecorder/.ssh
  drwx-- 2 gpxrecorder gpxrecorder 4096 Nov 11 19:33
  /home/gpxrecorder/.ssh drwx-- 2 rd  rd  4096 Dec 25 
  2008 /home/rd/.ssh bokomoko:~# ls -ld ~rd ~gpxrecorder
  drwxr-x--x  5 gpxrecorder gpxrecorder 4096 Nov 11 19:33 /home/gpxrecorder
  drwxr-x--x 52 rd  rd  4096 Nov 10 15:32 /home/rd
  bokomoko:~#
  
  For gpxrecorder
  
  debug1: Server accepts key: pkalg ssh-rsa blen 149
  
  does not show up.
  
  Any hint why the two accounts might behave differently are very welcome.
  
  Many thanks,
  Rainer
 
 Can you try doing `ssh -vvv gpxrecorder@hostname` and pastie the output?
 Also check for any errors on the squeeze server's /var/log/auth.log.

An ssh agent is running and has the keys

rd@blackbox:~/SW.nobackup/navit-clean-build/navit$ ssh-add -l
1024 c5:41:03:c6:ef:9e:d3:e4:39:dc:74:88:2b:78:bb:05 /home/rd/.ssh/id_rsa 
(RSA)
rd@blackbox:~/SW.nobackup/navit-clean-build/navit$ ssh -vvv 
gpxrecor...@bokomoko.de
OpenSSH_6.0p1 Debian-3, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/rd/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to bokomoko.de [87.118.104.111] port 22.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load /home/rd/.ssh/id_rsa as a RSA1 public key
debug1: identity file /home/rd/.ssh/id_rsa type -1
debug1: identity file /home/rd/.ssh/id_rsa-cert type -1
debug1: identity file /home/rd/.ssh/id_dsa type -1
debug1: identity file /home/rd/.ssh/id_dsa-cert type -1
debug1: identity file /home/rd/.ssh/id_ecdsa type -1
debug1: identity file /home/rd/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.5p1 
Debian-6+squeeze2
debug1: match: OpenSSH_5.5p1 Debian-6+squeeze2 pat OpenSSH_5*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3
debug2: fd 3 setting O_NONBLOCK
debug3: load_hostkeys: loading entries for host bokomoko.de from file 
/home/rd/.ssh/known_hosts
debug3: load_hostkeys: found key type RSA in file /home/rd/.ssh/known_hosts:334
debug3: load_hostkeys: loaded 1 keys
debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-
v...@openssh.com,ssh-rsa-cert-...@openssh.com,ssh-rsa
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-
nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-
sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-...@openssh.com,ssh-rsa-cert-
v...@openssh.com,ssh-rsa,ecdsa-sha2-nistp256-cert-...@openssh.com,ecdsa-sha2-
nistp384-cert-...@openssh.com,ecdsa-sha2-nistp521-cert-...@openssh.com,ssh-
dss-cert-...@openssh.com,ssh-dss-cert-...@openssh.com,ecdsa-sha2-
nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-
cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-
ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-
cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-
sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-
ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-
sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-
ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit: none,z...@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-
group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-

Re: ssh issue

2012-11-11 Thread Neal Murphy 
On Sunday, November 11, 2012 02:39:14 PM Rainer Dorsch wrote:
 Hello,
 
 I have on a Debian squeeze server an issue, that I can only login as user
 rd, not as user gpxrecorder, although there seems to be no difference in
 the accounts:

I'll bet some key files in .ssh/ are readable by other than the owner. Nothing 
in .ssh (and the dir itself) should have 'group' or 'other' perms set. Try:
  chmod -R g-rwx,o-rwx /home/gpxrecorder/.ssh
You should do that for /home/rd/.ssh as well.

If you have the file '.ssh/config', check it for oddities.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121650.29545.neal.p.mur...@alum.wpi.edu

Re: ssh issue

2012-11-11 Thread Rainer Dorsch 
Am Sunday 11 November 2012 schrieb Selim T. Erdogan:
 Rainer Dorsch, 11.11.2012:
  Hello,
  
  I have on a Debian squeeze server an issue, that I can only login as user
  rd, not as user gpxrecorder, although there seems to be no difference in
  the accounts:
  
  bokomoko:~# diff ~rd/.ssh/authorized_keys
  ~gpxrecorder/.ssh/authorized_hosts bokomoko:~# ls -l
  ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts -rw-r--r-- 1
  gpxrecorder gpxrecorder 222 Nov 11 19:33
  /home/gpxrecorder/.ssh/authorized_hosts
  -rw-r--r-- 1 rd  rd  222 Dec 30  2006
  /home/rd/.ssh/authorized_keys
 
 How come you're diffing authorized_keys for rd and authorized_hosts for
 gpxrecorder?  Are the contents of those supposed to be the same?

Yes, I want to login at both accounts from my machine at home. One (rd) works 
the other (gpxrecorder) does not. The miracle (for me) is that the 
configuration for both accounts seems to be absolutely identicalit 
certainly is not, but where is the difference hidden?

Rainer

-- 
Rainer Dorsch
http://bokomoko.de/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20122246.54450...@bokomoko.de

Re: ssh issue

2012-11-11 Thread Rainer Dorsch 
Am Sunday 11 November 2012 schrieb David Christensen:
 On 11/11/12 11:39, Rainer Dorsch wrote:
  I have on a Debian squeeze server an issue, that I can only login as user
  rd, not as user gpxrecorder, although there seems to be no difference in
  the accounts:
  bokomoko:~# diff ~rd/.ssh/authorized_keys
  ~gpxrecorder/.ssh/authorized_hosts
 
 Have you generated SSH keys for the gpxrecorder account?
 

Hmm...authorized_keys contain keys from the user who wants to login. I does 
not make sense to generate keys for the gpxrecorder account (?).

Rainer


-- 
Rainer Dorsch
http://bokomoko.de/


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20122248.09589...@bokomoko.de

Re: ssh issue

2012-11-11 Thread staticsafe 
On 11/11/2012 16:44, Rainer Dorsch wrote:
 Am Sunday 11 November 2012 schrieb staticsafe:
 On 11/11/2012 14:39, Rainer Dorsch wrote:
 Hello,

 I have on a Debian squeeze server an issue, that I can only login as user
 rd, not as user gpxrecorder, although there seems to be no difference in
 the accounts:

 bokomoko:~# diff ~rd/.ssh/authorized_keys
 ~gpxrecorder/.ssh/authorized_hosts bokomoko:~# ls -l
 ~rd/.ssh/authorized_keys ~gpxrecorder/.ssh/authorized_hosts -rw-r--r-- 1
 gpxrecorder gpxrecorder 222 Nov 11 19:33
 /home/gpxrecorder/.ssh/authorized_hosts
 -rw-r--r-- 1 rd  rd  222 Dec 30  2006
 /home/rd/.ssh/authorized_keys
 bokomoko:~# ls -ld ~rd/.ssh ~gpxrecorder/.ssh
 drwx-- 2 gpxrecorder gpxrecorder 4096 Nov 11 19:33
 /home/gpxrecorder/.ssh drwx-- 2 rd  rd  4096 Dec 25 
 2008 /home/rd/.ssh bokomoko:~# ls -ld ~rd ~gpxrecorder
 drwxr-x--x  5 gpxrecorder gpxrecorder 4096 Nov 11 19:33 /home/gpxrecorder
 drwxr-x--x 52 rd  rd  4096 Nov 10 15:32 /home/rd
 bokomoko:~#

 For gpxrecorder

 debug1: Server accepts key: pkalg ssh-rsa blen 149

 does not show up.

 Any hint why the two accounts might behave differently are very welcome.

 Many thanks,
 Rainer

 Can you try doing `ssh -vvv gpxrecorder@hostname` and pastie the output?
 Also check for any errors on the squeeze server's /var/log/auth.log.
 
 An ssh agent is running and has the keys
 
 rd@blackbox:~/SW.nobackup/navit-clean-build/navit$ ssh-add -l
 1024 c5:41:03:c6:ef:9e:d3:e4:39:dc:74:88:2b:78:bb:05 /home/rd/.ssh/id_rsa 
 (RSA)
 rd@blackbox:~/SW.nobackup/navit-clean-build/navit$ ssh -vvv 
 gpxrecor...@bokomoko.de
 *snip*
 Enter passphrase for key '/home/rd/.ssh/id_rsa': 
 
 No entry in /var/log/auth.log until here.
 
 Thanks,
 Rainer
 

I'm not seeing anything wrong in the output you pasted, what happens
after you type in the passphrase for the id_rsa key?

-- 
staticsafe
O ascii ribbon campaign - stop html mail - www.asciiribbon.org
Please don't top post - http://goo.gl/YrmAb


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50a0254f.2070...@staticsafe.ca

Re: ssh issue

2012-11-11 Thread David Christensen 

On 11/11/12 13:48, Rainer Dorsch wrote:

Hmm...authorized_keys contain keys from the user who wants to login. I does
not make sense to generate keys for the gpxrecorder account (?).


I typically create user keys on both ends.  The O/S installer and/or 
package manager typically create host keys on both ends for me.  When I 
get everything else right, SSH works.



I suggest creating user keys for gpxrecorder on the server.


David


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/50a0252a.5000...@holgerdanske.com

Re: ssh issue

2012-11-11 Thread David Christensen 

Am Sunday 11 November 2012 schrieb Selim T. Erdogan:

How come you're diffing authorized_keys for rd and authorized_hosts for
gpxrecorder?


Good eyes.  I use only authorized_keys on my machines.


I suggest renaming authorized_hosts to authorized_keys for gpxrecorder.


David


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/50a025e4.6070...@holgerdanske.com

Re: ssh issue

2012-11-11 Thread Claudius Hubig 
Hello Rainer,

[ Removed useless crap from quote, cf.
20122039.14270...@bokomoko.de for original ]

Rainer Dorsch m...@bokomoko.de wrote:
 Am Sunday 11 November 2012 schrieb Selim T. Erdogan:
  Rainer Dorsch, 11.11.2012:
   bokomoko:~# ls -l ~rd/.ssh/authorized_keys 
   ~gpxrecorder/.ssh/authorized_hosts
   /home/gpxrecorder/.ssh/authorized_hosts
^
   /home/rd/.ssh/authorized_keys
   
 The miracle (for me) is that the 
 configuration for both accounts seems to be absolutely identicalit 
 certainly is not, but where is the difference hidden?

It is not. authorized_keys != authorized_hosts, as Selim pointed out.
Rename ~gpxrecorder/.ssh/authorized_hosts to
~gpxrecorder/.ssh/authorized_keys and try again.

Best,

Claudius


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2012222304.683cb...@ares.home.chubig.net

Re: ssh issue

2012-11-11 Thread Chris Bannister 
On Sun, Nov 11, 2012 at 02:22:34PM -0800, David Christensen wrote:
 On 11/11/12 13:48, Rainer Dorsch wrote:
 Hmm...authorized_keys contain keys from the user who wants to login. I does
 not make sense to generate keys for the gpxrecorder account (?).
 
 I typically create user keys on both ends.  The O/S installer and/or
 package manager typically create host keys on both ends for me.
 When I get everything else right, SSH works.
 
 
 I suggest creating user keys for gpxrecorder on the server.

Why? If the client machine is never going to have anyone
ssh'ing into it, it doesn't need ssh-server installed. 

If any users on the server machine are never going to ssh into any other
machine, then keys never need to be generated for any of those users.

-- 
If you're not careful, the newspapers will have you hating the people
who are being oppressed, and loving the people who are doing the 
oppressing. --- Malcolm X


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121112042318.GM27514@tal

Re: SSH Issue

2011-03-13 Thread Michael Thompson 
On 13 March 2011 02:28, Adrian Levi adrian.l...@gmail.com wrote:
 On the server to get key based auth working you must:
 1)Have the correct permissions on .ssh/*

Permissions on all ~/.ssh are fine and correct at 0644

 2) have your public key in authorized_keys

Both authorized_keys on the server and client have been deleted.
without anyting in the ~ ssh directorys it allows login via password.
As soon as key-gen -t rsa is performed on the client, the server
disallows login, unless ssh -o PreferredAuthentications=password -l
user server_address is used.

Is there another file the server may of stored the key in, which I'm unaware of?


 On the client you need to have your key decripted for use either by:
 1) using agent
 2) having an empty password string in your private key.

Empty password in the actual keyfile.

 3) correct .ssh/* permissions.

 How many keys are in your server authorized_keys file? can you trim it
 down to just one for testing?

Its empty. (~/.ssh)

 What sort of changes have you made to the default sshd.conf file on
 the server and ssh.conf file on the client.

None, apart from diasallow root logins.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/AANLkTi=moe5l2az5b+86frme3e3-ovl48j8a3dshn...@mail.gmail.com

Re: SSH Issue

2011-03-13 Thread Michael Thompson 
This is now solved. MaxAuthRetries was set to 1, so when the server
rejected the ID, it exceeded the value.

Increasing this amount so the server could procede to password
interactive login worked and let me send the new keyfile to server.

Thanks for all your help.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/aanlktineaueedq4_ovcrfxkjj_vgv7uyejna8dypn...@mail.gmail.com

SSH Issue

2011-03-12 Thread Michael Thompson 
I've got a slight issue with logging into my server using public keys.

It was working fine, until I had to rebuild my desktop machine. I had
the key copied to the server, and passwordless logins where fine.

However now I have rebuilt my desktop, I cant get to the login.

So heres whats happend.

Rebuilt id_rsa.pub, server will not allow login. Remove id_rsa.pub and
the server allows password based login.

On the server, removed authorized_keys and known_hosts. makes no
difference. Server still disallows keyfile, but will allow password
when id_rsa is not present on the client.

Heres a -v of the login chat with keyfile

Code:

michael@eve:~$ ssh -v server
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server [ser.ver.ip] port 22.
debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type -1
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 none
debug1: kex: client-server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'host' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/michael/.ssh/id_rsa
Received disconnect from ser.ver.ip: 2: Too many authentication
failures for michael

And without

Code:

michael@eve:~/.ssh$ ssh -v server
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server [ser.ver.ip] port 22.
debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type -1
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type -1
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 none
debug1: kex: client-server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'server' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/michael/.ssh/id_rsa
debug1: Trying private key: /home/michael/.ssh/id_dsa
debug1: Next authentication method: password
michael@server's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
Linux s15433632 2.6.18-028stab070.4 #1 SMP Tue Aug 17 18:32:47 MSD 2010 x86_64

So, is there anyway of getting the server to forget the previous keys,
it is remembering, As previousily said, I have completly removed the
contents of ~/.ssh/ on both the clients and the server.
__

--
Michael
http://photography.thompsonm.me.uk

To see a World in a Grain of Sand
And a Heaven in a Wild Flower,
Hold Infinity in the palm of your hand
And Eternity in an hour.
--William Blake


-- 
To UNSUBSCRIBE, email to

SSH Issue

2011-03-12 Thread Michael Thompson 
I've got a slight issue with logging into my server using public keys.

It was working fine, until I had to rebuild my desktop machine. I had
the key copied to the server, and passwordless logins where fine.

However now I have rebuilt my desktop, I cant get to the login.

So heres whats happend.

Rebuilt id_rsa.pub, server will not allow login. Remove id_rsa.pub and
the server allows password based login.

On the server, removed authorized_keys and known_hosts. makes no
difference. Server still disallows keyfile, but will allow password
when id_rsa is not present on the client.

Heres a -v of the login chat with keyfile

Code:

michael@eve:~$ ssh -v server
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server [ser.ver.ip] port 22.
debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type -1
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 none
debug1: kex: client-server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'host' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering public key: /home/michael/.ssh/id_rsa
Received disconnect from ser.ver.ip: 2: Too many authentication
failures for michael

And without

Code:

michael@eve:~/.ssh$ ssh -v server
OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to server [ser.ver.ip] port 22.
debug1: Connection established.
debug1: identity file /home/michael/.ssh/id_rsa type -1
debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
debug1: identity file /home/michael/.ssh/id_dsa type -1
debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version
OpenSSH_5.1p1 Debian-5
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server-client aes128-ctr hmac-md5 none
debug1: kex: client-server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'server' is known and matches the RSA host key.
debug1: Found key in /home/michael/.ssh/known_hosts:1
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/michael/.ssh/id_rsa
debug1: Trying private key: /home/michael/.ssh/id_dsa
debug1: Next authentication method: password
michael@server's password:
debug1: Authentication succeeded (password).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_GB.UTF-8
Linux s15433632 2.6.18-028stab070.4 #1 SMP Tue Aug 17 18:32:47 MSD 2010 x86_64

So, is there anyway of getting the server to forget the previous keys,
it is remembering, As previousily said, I have completly removed the
contents of ~/.ssh/ on both the clients and the server.
__

-- 
Michael
http://photography.thompsonm.me.uk

To see a World in a Grain of Sand
And a Heaven in a Wild Flower,
Hold Infinity in the palm of your hand
And Eternity in an hour.
--William Blake


-- 
To UNSUBSCRIBE, email to

Re: SSH Issue

2011-03-12 Thread Aéris 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 13/03/2011 00:00, Michael Thompson a écrit :
 I've got a slight issue with logging into my server using public keys.

Could you paste the output of « grep sshd /var/log/auth.log »?

- -- 
Aeris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNfBBrAAoJEK8zQvxDY4P9qjcIAK+zPC6kh/3HhXMzsnSE1S2U
LW4zH0Uga302IFY6YqmnX7MXWTLJFqYpuMt0HZ1plf1vDhgMTyRY1jY2zlohTDG4
0mgrfQURtw51pQc/ZL5maV2tceYB0Huxe2grgXUdtw0Av/O/dcqSuSR4vfwG5eSl
GmCDE1A07jX01jnknUfVHD2RNknzwEmRHbdmLz98YYrAGAA6cGArTg/K4MFqX4rI
jwcWf/asyy07wMDElMqVD5ewWjZTnyPPEU/rTpqWgiab4cBYx3fAkoXFQH8PM3vL
/4XxiCqsFPRRz5CV53LbrLfMqui+ErVxvoaAxJ3s2//xuG/Y9227FgxVMTMgADo=
=xvej
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d7c106b$0$689$426a7...@news.free.fr

Re: SSH Issue

2011-03-12 Thread Adrian Levi 
On 13 March 2011 08:37, Michael Thompson maverickapo...@gmail.com wrote:
 I've got a slight issue with logging into my server using public keys.

 It was working fine, until I had to rebuild my desktop machine. I had
 the key copied to the server, and passwordless logins where fine.

 However now I have rebuilt my desktop, I cant get to the login.

 So heres whats happend.

 Rebuilt id_rsa.pub, server will not allow login. Remove id_rsa.pub and
 the server allows password based login.

 On the server, removed authorized_keys and known_hosts. makes no
 difference. Server still disallows keyfile, but will allow password
 when id_rsa is not present on the client.

On the server to get key based auth working you must:
1)Have the correct permissions on .ssh/*
2) have your public key in authorized_keys

On the client you need to have your key decripted for use either by:
1) using agent
2) having an empty password string in your private key.
3) correct .ssh/* permissions.

How many keys are in your server authorized_keys file? can you trim it
down to just one for testing?
What sort of changes have you made to the default sshd.conf file on
the server and ssh.conf file on the client.

Adrian



 Heres a -v of the login chat with keyfile

 Code:

 michael@eve:~$ ssh -v server
 OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
 debug1: Reading configuration data /etc/ssh/ssh_config
 debug1: Applying options for *
 debug1: Connecting to server [ser.ver.ip] port 22.
 debug1: Connection established.
 debug1: identity file /home/michael/.ssh/id_rsa type 1
 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
 debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
 debug1: identity file /home/michael/.ssh/id_dsa type -1
 debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
 debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.1p1 Debian-5
 debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
 debug1: Enabling compatibility mode for protocol 2.0
 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
 debug1: SSH2_MSG_KEXINIT sent
 debug1: SSH2_MSG_KEXINIT received
 debug1: kex: server-client aes128-ctr hmac-md5 none
 debug1: kex: client-server aes128-ctr hmac-md5 none
 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
 debug1: Host 'host' is known and matches the RSA host key.
 debug1: Found key in /home/michael/.ssh/known_hosts:1
 debug1: ssh_rsa_verify: signature correct
 debug1: SSH2_MSG_NEWKEYS sent
 debug1: expecting SSH2_MSG_NEWKEYS
 debug1: SSH2_MSG_NEWKEYS received
 debug1: Roaming not allowed by server
 debug1: SSH2_MSG_SERVICE_REQUEST sent
 debug1: SSH2_MSG_SERVICE_ACCEPT received
 debug1: Authentications that can continue: publickey,password
 debug1: Next authentication method: publickey
 debug1: Offering public key: /home/michael/.ssh/id_rsa
 Received disconnect from ser.ver.ip: 2: Too many authentication
 failures for michael

 And without

 Code:

 michael@eve:~/.ssh$ ssh -v server
 OpenSSH_5.5p1 Debian-6, OpenSSL 0.9.8o 01 Jun 2010
 debug1: Reading configuration data /etc/ssh/ssh_config
 debug1: Applying options for *
 debug1: Connecting to server [ser.ver.ip] port 22.
 debug1: Connection established.
 debug1: identity file /home/michael/.ssh/id_rsa type -1
 debug1: identity file /home/michael/.ssh/id_rsa-cert type -1
 debug1: identity file /home/michael/.ssh/id_dsa type -1
 debug1: identity file /home/michael/.ssh/id_dsa-cert type -1
 debug1: Remote protocol version 2.0, remote software version
 OpenSSH_5.1p1 Debian-5
 debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*
 debug1: Enabling compatibility mode for protocol 2.0
 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6
 debug1: SSH2_MSG_KEXINIT sent
 debug1: SSH2_MSG_KEXINIT received
 debug1: kex: server-client aes128-ctr hmac-md5 none
 debug1: kex: client-server aes128-ctr hmac-md5 none
 debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
 debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
 debug1: Host 'server' is known and matches the RSA host key.
 debug1: Found key in /home/michael/.ssh/known_hosts:1
 debug1: ssh_rsa_verify: signature correct
 debug1: SSH2_MSG_NEWKEYS sent
 debug1: expecting SSH2_MSG_NEWKEYS
 debug1: SSH2_MSG_NEWKEYS received
 debug1: Roaming not allowed by server
 debug1: SSH2_MSG_SERVICE_REQUEST sent
 debug1: SSH2_MSG_SERVICE_ACCEPT received
 debug1: Authentications that can continue: publickey,password
 debug1: Next authentication method: publickey
 debug1: Trying private key: /home/michael/.ssh/id_rsa
 debug1: Trying private key: /home/michael/.ssh/id_dsa
 debug1: Next authentication method: password
 michael@server's password:
 debug1: Authentication succeeded (password).
 debug1: channel 0: new