Re: 6.1 amd64 errata 30_xrstor patch fails
On Wed, Oct 04, 2017 at 12:59:36AM +0200, Oliver Marugg wrote: > sorry for my previous markdown formatted mail: > I entered the commands correctly: > > ... > # KK=`sysctl -n kern.osversion | cut -d# -f1` > # cd /usr/src/sys/arch/`machine`/compile/$KK > # make obj > # make config > make: don't know how to make config > Stop in /usr/src/sys/arch/amd64/compile/GENERIC.MP > ... > FWIW - it worked for me (OpenBSD ... 6.1 GENERIC.MP#4 amd64): # KK=`sysctl -n kern.osversion | cut -d# -f1` # cd /usr/src/sys/arch/`machine`/compile/$KK # make obj # make config cd /usr/obj/sys/arch/amd64/compile/GENERIC.MP && config -s /usr/src/sys -b /usr/src/sys/arch/amd64/compile/GENERIC.MP/obj /usr/src/sys/arch/amd64/conf/GENERIC.MP #
Re: recent troubles with iwn(4)
On Sun, Sep 08, 2019 at 08:31:55PM +, Bryan Stenson wrote: > Hi all - > > I'm writing to "misc" rather than "bugs" as I'm not yet sure this is a > bug. I'm hoping to help triage this with assistance from this list. > > I'm running -CURRENT and the iwn(4) driver for my wireless card. Over > the past year, this has been working great, but recently (within the > last month or so), I've had issues where the NIC just stops working > after a few hours of usage. I don't have a solid steps for > reproduction. > > I realize "stops working" is not a very accurate account here...but > I'm confused on how to get more descriptive information of the > problem. When it stops, "ifconfig" shows iwn0 with an IP address, but > I'm unable to ping. Additionally, I'm not seeing any > warnings/messages in "dmesg" about the device...so I'm confused. The iwn driver on my host runnning 6.4 stable writes to /var/log/messages (as well as the system message buffer). Is there nothing in the log files on your system? --Paul
Re: TRIM on SSD
On Wed, Dec 06, 2017 at 03:15:57AM -0500, Rupert Gallagher wrote: > I know well that article, because it is several years old with no updates. > > Those working on ffs should do what they are supposed to do. Lack of > money? Setup a stickers sale or a kickstarter, get the money and just > fucking do it. Why do you think anyone on this list should take you seriously? You blatantly disregard the standards of this list. Your technical observations are of highly dubious merit. You like to make judgements/pronouncements about technical matters as if you're an expert and can speak with authority; yet whenever you've neeeded help for a genuine technical problem, you demonstrate that you possess only rudimentary knowledge, at best equivalent to a slow-learning, junior sysadmin. And in spite of all that, you think you know best what other people should do. It seems you would like to think that it's your choice of email client that engenders the aggression towards you. You're being clueless.
Re: AuthorizedKeyCommand ldap
On Mon, Dec 11, 2017 at 03:49:24PM -0700, Dan Becker wrote: > I am reading a blog proposing to use the AuthorizedKeyCommand to hook into > another authentication mechanism by calling a shell script > > https://blog.heckel.xyz/2015/05/04/openssh-authorizedkeyscommand-with-fingerprint/ > > Do I have a valid concern in thinking this might not be a prudent method of > authentication ? > I don't know why he uses the term 'dynamic authorized_keys file'. I know what he means, but it's not a file. (When people misuse basic terms I immediately question their depth of understanding.) As for your question - these are some thoughts, not intended to be comprehensive: As I see it, the key will be somewhere - in the authorized_keys file in the user's home directory, in an LDAP directory, or perhaps elsewhere. Regardless of where it's kept, it needs to be secured against tampering. Is the local host more secure in that regard than an LDAP dir? That depends on the quality of the sysadmins who set up the server and how the network infrastructure is designed. The same applies to any other mechanism for remotely storing public keys. sshd(8) will complain if the perms for the user's authorized_key file aren't correct, so it offers a safe-guard against misconfiguration. The mechanism for retrieving the key from a remote server should use SSL/TLS to validate the server's identity and protect the contents. The utility invoked by sshd to fetch the key needs to be secured, requiring special privileges to modify it. Locally, points of attack would be the tool itself or the user's authorized keys file, or the server's public key. They're all files, so file permission restrictions would have to be circumvented. If the tool is not written in a type-safe language, then it could create additional vulnerabilities as well. In larger environments, keeping track of authorized_keys files for users and hosts, making sure they're (only) on the hosts they need to be on, and keeping them accurate and up-to-date can be tedious and error prone, even with a config management system. One could argue that that method allows for vulnerabilities that would not exist if the keys were managed centrally. Again, it depends on the quality of the sysadmins' work. The security requirements in an infrastructure are probably not the same for all hosts, so you could use a hybrid strategy, using a local authorzed_keys file for hosts that need greater protection (e.g., database servers, firewalls, DMZ hosts, etc) if that makes you more comfortable. (Generally speaking, I think too much uniformity can sometimes be a weakness).
Re: AuthorizedKeyCommand ldap
On Tue, Dec 12, 2017 at 09:35:27AM -0700, Dan Becker wrote:
> On Mon, Dec 11, 2017 at 7:13 PM, Paulm wrote:
>
> > On Mon, Dec 11, 2017 at 03:49:24PM -0700, Dan Becker wrote:
> > > I am reading a blog proposing to use the AuthorizedKeyCommand to hook
> > into
> > > another authentication mechanism by calling a shell script
> > >
> > > https://blog.heckel.xyz/2015/05/04/openssh-authorizedkeyscommand-with-
> > fingerprint/
> > >
> > > Do I have a valid concern in thinking this might not be a prudent method
> > of
> > > authentication ?
> > >
> >
> > I don't know why he uses the term 'dynamic authorized_keys file'. I
> > know what he means, but it's not a file. (When people misuse basic
> > terms I immediately question their depth of understanding.)
> >
> > As for your question - these are some thoughts, not intended to be
> > comprehensive:
> >
> > As I see it, the key will be somewhere - in the authorized_keys file
> > in the user's home directory, in an LDAP directory, or perhaps
> > elsewhere. Regardless of where it's kept, it needs to be secured
> > against tampering. Is the local host more secure in that regard than
> > an LDAP dir? That depends on the quality of the sysadmins who set up
> > the server and how the network infrastructure is designed. The same
> > applies to any other mechanism for remotely storing public keys.
> >
> > sshd(8) will complain if the perms for the user's authorized_key file
> > aren't correct, so it offers a safe-guard against misconfiguration.
> >
> > The mechanism for retrieving the key from a remote server should use
> > SSL/TLS to validate the server's identity and protect the contents.
> >
> > The utility invoked by sshd to fetch the key needs to be secured,
> > requiring special privileges to modify it.
> >
> > Locally, points of attack would be the tool itself or the user's
> > authorized keys file, or the server's public key. They're all files,
> > so file permission restrictions would have to be circumvented. If the
> > tool is not written in a type-safe language, then it could create
> > additional vulnerabilities as well.
> >
> > In larger environments, keeping track of authorized_keys files for
> > users and hosts, making sure they're (only) on the hosts they need to
> > be on, and keeping them accurate and up-to-date can be tedious and
> > error prone, even with a config management system. One could argue
> > that that method allows for vulnerabilities that would not exist if
> > the keys were managed centrally. Again, it depends on the quality of
> > the sysadmins' work.
> >
> > The security requirements in an infrastructure are probably not the
> > same for all hosts, so you could use a hybrid strategy, using a local
> > authorzed_keys file for hosts that need greater protection (e.g.,
> > database servers, firewalls, DMZ hosts, etc) if that makes you more
> > comfortable. (Generally speaking, I think too much uniformity can
> > sometimes be a weakness).
> >
> >
> >
> >
> Thank you for the above
>
> We have someone suggesting we implement something similar to the above with
> a twist.
>
> The script they call acts similar to this
>
> user="$1"
> hostname="$(hostname)"
> curl -s -q -m 5 -f -H "Authorization: Token ${secret}" "
> https://auth.site.com/sshkeys/?user=${user}&hostname=${hostname}";
> 2>/dev/null
> exit $?
>
>
> My main concern comes from the fact this process is being ran as root and
> injecting the username as an arg "$1"
>
> Example :
>
> What happens if someone runs ssh '"&rm -rf /'@host, is there a sanitation
> in the ssh daemon ?
Your script will live in the filesystem, potentially executable by
other programs/users, not just sshd. Regardless of any kind of input
sanitation sshd does, your script should probably do it too - or be
extra careful about how it handles the input.
Re: AuthorizedKeyCommand ldap
On Tue, Dec 12, 2017 at 09:35:27AM -0700, Dan Becker wrote:
> On Mon, Dec 11, 2017 at 7:13 PM, Paulm wrote:
>
> > On Mon, Dec 11, 2017 at 03:49:24PM -0700, Dan Becker wrote:
> > > I am reading a blog proposing to use the AuthorizedKeyCommand to hook
> > into
> > > another authentication mechanism by calling a shell script
> > >
> > > https://blog.heckel.xyz/2015/05/04/openssh-authorizedkeyscommand-with-
> > fingerprint/
> > >
> > > Do I have a valid concern in thinking this might not be a prudent method
> > of
> > > authentication ?
> > >
> >
> > I don't know why he uses the term 'dynamic authorized_keys file'. I
> > know what he means, but it's not a file. (When people misuse basic
> > terms I immediately question their depth of understanding.)
> >
> > As for your question - these are some thoughts, not intended to be
> > comprehensive:
> >
> > As I see it, the key will be somewhere - in the authorized_keys file
> > in the user's home directory, in an LDAP directory, or perhaps
> > elsewhere. Regardless of where it's kept, it needs to be secured
> > against tampering. Is the local host more secure in that regard than
> > an LDAP dir? That depends on the quality of the sysadmins who set up
> > the server and how the network infrastructure is designed. The same
> > applies to any other mechanism for remotely storing public keys.
> >
> > sshd(8) will complain if the perms for the user's authorized_key file
> > aren't correct, so it offers a safe-guard against misconfiguration.
> >
> > The mechanism for retrieving the key from a remote server should use
> > SSL/TLS to validate the server's identity and protect the contents.
> >
> > The utility invoked by sshd to fetch the key needs to be secured,
> > requiring special privileges to modify it.
> >
> > Locally, points of attack would be the tool itself or the user's
> > authorized keys file, or the server's public key. They're all files,
> > so file permission restrictions would have to be circumvented. If the
> > tool is not written in a type-safe language, then it could create
> > additional vulnerabilities as well.
> >
> > In larger environments, keeping track of authorized_keys files for
> > users and hosts, making sure they're (only) on the hosts they need to
> > be on, and keeping them accurate and up-to-date can be tedious and
> > error prone, even with a config management system. One could argue
> > that that method allows for vulnerabilities that would not exist if
> > the keys were managed centrally. Again, it depends on the quality of
> > the sysadmins' work.
> >
> > The security requirements in an infrastructure are probably not the
> > same for all hosts, so you could use a hybrid strategy, using a local
> > authorzed_keys file for hosts that need greater protection (e.g.,
> > database servers, firewalls, DMZ hosts, etc) if that makes you more
> > comfortable. (Generally speaking, I think too much uniformity can
> > sometimes be a weakness).
> >
> >
> >
> >
> Thank you for the above
>
> We have someone suggesting we implement something similar to the above with
> a twist.
>
> The script they call acts similar to this
>
> user="$1"
> hostname="$(hostname)"
> curl -s -q -m 5 -f -H "Authorization: Token ${secret}" "
> https://auth.site.com/sshkeys/?user=${user}&hostname=${hostname}";
> 2>/dev/null
> exit $?
>
>
> My main concern comes from the fact this process is being ran as root and
> injecting the username as an arg "$1"
>
> Example :
>
> What happens if someone runs ssh '"&rm -rf /'@host, is there a sanitation
> in the ssh daemon ?
Also, because you're talking about authentication, I wouldn't be too
casual about handling errors.
Errors should be reported to syslog, not sent to /dev/null.
Re: AuthorizedKeyCommand ldap
> > > The script they call acts similar to this > > > > > > user="$1" > > case $user in > user1) > do stuff > ;; > user2) > do stuff > ;; > > user3) > do stuff > ;; > *) > invalid user stuff > ;; A solution that scales would use a regex that checks input for chars not allowed in a username, and confirms the length of input doesn't exceed the max length for a username.
Re: OpenBSD hangs when i unplug USB disk
You *do* know about mount(8)/umount(8), right? On Wed, Nov 14, 2012 at 04:22:20PM -0300, Marcos Laufer wrote: > Hello, i'd like to inform a problem when dettaching an external 1TB > USB disk drive , the system just freezes, i can't type anything. > Also It stops responding to ping. > If i don't unplug it then i can use the disk normally, i can copy > and delete files with no problem. But as soon as i unplug the USB > cord, the machine freezes. > I've tested it on several machines, different OpenBSD versions > starting from 4.3, i'm not asking for support, i know old OpenBSD > versions are no longer supported, but this seemed pretty odd, i > suppose that plugging and unplugging a USB disk should not cause any > problems on any OS version. > > These are the lines on dmesg about this disk: > > > Nov 14 16:00:31 hq /bsd: umass0 at uhub0 > Nov 14 16:00:31 hq /bsd: port 5 configuration 1 interface 0 > "Western Digital My Passport 0748" rev 2.10/10.15 addr 2 > Nov 14 16:00:31 hq /bsd: umass0: using SCSI over Bulk-Only > Nov 14 16:00:31 hq /bsd: scsibus0 at umass0: 2 targets, initiator 0 > Nov 14 16:00:31 hq /bsd: sd0 at scsibus0 targ 1 lun 0: Passport 0748, 1015> SCSI4 0/direct fixed > Nov 14 16:00:38 hq /bsd: sd0: 953837MB, 512 bytes/sec, 1953458176 sec total > Nov 14 16:00:38 hq /bsd: ses0 at scsibus0 targ 1 lun 1: Device, 1015> SCSI4 13/enclosure services fixed > Nov 14 16:00:38 hq /bsd: ses0: unable to read enclosure configuration > > Best regards, > Marcos
Re: apue : for openbsd : which edition?
Edition 3 is due out in June. On Sun, Feb 10, 2013 at 09:17:52PM +0100, Juan Francisco Cantero Hurtado wrote: > On Sun, Feb 10, 2013 at 01:00:50AM -0500, Mayuresh Kathe wrote: > > hello, may i know which would be the most suitable > > edition of 'apue' (1st or 2nd) to learn more about > > programming services under openbsd? > > thanks. > > http://article.gmane.org/gmane.os.openbsd.misc/197135 > > Cheers. > > -- > Juan Francisco Cantero Hurtado http://juanfra.info
malloc(9) statistics
I'm having trouble understanding the purpose of a couple of statistics recorded in the calls to malloc(9) and free(9). The first is displayed by 'systat malloc' under the KERN LIMIT column. The value is taken from ks_mapblocks. From kmemstats structure in sys/malloc.h: u_short ks_mapblocks; /* number of times blocked for kernel map */ The comment suggests it's something that would be incremented when a call to uvm_km_kmemalloc_pla returns NULL because the map is full. This doesn't happen though, and as far as I can tell ks_mapblocks isn't referenced/used anywhere outside of its declaration except for systat/sysctl. Is its usage deprecated perhaps? The second variable is kb_couldfree. This is more puzzling. It's only incremented in free(). From struct kmembuckets: u_int64_t kb_couldfree; /* over high water mark and could free */ This sounds like excess items in the bucket which could be reclaimed if needed elsewhere; but that seems unlikely given that 1) the variable isn't decremented anywhere that I can find, and 2) some of the values reported by 'systat buckets', when multiplied by the size of the bucket item, exceed the size of the entire malloc arena. What does kb_couldfree actually mean? (or what am I not getting?)
Re: Doubt with IPSEC
I would suggest passing the -vL option to iskampd. -v enables verbose logging which will report errors when trying to setup the SA. The -L option will create pcap file in /var/run which contains the packets exchanged to set up the SA. If you look at this pcap file w/ the verbose (-vv) option to tcpdump, you will see extensive info SA negotiations. On Wed, Jul 11, 2012 at 02:23:13PM -0300, Rodrigo Mosconi wrote: > Hi, > > I`m having a problem to establish a IPSEC transport between two > openbsd hosts (one with 5.1 and the other with 4.9). They are > configured to use the transport mode (confs bellow). > When I run "isakmpd -K ; ipsecctl -f /etc/ipsec.conf" on both hosts, > no SA are created. What did I miss? > > Thanks, > > Mosconi > > OBSD51 (hubble): > PF: > # pfctl -sr > pass all flags S/SA > block drop in on ! lo0 proto tcp from any to any port 6000:6010 > > # ping -c 5 spitzer > PING spitzer.domain (IP_SPITZER): 56 data bytes > 64 bytes from IP_SPITZER: icmp_seq=0 ttl=244 time=69.193 ms > 64 bytes from IP_SPITZER: icmp_seq=1 ttl=244 time=70.835 ms > 64 bytes from IP_SPITZER: icmp_seq=2 ttl=244 time=70.223 ms > 64 bytes from IP_SPITZER: icmp_seq=3 ttl=244 time=70.740 ms > 64 bytes from IP_SPITZER: icmp_seq=4 ttl=244 time=69.469 ms > --- spitzer.domain ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 69.193/70.092/70.835/0.661 ms > > # cat /etc/ipsec.conf > # $OpenBSD: ipsec.conf,v 1.5 2006/09/14 15:10:43 hshoexer Exp $ > # > # See ipsec.conf(5) for syntax and examples. > > # Set up two tunnels using automatic keying with isakmpd(8): > # > # First between the networks 10.1.1.0/24 and 10.1.2.0/24, > # second between the machines 192.168.3.1 and 192.168.3.2. > # Use FQDNs as IDs. > > ike esp transport from hubble to spitzer \ > main \ > auth hmac-sha2-512 \ > enc aes-256 \ > group modp4096 \ > srcid hubble.domain \ > dstid spitzer.domain \ > psk '/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy' > > # ipsecctl -vvf /etc/ipsec.conf > @0 C set [Phase 1]:IP_SPITZER=peer-IP_SPITZER force > C set [peer-IP_SPITZER]:Phase=1 force > C set [peer-IP_SPITZER]:Address=IP_SPITZER force > C set > [peer-IP_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy > force > C set [peer-IP_SPITZER]:Configuration=phase1-peer-IP_SPITZER force > C set [phase1-peer-IP_SPITZER]:EXCHANGE_TYPE=ID_PROT force > C add [phase1-peer-IP_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force > C set [peer-IP_SPITZER]:ID=id-hubble.domain force > C set [id-hubble.domain]:ID-type=FQDN force > C set [id-hubble.domain]:Name=hubble.domain force > C set [peer-IP_SPITZER]:Remote-ID=id-spitzer.domain force > C set [id-spitzer.domain]:ID-type=FQDN force > C set [id-spitzer.domain]:Name=spitzer.domain force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Phase=2 force > C set [from-IP_HUBBLE-to-IP_SPITZER]:ISAKMP-peer=peer-IP_SPITZER force > C set > [from-IP_HUBBLE-to-IP_SPITZER]:Configuration=phase2-from-IP_HUBBLE-to-IP_SPITZER > force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Local-ID=from-IP_HUBBLE force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Remote-ID=to-IP_SPITZER force > C set [phase2-from-IP_HUBBLE-to-IP_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force > C set > [phase2-from-IP_HUBBLE-to-IP_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE > force > C set [from-IP_HUBBLE]:ID-type=IPV4_ADDR force > C set [from-IP_HUBBLE]:Address=IP_HUBBLE force > C set [to-IP_SPITZER]:ID-type=IPV4_ADDR force > C set [to-IP_SPITZER]:Address=IP_SPITZER force > C add [Phase 2]:Connections=from-IP_HUBBLE-to-IP_SPITZER > @1 C set [Phase 1]:IP6_SPITZER=peer-IP6_SPITZER force > C set [peer-IP6_SPITZER]:Phase=1 force > C set [peer-IP6_SPITZER]:Address=IP6_SPITZER force > C set > [peer-IP6_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy > force > C set [peer-IP6_SPITZER]:Configuration=phase1-peer-IP6_SPITZER force > C set [phase1-peer-IP6_SPITZER]:EXCHANGE_TYPE=ID_PROT force > C add [phase1-peer-IP6_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force > C set [peer-IP6_SPITZER]:ID=id-hubble.domain force > C set [id-hubble.domain]:ID-type=FQDN force > C set [id-hubble.domain]:Name=hubble.domain force > C set [peer-IP6_SPITZER]:Remote-ID=id-spitzer.domain force > C set [id-spitzer.domain]:ID-type=FQDN force > C set [id-spitzer.domain]:Name=spitzer.domain force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Phase=2 force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:ISAKMP-peer=peer-IP6_SPITZER force > C set > [from-IP6_HUBBLE-to-IP6_SPITZER]:Configuration=phase2-from-IP6_HUBBLE-to-IP6_SPITZER > force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Local-ID=from-IP6_HUBBLE force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Remote-ID=to-IP6_SPITZER force > C set [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force > C set > [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:Suite
Re: Doubt with IPSEC
One of the two hosts needs to use 'passive' in ipsec.conf so that it acts as server and listens/responds to incoming requests from peers. On Wed, Jul 11, 2012 at 02:23:13PM -0300, Rodrigo Mosconi wrote: > Hi, > > I`m having a problem to establish a IPSEC transport between two > openbsd hosts (one with 5.1 and the other with 4.9). They are > configured to use the transport mode (confs bellow). > When I run "isakmpd -K ; ipsecctl -f /etc/ipsec.conf" on both hosts, > no SA are created. What did I miss? > > Thanks, > > Mosconi > > OBSD51 (hubble): > PF: > # pfctl -sr > pass all flags S/SA > block drop in on ! lo0 proto tcp from any to any port 6000:6010 > > # ping -c 5 spitzer > PING spitzer.domain (IP_SPITZER): 56 data bytes > 64 bytes from IP_SPITZER: icmp_seq=0 ttl=244 time=69.193 ms > 64 bytes from IP_SPITZER: icmp_seq=1 ttl=244 time=70.835 ms > 64 bytes from IP_SPITZER: icmp_seq=2 ttl=244 time=70.223 ms > 64 bytes from IP_SPITZER: icmp_seq=3 ttl=244 time=70.740 ms > 64 bytes from IP_SPITZER: icmp_seq=4 ttl=244 time=69.469 ms > --- spitzer.domain ping statistics --- > 5 packets transmitted, 5 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 69.193/70.092/70.835/0.661 ms > > # cat /etc/ipsec.conf > # $OpenBSD: ipsec.conf,v 1.5 2006/09/14 15:10:43 hshoexer Exp $ > # > # See ipsec.conf(5) for syntax and examples. > > # Set up two tunnels using automatic keying with isakmpd(8): > # > # First between the networks 10.1.1.0/24 and 10.1.2.0/24, > # second between the machines 192.168.3.1 and 192.168.3.2. > # Use FQDNs as IDs. > > ike esp transport from hubble to spitzer \ > main \ > auth hmac-sha2-512 \ > enc aes-256 \ > group modp4096 \ > srcid hubble.domain \ > dstid spitzer.domain \ > psk '/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy' > > # ipsecctl -vvf /etc/ipsec.conf > @0 C set [Phase 1]:IP_SPITZER=peer-IP_SPITZER force > C set [peer-IP_SPITZER]:Phase=1 force > C set [peer-IP_SPITZER]:Address=IP_SPITZER force > C set > [peer-IP_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy > force > C set [peer-IP_SPITZER]:Configuration=phase1-peer-IP_SPITZER force > C set [phase1-peer-IP_SPITZER]:EXCHANGE_TYPE=ID_PROT force > C add [phase1-peer-IP_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force > C set [peer-IP_SPITZER]:ID=id-hubble.domain force > C set [id-hubble.domain]:ID-type=FQDN force > C set [id-hubble.domain]:Name=hubble.domain force > C set [peer-IP_SPITZER]:Remote-ID=id-spitzer.domain force > C set [id-spitzer.domain]:ID-type=FQDN force > C set [id-spitzer.domain]:Name=spitzer.domain force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Phase=2 force > C set [from-IP_HUBBLE-to-IP_SPITZER]:ISAKMP-peer=peer-IP_SPITZER force > C set > [from-IP_HUBBLE-to-IP_SPITZER]:Configuration=phase2-from-IP_HUBBLE-to-IP_SPITZER > force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Local-ID=from-IP_HUBBLE force > C set [from-IP_HUBBLE-to-IP_SPITZER]:Remote-ID=to-IP_SPITZER force > C set [phase2-from-IP_HUBBLE-to-IP_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force > C set > [phase2-from-IP_HUBBLE-to-IP_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE > force > C set [from-IP_HUBBLE]:ID-type=IPV4_ADDR force > C set [from-IP_HUBBLE]:Address=IP_HUBBLE force > C set [to-IP_SPITZER]:ID-type=IPV4_ADDR force > C set [to-IP_SPITZER]:Address=IP_SPITZER force > C add [Phase 2]:Connections=from-IP_HUBBLE-to-IP_SPITZER > @1 C set [Phase 1]:IP6_SPITZER=peer-IP6_SPITZER force > C set [peer-IP6_SPITZER]:Phase=1 force > C set [peer-IP6_SPITZER]:Address=IP6_SPITZER force > C set > [peer-IP6_SPITZER]:Authentication=/+V1gt9G6FTQ"_}/Rn#nny!ZCgmd5+jIe^dKXf+)40R6%ZS(zD8Q2DUt[T(NwJOy > force > C set [peer-IP6_SPITZER]:Configuration=phase1-peer-IP6_SPITZER force > C set [phase1-peer-IP6_SPITZER]:EXCHANGE_TYPE=ID_PROT force > C add [phase1-peer-IP6_SPITZER]:Transforms=AES-256-SHA2-512-GRP16 force > C set [peer-IP6_SPITZER]:ID=id-hubble.domain force > C set [id-hubble.domain]:ID-type=FQDN force > C set [id-hubble.domain]:Name=hubble.domain force > C set [peer-IP6_SPITZER]:Remote-ID=id-spitzer.domain force > C set [id-spitzer.domain]:ID-type=FQDN force > C set [id-spitzer.domain]:Name=spitzer.domain force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Phase=2 force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:ISAKMP-peer=peer-IP6_SPITZER force > C set > [from-IP6_HUBBLE-to-IP6_SPITZER]:Configuration=phase2-from-IP6_HUBBLE-to-IP6_SPITZER > force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Local-ID=from-IP6_HUBBLE force > C set [from-IP6_HUBBLE-to-IP6_SPITZER]:Remote-ID=to-IP6_SPITZER force > C set [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:EXCHANGE_TYPE=QUICK_MODE force > C set > [phase2-from-IP6_HUBBLE-to-IP6_SPITZER]:Suites=QM-ESP-TRP-AES-SHA2-256-PFS-SUITE > force > C set [from-IP6_HUBBLE]:ID-type=IPV6_ADDR force > C set [from-IP6_HUBBLE]:Address=IP6_HUBBLE force > C set [to-IP6_SPITZER]:ID-type=IPV6_ADDR force > C set [to-IP6_SPITZ
Re: Calomel.org
> Here's a better idea I'm putting out there to see how fast it gets shot down: > openbsd-wiki.org, with a rule that whoever gets a question answered on misc > has to add an entry with the cleaned reply. It'd do wonders for misc's > signal/noise because lazy fucks, retards and trolls would think twice before > posting and legitimate users would get answers faster and silently, in > whatever available languages. How is that going to stop the 'retards and trolls' from posting? What are the consequences for people who break the rule, and who is going to enforce it? Have you really thought this through? > Dynamic content & proper search would also put an end to "just wade through > marc.info" fuck-offs and self-righteous RTFD when one has to "egrep -Rli > serial /usr/share/man", say. Man/info pages are the ultimate /reference/, > they're not meant to solve high-level problems. The FAQs are really are no > FAQs at all but a gigantic snowball with floppy install instructions > crucially leaving out 5 1/4" and 8" media. I don't understand why the floppy install option gets you so riled up. I happen to have a couple of IBM Thinkpads from the early 2000's, which still work quite well with the exception of unreliable cdrom drives. So I like knowing the floppy option is there.
Re: /etc/mygate not work
How do your interfaces get configured on boot? Is DHCP involved anywhere? >From mygate(5): "/etc/mygate is processed after all interfaces have been configured. If any hostname.if(5) files contain ``dhcp'' directives, IPv4 entries in /etc/mygate will be ignored." On Mon, Jul 30, 2012 at 02:40:47PM +0300, lilit-aibolit wrote: > there is strange behaviour in 5.1. > before reboot: > # cat /etc/mygate > 192.168.2.80 > # ls -la /etc/mygate > -rw-r--r-- 1 root wheel 13 Jul 30 13:15 /etc/mygate > # ifconfig -a > lo0: flags=8049 mtu 33196 > ... > em0: flags=28843 mtu 1500 > .. > status: active > inet 192.168.2.2 netmask 0xff00 broadcast 192.168.2.255 > em1: flags=8843 mtu 1500 > ... > status: no carrier > inet6 fe80::218:7dff:fe13:f325%em1 prefixlen 64 scopeid 0x2 > enc0: flags=0<> > .. > rum0: flags=28843 mtu 1500 > .. > status: active > .. > inet 192.168.22.2 netmask 0xff00 broadcast 192.168.22.255 > tun0: flags=8051 mtu 1500 > > status: active > inet 192.168.88.1 --> 192.168.88.2 netmask 0x > pflog0: flags=141 mtu 33196 > > after reboot: > # netstat -rn > Destination Gateway Flags Refs Use Mtu Prio Iface > 127/8 127.0.0.1 UGRS 0 0 33196 8 lo0 > 127.0.0.1 127.0.0.1 UH 1 6 33196 4 lo0 > 192.168.2/24 link#1 UC 2 0 - 4 em0 > > > default route is absent. > please, help to understand what is wrong? > - End forwarded message -
Re: apache - built in - and syslog
Have you looked here? /usr/share/doc/html/httpd/ On Mon, Jul 30, 2012 at 01:31:16PM -0400, sven falempin wrote: > http://www.moko.ru/doc/apache/mod/mod_log_config.html#transferlog > > |followed by a command > > anything better ? > > thx to russia ... > > 2012/7/30 sven falempin > > > HEllo, > > > > I(and google) do not find the apache 1.3.29 documentation for editing conf > > file, neither information to syslog the apache logs. > > > > Pointer anyone ? > > > > -- > > > > - > > () ascii ribbon campaign - against html e-mail > > /\ > > > > * > > * > > > > > > > > > > > > > > > -- > - > () ascii ribbon campaign - against html e-mail > /\
Re: Dilemma: between OpenBSD and NetBSD
On Sat, Aug 11, 2012 at 03:49:01AM +0200, benh...@gmx.us wrote: > On 2012-08-11 03:21, Andres Perera wrote: > >i find it hard to believe you're involved in such project. "more > >portable", "more secure" don't mean anything unless details are > >involved. i mean, if it runs on your target hosts, what could "more > >portable" possibly mean? > > > >it's better to say: i'm trying out these two and i want a comparison. > > >lying, saying your boss wants a bsd solution, doesn't make it seem > >more important! > > > I didn't expect to find a clairvoyant on this mailing list. You will find idiots on @misc. It's one of the few things not in the FAQ.
Re: Dell Latitude E6420 issues - not working...
There's no guarantee that snapshots are functional or bootable. Have you tried installing/booting the 5.1 release to see if that works? On Tue, Aug 14, 2012 at 10:24:39AM -0400, Jiri B wrote: > Hi all, > > I have in my hands Dell Latitude E6420 so I tried to boot > OpenBSD snapshot and booting got stucked on these lines... > (I retyped from a photos I made.) > > The last line was one with 'scsibus1 at umass0' below, then > I touched a key and console was full of pbkbcintr lines... > > How can I help to troubleshoot this? > > jirib > > ... > uhidev1 at uhub5 port 1 configuration 1 in > rev 2.00/54.00 addr 3 > uhidev1: iclass 3/1 > uhid at uhidev1 not configured > uhidev2 at uhub5 port 2 configuration 1 in > dio 400 DSP" rev 2.00/1.32 addr 4 > uhidev2: iclass 3/0, 9 report ids > uhid at uhidev2 reportid 1 not configured > uhid at uhidev2 reportid 2 not configured > uhid at uhidev2 reportid 8 not configured > uhid at uhidev2 reportid 9 not configured > "Plantronics Plantronics .Audio 180 DSP" re > nfiguration 1 not configured > umass0 at uhub5 port 6 configuration 3 inter > ddr 5 > umass0: using SCSI over Bulk-Only > scsibus1 at umass0: 2 targets, initiator 0 > _ > > pckbcintr: no eki for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1 > pckbcintr: no dev for slot 1
Re: iked.conf question - muplitple clients with certs.
I'm not sure if it's relevant for your situation, but do you know that, according to the iked(8) manpage, iked is 'not finished' and not recommended for production networks? (See the last section - 'caveats') It might be better to use isakmpd(8) with ipsec(4)/ipsecctl(8)/ipsec.conf(5) if your running this in production. On Wed, Aug 15, 2012 at 01:36:47PM -0400, Bentley, Dain wrote: > Hello Misc, > I'm having a small issue with my iked.conf on my openbsd 4.9 firewall. I have > the following config and it works fine: > > Ikev2 "laptop" passive esp \ > From 192.168.10.0/24 to 1.1.1.0/24 local any peer any \ > srcid xxx.xxx.xxx.xxx \ > config address 1.1.1.2 > > > I have a win 7 laptop with certs and I connect with no issue. Now I'd like to > add a couple of more clients in the mix. So I created certs for them and > distributed them correctly and now have the following: > > > Ikev2 "home-PC" passive esp \ > From 192.168.10.0/24 to 1.1.1.0/24 local any peer any \ > srcid xxx.xxx.xxx.xxx \ > config address 1.1.1.3 > > > Ikev2 "laptop" passive esp \ > From 192.168.10.0/24 to 1.1.1.0/24 local any peer any \ > srcid xxx.xxx.xxx.xxx \ > config address 1.1.1.2 > > > > But when I connect I cannot and starting iked -dvv shows it's trying to > connect with the "laptop" policy. I'm afraid I have the config wrong. Is > this the correct way to add multiple clients and if not what would I do? I > can't seem to find any info on the web or man pages.
Re: Openbsd init script for ssh VPN tunnel
On Tue, Aug 21, 2012 at 07:59:30PM -0600, Luis F Urrea wrote:
> I have a server hosting SSH tunnels and Openbsd 4.5 clients connecting to
> it.
>
> Things work just fine but I am in the need of automating the connection
> from the client to the server. So that if the client is accidentally
> rebooted, then the connection initiates unattended.
>
> So it should be as straight forward as to include the ssh connection in an
> init script. However I have miserably failed to do so by including it to
> /etc/rc.local, which is the file I usually do this sort of things in.
>
> Right now I am using autossh to also restart the connection if necessary
> and the script that I put on /etc/rc.local follows:
>
> #!/bin/sh
> #
> # Example script to start up tunnel with autossh.
> #
> # This script will tunnel 2200 from the remote host
> # to 22 on the local host. On remote host do:
> # ssh -p 2200 localhost
> #
> # $Id: autossh.host,v 1.6 2004/01/24 05:53:09 harding Exp $
> #
>
> ID=root
> HOST=example.com
>
> #AUTOSSH_POLL=600
> #AUTOSSH_PORT=2
> #AUTOSSH_GATETIME=30
> #AUTOSSH_LOGFILE=$HOST.log
> #AUTOSSH_DEBUG=yes
> #AUTOSSH_PATH=/usr/local/bin/ssh
> export AUTOSSH_POLL AUTOSSH_LOGFILE AUTOSSH_DEBUG AUTOSSH_PATH
> AUTOSSH_GATETIME AUTOSSH_PORT
>
> autossh -2 -f -M 2 ${ID}@${HOST}
>
> The script detaches just fine when run manually so I just include it on
> /etc/rc.local as
>
> echo -n 'starting local daemons:'
>
> if [ -x /usr/local/sbin/autossh.sh ]; then
>echo -n 'ssh tunnel'
>/usr/local/sbin/autossh.sh
> fi
>
> echo '.'
>
>
> I have also tried calling it from /etc/hostname.tun0 in case there may be
> issues with /etc/rc.local not being called at the right time when network
> connections are ready, so I would use:
>
> inet 10.254.254.2 255.255.255.252 10.254.254.1
> !/usr/local/sbin/autossh.sh
>
> Your input is highly appreciated.
>
> PS. Clients are remote to me so i dont see much from console and I cant
> seem to find a way to have logs from boot.
>
I tried testing your script but hit a more general problem early on.
I'm running 5.1 and haven't been able to get autossh to work
successfully when called from the command line (or your script) using
the -f flag. According to the logs (authlog) on the remote machine,
the client successfully connects, then disconnects, apparently of its
own accord:
Aug 21 20:06:03 sshd[4635]: Accepted publickey for paul from 192.168.44.8 port
59113 ssh2
Aug 21 20:06:03 sshd[1671]: Received disconnect from 192.168.44.8: disconnected
by user
And the log file on local host:
Aug 21 20:06:02 x200 autossh[4347]: starting ssh (count 1)
Aug 21 20:06:04 x200 autossh[4347]: ssh child pid is 26907
Aug 21 20:06:04 x200 autossh[4347]: ssh exited prematurely with status 1;
autossh exiting
Calling autossh from your script had the same results (I didn't try it
using rc.local). The return status of 1 on the very first attempt
apparently causes autossh to give up (as documented in the man page),
though I can't see a reason why ssh would disconnect.
You might check what is in /var/log/authlog on your server. (BTW, the
AUTOSSH_DEBUG flag didn't produce any output.)
What's the -2 arg for in your script? I don't see it in the
manpage.
But it *does* work without the -f flag.
Re: Openbsd init script for ssh VPN tunnel
> > But it *does* work without the -f flag. > > > > That's very strange, does it detach from the terminal without the -f ? Can't say for certain. Presumably it does, but the program immediately exits and returns. If it does detach, it's not perceptible. You might try writing your own script that starts ssh and put that in rc.conf. It won't have the ongoing monitor-and-restart capabilities though. Alternatively, there is isakmpd/ipsec. That's integrated into the /etc/rc.d framework, though you still have to call ipsecctl from rc.local.
