On Tuesday 31 May 2016 23:56:02 Richard Hector wrote:
> On 01/06/16 07:31, Lisi Reisz wrote:
> > Now to do what I really wanted to do all along, and ssh in to run level
> > one as root:
> >
> > lisi@Tux-II:~$ ssh root@192.168.0.5
> > ssh: connect to host 192.168.0.5 port 22: No route to host
> > li
On Tue, May 31, 2016, at 15:31, Lisi Reisz wrote:
> ...
> So I need static IPs fast!
> ...
(The above was actually quoted from an earlier post).
If you want to convert your computers to use static IP addresses, you might
want to take a look at the following web page:
http://www.stevesdebianstu
On 01/06/16 07:31, Lisi Reisz wrote:
> Now to do what I really wanted to do all along, and ssh in to run level one
> as
> root:
>
> lisi@Tux-II:~$ ssh root@192.168.0.5
> ssh: connect to host 192.168.0.5 port 22: No route to host
> lisi@Tux-II:~$ ssh lisi@192.168.0.5
Run level one? AKA single us
On Tuesday 31 May 2016 21:51:30 Joe wrote:
> On Tue, 31 May 2016 20:31:32 +0100
>
> Lisi Reisz wrote:
> > ---
> > Now to do what I really wanted to do all along, and ssh in to run
> > level one as root:
> >
> > lisi@Tux-II:~$ ssh root@192.168.0.5
> > ssh
On Tue, 31 May 2016 20:31:32 +0100
Lisi Reisz wrote:
> ---
> Now to do what I really wanted to do all along, and ssh in to run
> level one as root:
>
> lisi@Tux-II:~$ ssh root@192.168.0.5
> ssh: connect to host 192.168.0.5 port 22: No route to host
>
On Thursday 31 March 2016 15:08:24 Brian wrote:
> On Thu 31 Mar 2016 at 13:27:35 +0100, Lisi Reisz wrote:
> > On Thursday 31 March 2016 12:28:57 to...@tuxteam.de wrote:
> > > 1. Each computer should have an SSH server running (on Debian that
> > > would be package openssh-server: in Debian it has p
On Thu 31 Mar 2016 at 14:34:47 (+0200), to...@tuxteam.de wrote:
> On Thu, Mar 31, 2016 at 01:27:35PM +0100, Lisi Reisz wrote:
> > It is installed and running. I can ssh from Eros, but not into it. If I
> > just
> > try to ssh from Tux-II to Eros, I get the error "Could not connect to host
> >
On Thu, 31 Mar 2016, Lisi Reisz wrote:
So I need static IPs fast! or a hosts file?
That's how I do it. Only make that "or" above an "and!"
Also, liberal use of public-keys practically automates the whole
thing, so that you don't have to bother with pesky passwords on
your private 'net.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Mar 31, 2016 at 02:40:58PM +0100, Brian wrote:
> On Thu 31 Mar 2016 at 14:38:05 +0200, to...@tuxteam.de wrote:
>
> > On Thu, Mar 31, 2016 at 01:32:05PM +0100, Brian wrote:
> >
> > [...]
> >
> > > There is also dropbear as a lightweight SSH2
On Thu 31 Mar 2016 at 13:27:35 +0100, Lisi Reisz wrote:
> On Thursday 31 March 2016 12:28:57 to...@tuxteam.de wrote:
>
> > 1. Each computer should have an SSH server running (on Debian that would
> >be package openssh-server: in Debian it has priority "optional": I'd
> >double-check that
On Thu 31 Mar 2016 at 14:38:05 +0200, to...@tuxteam.de wrote:
> On Thu, Mar 31, 2016 at 01:32:05PM +0100, Brian wrote:
>
> [...]
>
> > There is also dropbear as a lightweight SSH2 server and client. Using
> > it in preference to openssh is useful for resource constrained machines.
>
> Yes, ther
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Mar 31, 2016 at 01:32:05PM +0100, Brian wrote:
[...]
> There is also dropbear as a lightweight SSH2 server and client. Using
> it in preference to openssh is useful for resource constrained machines.
Yes, there are nifty tricks like embeddin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Mar 31, 2016 at 01:27:35PM +0100, Lisi Reisz wrote:
> Great! Thankl you! I now have a starting point for my questions.
>
> On Thursday 31 March 2016 12:28:57 to...@tuxteam.de wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
>
On Thu 31 Mar 2016 at 13:28:57 +0200, to...@tuxteam.de wrote:
> On Thu, Mar 31, 2016 at 12:43:49PM +0100, Lisi Reisz wrote:
> > I want all the computers on my private network to be able to shh into each
> > other. In Jessie, what do I have to do where in what config file?
> > Presumably some p
Great! Thankl you! I now have a starting point for my questions.
On Thursday 31 March 2016 12:28:57 to...@tuxteam.de wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Thu, Mar 31, 2016 at 12:43:49PM +0100, Lisi Reisz wrote:
> > I want all the computers on my private network to be a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Mar 31, 2016 at 12:43:49PM +0100, Lisi Reisz wrote:
> I want all the computers on my private network to be able to shh into each
> other. In Jessie, what do I have to do where in what config file?
> Presumably some port is shut??
0. Each c
Just for complement, compare these ssh security tips:
Secure Secure Shell
https://stribika.github.io/2015/01/04/secure-secure-shell.html
Regards,
jvp.
Hi.
On Sun, 21 Feb 2016 02:29:01 +0100
arian wrote:
> > Because you can install ssh client without a server, but a
> > ssh server without a client on the same host is not of much use to
> > anyone.
>
> Is that so? I have a couple of hosts where I cannot remember runner ssh
> myself eve
On 20.02.2016 20:23, Reco wrote:
> The way I see it, ssh-keygen merely generates *possible* prime numbers,
> as correct checking for primeness (sp?) would require very long and
> very CPU intensive checking - basically you'd have to divide generated
> number by each and any number less than gener
On Sat, Feb 20, 2016 at 10:23:26PM +0300, Reco wrote:
> Hi.
>
> On Sat, 20 Feb 2016 19:50:54 +0100
> Daniel wrote:
>
> > I have followed the instructions under "MODULI GENERATION" in the
> > "ssh-keygen" man page.
> > The resulting "moduli-2048" file is considerably smaller than the one
Hi.
On Sat, 20 Feb 2016 19:50:54 +0100
Daniel wrote:
> I have followed the instructions under "MODULI GENERATION" in the
> "ssh-keygen" man page.
> The resulting "moduli-2048" file is considerably smaller than the one
> provided with the
> "openssh-client" package. I have a few questio
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=ss
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
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
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
> ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
It helps to explain things, Daniel, but truly, the client in question
is horrendously out of date and deprecated for all secure intents and
purposes, I'm quite happy to retire it from active support on my
server.
On Sat, 16 Jan 2016 15:19:33 -0300, you wrote:
>Hi, Steve.
>
>On 14/01/16 13:10, Ste
Daniel,
On Sat, 16 Jan 2016 14:50:20 -0300, you wrote:
>I'm sorry. I Had forgotten of the detail of the accessibility :(
No worries. Things are in a sorry state at the moment because of other
things I did without realizing I did them, but I've already told my
usership that Voyager will have to g
Hi, Steve.
On 14/01/16 13:10, Steve Matzura wrote:
> Failing connection:
> (...)
> no matching cipher found: client
> aes192-cbc,3des-cbc,blowfish-cbc,aes128-cbc,aes256-cbc,rijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-...@lysator.liu.se,des-cbc,des-...@ssh.com
> server
> aes128-ctr,ae
Hi, Steve.
On 14/01/16 13:01, Steve Matzura wrote:
>> I do not know that client, but if your users are using Firefox, maybe
>> you could use FireFTP [1]. I never had problems with it, and we could
>> also say that while users use Firefox, you could run it on different
>> operating systems.
> It
The problem is that the older client doesn't support ciphers newer than CBC
and arcfour (both depreciated on the newer server versions of OpenSSH).
Lookup how to re-enable these suites using the Cipher directive.
One more piece of the puzzle. The working system is Red Hat Fedora 20,
the non-working one is Debian 8.2.
More info. I used getenforce' and found SELinux is installed but
disabled on the system where FTP Voyager can connect using SFTP over
ssh, and not installed at all on the system where FTP Voyager cannot
connect. In fact, using either the `getenforce' or `'sestatus' on the
no-connect system yields `
Daniel,
On Thu, 14 Jan 2016 09:05:36 -0300, you wrote:
>Hi, Steve.
>
>On 14/01/16 08:45, Steve Matzura wrote:
>
>> This is clearly the problem area. I tried some ssh option settings in
>> Voyager with no success. Should this client be retired? It's not
>> *that* old.
>
>I do not know that client,
I decided to put the two logs from `sshd -d' side-by-side to try to
figure out where the differences are. Both logs have the following
lines immediately after the connection request:
debug1: Client protocol version 2.0; client software version
FTP-Voyager-15.2.0.15
debug1: no match: FTP-Voyager-15
Hi, Steve.
On 14/01/16 08:45, Steve Matzura wrote:
> This is clearly the problem area. I tried some ssh option settings in
> Voyager with no success. Should this client be retired? It's not
> *that* old.
I do not know that client, but if your users are using Firefox, maybe
you could use FireFTP
Lars,
On Thu, 14 Jan 2016 12:45:09 +0200, you wrote:
>Can you update the client to one that uses the safer ciphers and avoids
>the deprecated ones?
You and I came to the same conclusion with the same lines of log as
evidence at about the same time. Amazing.
Many of my users use Voyager version
Tomas,
On Thu, 14 Jan 2016 05:32:04 -0500, I wrote:
>debug1: Enabling compatibility mode for protocol 2.0
>debug1: Local version string SSH-2.0-OpenSSH_6.7p1 Debian-5
>debug1: permanently_set_uid: 107/65534 [preauth]
>debug1: list_hostkey_types:
>ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [p
On 01/14/2016 12:32 PM, Steve Matzura wrote:
> debug1: sshd version OpenSSH_6.7, OpenSSL 1.0.1k 8 Jan 2015
>...
> debug1: Client protocol version 2.0; client software version
> FTP-Voyager-15.2.0.15
> debug1: no match: FTP-Voyager-15.2.0.15
> debug1: Enabling compatibility mode for protocol 2.0
> .
Tomas,
On Wed, Jan 13, 2016 at 07:13:57PM -0500, Steve Matzura wrote:
>> I hope this isn't off-topic by too much. If it is, a word to me
>> privately and I'll wait for responses to queries I've made elsewhere.
>I'm not as much of an SSH guru to "get" what's going on by just reading
>configs, but a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jan 13, 2016 at 07:13:57PM -0500, Steve Matzura wrote:
> I hope this isn't off-topic by too much. If it is, a word to me
> privately and I'll wait for responses to queries I've made elsewhere.
>
> I maintain two FTP servers and support four Wi
Is it possible that you are using a dsa key? ;-)
Use ssh with -v and take a look to the Output.
Yes, that was the problem. I switched to rsa, which doesn't seem to me like it
reduces paranoia, but I deal with systems that apparently don't understand
ed25519.
I had the same problem a few weeks ago.
"OpenSSH 7.0 disables ssh-dss keys by default" =)
Is it possible that you are using a dsa key? ;-)
Use ssh with -v and take a look to the Output.
Am 5. Januar 2016 17:49:54 MEZ, schrieb rvclay...@acm.org:
>I'm running
>
> $ lsb_release -a
> No LSB
On Tue, Jan 05, 2016 at 11:49:54AM -0500, rvclay...@acm.org wrote:
I'm running
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux testing-updates (sid)
Release:testing-updates
Codename: sid
$ uname -a
Linux BanjaLuka 4.3.
On 12/16/2015 06:54 PM, Kent West wrote:
westk@westek:~$ cat /etc/debian_version
stretch/sid
So, Debian Testing (Stretch).
You have a newer version of openssh-server (1:6.9p1-3) than I do
(1:6.7p1-5). Check your 'man sshd_config' carefully.
Kents-MacBook-Pro:~ westk$ ssh -vvv we...@west
On 12/16/15 8:19 PM, David Christensen wrote:
On 12/16/2015 05:29 AM, Kent West wrote:
If I try to connect to my Debian box at work, using either my Mac's OS X
or my Mac's Debian VM, I can connect successfully, but then immediately
the connection is closed:
Kents-MacBook-Pro:~ westk$ ssh -Y w
On 12/16/2015 05:29 AM, Kent West wrote:
If I try to connect to my Debian box at work, using either my Mac's OS X
or my Mac's Debian VM, I can connect successfully, but then immediately
the connection is closed:
Kents-MacBook-Pro:~ westk$ ssh -Y we...@westek.acu.edu
we...@westek.acu.edu's passwo
Kent West a écrit :
>
> One thing I did notice in the auth logs is that the connection port
> seems to change every connection attempt; is that normal?
Yes. The client source port used by a typical TCP connection is ephemeral.
Thanks to everybody who contributed to this thread. It is valuable.
Regards.
Johann
Normally for ssh tunnels I use -D
which creates a local socks tunnel listener (i.e -D1080) and means you can
do away with manual port forwards, you can then use a sockswrapper
(tsocks/dsocks) pointing at localhost to transparently proxify most
applications. Note that for UDP based things neither -
Also consider tincd
On 10 May 2015 at 04:51, Bonno Bloksma wrote:
> Hello Peter
>
>
> >> Petter Adsen wrote:
> >> > Now the question becomes; AFAIK, I could do this with ssh tunnels
> >> > and forward the ports on my router/firewall, or I could use
> >> > something like openvpn or IPsec (strongs
Bob Proulx a écrit :
>
> Both ssh and stunnel use TCP which means that in terms of ultimate
> performance and ultimate efficiency you are ending up with TCP over
> TCP and that isn't perfect.
SSH local or remote port forwarding (-L/-R) does stream forwarding ; it
is not a layer-3 tunnel (-w), so
Hello Peter
>> Petter Adsen wrote:
>> > Now the question becomes; AFAIK, I could do this with ssh tunnels
>> > and forward the ports on my router/firewall, or I could use
>> > something like openvpn or IPsec (strongswan).
>>
>> Yes. Exactly.
>>
>> Also 'stunnel4' is useful too.
>
> Thanks, I
On Sat, 9 May 2015 18:49:27 -0600
Bob Proulx wrote:
> Petter Adsen wrote:
> > Now the question becomes; AFAIK, I could do this with ssh tunnels
> > and forward the ports on my router/firewall, or I could use
> > something like openvpn or IPsec (strongswan).
>
> Yes. Exactly.
>
> Also 'stunnel4
Petter Adsen wrote:
> Now the question becomes; AFAIK, I could do this with ssh tunnels and
> forward the ports on my router/firewall, or I could use something like
> openvpn or IPsec (strongswan).
Yes. Exactly.
Also 'stunnel4' is useful too.
I would avoid IPsec. Last I looked there were more
On 2015-04-08 16:45:16 -0600, Bob Proulx wrote:
> I see mdns there and immediately have an immune reaction due to many
> problems with it before. As you have already determined it is the
> source of your current 5 second timeout. I recommend purging
> libnss-mdns from your system. That will solv
On 09/04/2015 9:38 AM, "Igor Cicimov" wrote:
>
>
> On 09/04/2015 3:11 AM, "Vincent Lefevre" wrote:
> >
> > When connecting by SSH to a particular machine, ssh hangs for
> > 5 seconds. The client machine doesn't matter (except for the
> > machine itself). For instance:
> >
> > xvii:~> ssh -vvv 2>>
On 09/04/2015 3:11 AM, "Vincent Lefevre" wrote:
>
> When connecting by SSH to a particular machine, ssh hangs for
> 5 seconds. The client machine doesn't matter (except for the
> machine itself). For instance:
>
> xvii:~> ssh -vvv 2>>(ts -s "%.s") ypig
> [...]
> 0.278462 debug2: key: /home/vinc17/
Vincent Lefevre wrote:
> Vincent Lefevre wrote:
> > Bob Proulx wrote:
> nameserver 140.77.1.32
> nameserver 140.77.167.2
That is a second potential source of timeout.
man resolv.conf
nameserver Name server IP address
Internet address of a name server that the resolve
On 2015-04-09 00:09:08 +0200, Vincent Lefevre wrote:
> According to
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=414569
> "avahi-daemon: delay on resolving IP addresses when mdns is
> specified in /etc/nsswitch.conf"
>
> the 5-second delay shouldn't occur, as this bug was fixed wit
On 2015-04-08 23:57:53 +0200, Vincent Lefevre wrote:
> On 2015-04-08 14:27:38 -0600, Bob Proulx wrote:
> > grep "^hosts" /etc/nsswitch.conf
>
> hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
[...]
> [...]
> 23:54:03 mprotect(0x7f5b92ff3000, 4096, PROT_READ) = 0
> 23:54:03 munmap
On 2015-04-08 14:27:38 -0600, Bob Proulx wrote:
> Vincent Lefevre wrote:
> > Yes, but with nslookup, the failure is *immediate*. So, this doesn't
> > explain the 5-second delay.
>
> What is the configuration of /etc/resolv.conf? /etc/nsswitch.conf?
>
> cat /etc/resolv.conf
domain lip.ens-lyon
Vincent Lefevre wrote:
> Michael Graham wrote:
> > Vincent Lefevre wrote:
> > > # /usr/sbin/sshd -D -ddd -p 80 -f /etc/ssh/sshd_config 2>>(ts -s "%.s")
> > > [...]
> > > (I use port 80 since port 22 is already taken by the normal sshd and
> > > the gateway to the machine seems to filter arbitrary
On 2015-04-08 13:46:06 -0400, Michael Graham wrote:
> On 8 April 2015 at 13:41, Vincent Lefevre wrote:
> > # /usr/sbin/sshd -D -ddd -p 80 -f /etc/ssh/sshd_config 2>>(ts -s "%.s")
> > [...]
> > 3.315346 debug3: Trying to reverse map address 140.77.51.8.
>
> So sshd is doing the reverse lookup and
On 8 April 2015 at 13:41, Vincent Lefevre wrote:
> # /usr/sbin/sshd -D -ddd -p 80 -f /etc/ssh/sshd_config 2>>(ts -s "%.s")
> [...]
> 3.315346 debug3: Trying to reverse map address 140.77.51.8.
So sshd is doing the reverse lookup and fails
> ypig:~> nslookup 140.77.51.8
> ;; Got SERVFAIL reply fr
On 2015-04-08 19:21:12 +0200, Sven Hartge wrote:
> Vincent Lefevre wrote:
>
> > When connecting by SSH to a particular machine, ssh hangs for
> > 5 seconds. The client machine doesn't matter (except for the
> > machine itself).
>
> 5 seconds smells like some DNS problem.
Yes, but the result is
Vincent Lefevre wrote:
> When connecting by SSH to a particular machine, ssh hangs for
> 5 seconds. The client machine doesn't matter (except for the
> machine itself).
5 seconds smells like some DNS problem.
Grüße,
Sven.
--
Sigmentation fault. Core dumped.
--
To UNSUBSCRIBE, email to debi
Could be your ssh client proposing ciphers the SSH server doesn't
understand. This was known issue with communication of ssh client 5+ to ssh
server 4.x and older.
Give it a try and let us know.
http://www.held.org.il/blog/2011/05/the-myterious-case-of-broken-ssh-client-connection-reset-by-peer/
On Thu, Jan 30, 2014 at 12:27:30PM -0200, André Nunes Batista wrote:
> On Wed, 2014-01-29 at 13:47 -0600, Craig L. wrote:
> > On Thu, Jan 23, 2014 at 02:07:08PM -0600, Craig L. wrote:
> >
> > This appears to be a problem with an ASA firewall appliance and is being
> > looked at by our network team
On 13/02/14 07:07, Dan Purgert wrote:
> On 12/02/2014 13:30, Paul E Condon wrote:
>> On 20140212_200320, Lars Noodén wrote:
>>> On 02/12/2014 07:34 PM, Paul E Condon wrote:
...
Question: Suppose I encounter this situation of the 'known host' having
moved to a different IP address (or
On 12/02/2014 13:30, Paul E Condon wrote:
On 20140212_200320, Lars Noodén wrote:
On 02/12/2014 07:34 PM, Paul E Condon wrote:
...
Question: Suppose I encounter this situation of the 'known host' having
moved to a different IP address (or a different URL?), is there a way
to discover whether the
On 20140212_200320, Lars Noodén wrote:
> On 02/12/2014 07:34 PM, Paul E Condon wrote:
> > ...
> > Question: Suppose I encounter this situation of the 'known host' having
> > moved to a different IP address (or a different URL?), is there a way
> > to discover whether the change is due to a proper f
On Wed 12 Feb 2014 at 10:34:33 -0700, Paul E Condon wrote:
> Question: Suppose I encounter this situation of the 'known host' having
> moved to a different IP address (or a different URL?), is there a way
> to discover whether the change is due to a proper functioning DynDNS,
> or to a somewhat un
On 02/12/2014 07:34 PM, Paul E Condon wrote:
> ...
> Question: Suppose I encounter this situation of the 'known host' having
> moved to a different IP address (or a different URL?), is there a way
> to discover whether the change is due to a proper functioning DynDNS,
> or to a somewhat unstealthy
On 20140212_152909, Lars Noodén wrote:
> On 02/12/2014 02:59 PM, Brian wrote:
> > On Tue 11 Feb 2014 at 15:22:26 +0200, Lars Noodén wrote:
> >
> >> ssh-keygen -r checks the SSHFP record in DNS. Use grep or something to
> >> check known_hosts. For me, ssh-keygen -R does not remove all the
> >> dy
On 02/12/2014 02:59 PM, Brian wrote:
> On Tue 11 Feb 2014 at 15:22:26 +0200, Lars Noodén wrote:
>
>> ssh-keygen -r checks the SSHFP record in DNS. Use grep or something to
>> check known_hosts. For me, ssh-keygen -R does not remove all the
>> dynamically generated host keys, however. I've not y
On Tue 11 Feb 2014 at 15:22:26 +0200, Lars Noodén wrote:
> ssh-keygen -r checks the SSHFP record in DNS. Use grep or something to
> check known_hosts. For me, ssh-keygen -R does not remove all the
> dynamically generated host keys, however. I've not yet identified what
> confounds ssh-keygen.
On Tue 11 Feb 2014 at 06:52:10 -0700, Paul E Condon wrote:
> I'm puzzled about the apparent 'security theater' on this topic.
> Known host checking is done, I think, to defend against 'man in the
> middle', so when the known host key changes because of some event down
> in the bowels of dynamic dn
On Tue, Feb 11, 2014 at 11:56:41PM +1100, Zenaan Harkness wrote:
> On 2/11/14, Brian wrote:
> > On Tue 11 Feb 2014 at 10:10:37 +1100, Zenaan Harkness wrote:
> >> I'm wondering:
> >> 1) how to easily clean known_hosts
> >
> > ssh-keygen with the -R option.
>
> $ HOST=raptor
> $ ssh-keygen -r $HOST
On 02/11/2014 03:52 PM, Paul E Condon wrote:
> ... Known host checking is done, I think, to defend against 'man in
> the middle', so when the known host key changes because of some event
> down in the bowels of dynamic dns, does one have any possibility of
> determining that it is truly *not* a ma
Paul E Condon:
>
> I'm puzzled about the apparent 'security theater' on this topic.
> Known host checking is done, I think, to defend against 'man in the
> middle',
Exactly.
> so when the known host key changes because of some event down
> in the bowels of dynamic dns, does one have any possibili
I'm puzzled about the apparent 'security theater' on this topic.
Known host checking is done, I think, to defend against 'man in the
middle', so when the known host key changes because of some event down
in the bowels of dynamic dns, does one have any possibility of
determining that it is truly *no
On 02/11/2014 02:56 PM, Zenaan Harkness wrote:
> On 2/11/14, Brian wrote:
>> On Tue 11 Feb 2014 at 10:10:37 +1100, Zenaan Harkness wrote:
>>> I'm wondering:
>>> 1) how to easily clean known_hosts
>>
>> ssh-keygen with the -R option.
>
> Sounds great! (also, the CheckHostIP = no option looks very
On 2/11/14, Brian wrote:
> On Tue 11 Feb 2014 at 10:10:37 +1100, Zenaan Harkness wrote:
>> I'm wondering:
>> 1) how to easily clean known_hosts
>
> ssh-keygen with the -R option.
Sounds great! (also, the CheckHostIP = no option looks very useful in
this regard, thanks Karl)
However - it seems to
Hi
On Tue, Feb 11, 2014 at 09:53:32AM +1100, Zenaan Harkness wrote:
> With a dyndns type server, each time a new ip address happens, ssh
> login adds a new entry to .known_hosts
>
> Is there a recommended way to handle this?
Turn off CheckHostIP ?
For the uninitiated, in your ~/.ssh/config file
On Tue 11 Feb 2014 at 10:10:37 +1100, Zenaan Harkness wrote:
> I'm wondering:
>
> 1) how to easily clean known_hosts
ssh-keygen with the -R option.
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
A
On 02/11/2014 01:10 AM, Zenaan Harkness wrote:
>> On Feb 10, 2014 2:53 PM, "Zenaan Harkness" wrote:
>>> With a dyndns type server, each time a new ip address happens, ssh
>>> login adds a new entry to .known_hosts
>>>
>>> Is there a recommended way to handle this?
>
> On 2/11/14, Schlacta, Christ
> On Feb 10, 2014 2:53 PM, "Zenaan Harkness" wrote:
>> With a dyndns type server, each time a new ip address happens, ssh
>> login adds a new entry to .known_hosts
>>
>> Is there a recommended way to handle this?
On 2/11/14, Schlacta, Christ wrote:
> Configure static dhcp leases for your server
Craig L. wrote:
> When I tried to reconnect, it took almost 60 seconds for the password
> prompt to show up.
It's probably trying to lookup rDNS for your IP address. Reverse lookups
are controlled by a parameter in the sshd_config file.
Chris
--
To UNSUBSCRIBE, email to debian-user-requ...@li
On Wed, 2014-01-29 at 13:47 -0600, Craig L. wrote:
> On Thu, Jan 23, 2014 at 02:07:08PM -0600, Craig L. wrote:
> > I have a couple of VMs running on a remote server: one with an older
> > version of
> > Ubuntu, and one running wheezy. I have an ssh tunnel with X forwarding set
> > up
> > so that
On Thu, Jan 23, 2014 at 02:07:08PM -0600, Craig L. wrote:
> I have a couple of VMs running on a remote server: one with an older version
> of
> Ubuntu, and one running wheezy. I have an ssh tunnel with X forwarding set up
> so that I can access the machines from my system as localhost
> (ssh -p 48
On Thu, Jan 23, 2014 at 09:20:09PM -0200, André Nunes Batista wrote:
> On Thu, 2014-01-23 at 14:07 -0600, Craig L. wrote:
> >
> > When I tried to reconnect, it took almost 60 seconds for the password
> > prompt to
> > show up. Ever since then this problem occurs from my machine to either of
> >
On Thu, 2014-01-23 at 14:07 -0600, Craig L. wrote:
> I have a couple of VMs running on a remote server: one with an older version
> of
> Ubuntu, and one running wheezy. I have an ssh tunnel with X forwarding set up
> so that I can access the machines from my system as localhost
> (ssh -p 48828 use
On Tue, Sep 10, 2013 at 02:28:37PM +0200, Juan Sierra Pons wrote:
> 2013/9/10 Sean Alexandre
> >
> > On Tue, Sep 10, 2013 at 01:11:17PM +0200, Juan Sierra Pons wrote:
> > > Hi,
> > >
> > > I don't see anything strange in the logs provided. Do you see anything
> > > strange in your dmesg, /var/log/
--
Juan Sierra Pons j...@elsotanillo.net
Linux User Registered: #257202 http://www.elsotanillo.net
GPG key = 0xA110F4FE
Key Fingerprint = DF53 7415 0936 244E 9B00 6E66 E934 340
On Tue, Sep 10, 2013 at 01:11:17PM +0200, Juan Sierra Pons wrote:
> Hi,
>
> I don't see anything strange in the logs provided. Do you see anything
> strange in your dmesg, /var/log/daemon.log, etc?
>
> Is the DNS on the server's side working properly? Sometimes when the
> reverse DNS is not prope
Hi,
I don't see anything strange in the logs provided. Do you see anything
strange in your dmesg, /var/log/daemon.log, etc?
Is the DNS on the server's side working properly? Sometimes when the
reverse DNS is not properly configure some TCP based services get some
delay on first connection: ssh, m
On Tue, Sep 10, 2013 at 12:25:59PM +0200, Juan Sierra Pons wrote:
> Can you launch the tunnel in verbose (-vvv) mode and send the logs?
> ssh -vvv -o ExitOnForwardFailure=yes -fN -L1110:localhost:1212 server
Here's what I'm seeing with -vvv:
http://paste.debian.net/37873/
--
To UNSUBSCRIBE, ema
Hi,
Can you launch the tunnel in verbose (-vvv) mode and send the logs?
ssh -vvv -o ExitOnForwardFailure=yes -fN -L1110:localhost:1212 server
Thank you
Regards
--
Juan Sierra Pons
On 09/05/2013 11:51 AM, Luther Blissett wrote:
> On Thu, 2013-09-05 at 20:50 +1000, Zenaan Harkness wrote:
>> Hello Verde, hope you are well :)
>>
>> Your error report/ request for assistance, is woefully inadequate. Let
>> me suggest further details for you to provide:
>>
>> On 9/5/13, Verde Deni
On Thu, 2013-09-05 at 20:50 +1000, Zenaan Harkness wrote:
> Hello Verde, hope you are well :)
>
> Your error report/ request for assistance, is woefully inadequate. Let
> me suggest further details for you to provide:
>
> On 9/5/13, Verde Denim wrote:
> > Just successfully got ssh -X to work to
Hello Verde, hope you are well :)
Your error report/ request for assistance, is woefully inadequate. Let
me suggest further details for you to provide:
On 9/5/13, Verde Denim wrote:
> Just successfully got ssh -X to work to connect remotely to my BT5
I have no idea wtf is BT5.
As a good rule o
301 - 400 of 2135 matches
Mail list logo
